Lynkarr
Resources

How a badge becomes a contact

What actually happens between a photo and a saved record — what is read, what is refused, how a duplicate is caught, and what survives when the event that produced it is deleted.

Two kinds of badge, one button

Most conference badges carry a barcode or a QR code — vCard, MECARD, or a plain line of text — and that is read directly, with no photo needed. A badge printed with an organiser's own identifier instead of a person's details is reported as exactly that, rather than failed silently or guessed at, because only the organiser's own system can resolve it.

Everything else — a badge with no readable code at all, or a personal business card handed over at a stand — is read from a photo. There is one Scan Contact button either way; which path runs is decided by what the code actually contains, not by a choice somebody has to make first.

What the reading is told never to do

The model reads name, company, title, email and phone from the photo, and is told explicitly never to invent a field it cannot see — in particular, never to construct an email address from a name and a company. A real printed field in the wrong place (an event's own name read as the company, a barcode's id number read as a phone) is the failure this actually has, and the only reliable check for it is the person who was just holding the badge — so what was read is shown back editable, and nothing is saved until it is confirmed.

If nothing could be read at all, the photo is kept and a retake is offered rather than a blank form.

A photo is only saved as a contact if it is allowed to be

An event can be set to refuse business cards — for a visitor who hands over their own card instead of using the event's own badge. When that is off, every photo is checked for what kind of document it actually is before anything is extracted, and a business card is refused with a plain reason rather than saved as though it were the badge it was not.

What happens, in order

  1. Point the camera and tap once

    The camera opens the moment the button is tapped. A barcode or a QR code is read directly; anything else is read from the photo, automatically, without a second tap to start reading it.

  2. It is checked against the pool

    An address that matches an existing contact merges into it — a disagreement is kept as history, never silently overwritten. With no address, an exact match on name, phone, company and title catches a re-scan without ever merging on a bare name alone.

  3. A likely duplicate is asked about, not assumed

    Name and company both matching somebody already scanned at this event prompts "Contact already exists — overwrite?" rather than silently creating a second row or silently merging into the wrong person.

  4. It is tagged with the event automatically

    The event's own name, added to whatever tags the contact already has — never replacing them. A contact scanned at two shows carries both, not just the most recent.

  5. It lands in the pool, with its photo attached

    On its own page: every field editable, notes, tags, and the scanned image right there — exported or deleted from that one page, with no separate place any of it can go missing.

More in the same place

One pool, whatever the source A card enquiry, a form reply, a CSV import, typing one in by hand, and a scanned badge all land in the same table — searchable, filterable by tag or by source, selectable in bulk for export or delete.
Hosted and Attended, kept apart An event your company runs, and a trade show it turns up to with a booth, are different things and get their own section of the Events list rather than one undifferentiated pile.
A dashboard per event Total scans, unique contacts, who scanned the most, scans by company, and a green-to-red heatmap of traffic by hour — built from the actual scan log, not a guess from the contact count.
Auto-delete, on a schedule you set 30, 60 or 90 days after an event ends, its dashboard and scan history are removed automatically, with a warning email to whoever created it 7, 3 and 1 day(s) before. The contacts it produced are unaffected either way.
Delete a contact, delete its photo A scanned image is never left behind: deleting the contact it belongs to removes the photo with it, on every delete path, and the confirmation says so before it happens.
QR or photo, locked per event An event's default scan method is set once in its settings, so nobody scanning into it has to choose between reading a barcode and reading a badge photo.

Questions

What if the badge has no barcode at all?

It is read from the photo the same way a business card is — name, company, title, email and phone, told never to invent a field it cannot see. What could not be read is shown back editable rather than saved wrong.

Will scanning the same person twice create two contacts?

No. An address that matches merges into the existing contact. With no address, an exact match on name, phone, company and title catches a re-scan — and where name and company alone match somebody already scanned at that event, you are asked before anything is merged or duplicated.

What happens to the photo?

It is kept with the contact it produced, viewable on that contact's own page, and removed only when the contact itself is deleted — never on its own, and never when the event that produced it is deleted or expires.

Which plan is it on?

Starter and above.

Try it with one code

The free plan has no expiry and asks for no card, and the analytics behind it are the same ones a paying customer gets.

Get started free See pricing

Free forever for one person. No card, and scans are never metered.