Every trade show produces the same artifact: a pile of contacts spread across four places and a plan to merge them later. Later rarely comes. The badge scans stay in the vendor app, the photos stay in a camera roll, and the one person who booked a meeting gets a follow-up while everyone else gets silence. ThinkingAI is exhibiting at AI4 this week, and I own the follow-up list. The rule I set for myself: reconciliation happens during the show, against the CRM, so the list is finished before the booth comes down. As of Aug 6, with the show open since Aug 3, that list holds 33 booth leads in HubSpot and 46 badges collected at the booth, 11 of them already matched to CRM records and 35 still waiting to be added.
Decide the capture paths before the show opens
A booth conversation can end in exactly four places for us, and all four were decided before the first attendee walked in. A meeting booked on a live calendar at the booth. A signup on the iPad kiosk. The demo-incentive form, which offers $50 for a proper demo request. And a badge scan, imported into the CRM after hours. Four paths, one destination: each path produces a HubSpot contact whose source says booth.
That last clause is the design constraint. A capture path counts only if it ends in the CRM without a human retyping anything. The calendar booking creates the contact. The kiosk creates the contact. The form creates the contact. Badge scans arrive as an offline import. Set up this way, “export everything after the show” stops being a project, because the export already happened.
Photograph the badge when the scan fails
Badge scanning breaks more often than anyone admits. QR codes refuse to read under booth lighting, the scanning app demands a filled form while the person is mid-sentence, and some conversations end before anyone reaches for the scanner. Our fallback rule was one sentence: if you cannot scan it, photograph it. A badge photo is instant, interrupts nothing, and preserves everything printed on the badge: name, title, company, attendee tier.
The camera roll became a capture path of its own. By Aug 6 we had 46 badges collected, scans and photos together. Nobody at the booth had to remember anything about the person afterward, because the badge itself was the record.
Have AI read the photos the same day
A camera roll full of badge photos is where most systems stall, because someone has to type them out. We skipped the typing. The photos went to a vision model that read each badge and returned name, title, company, and badge tier as rows, deduplicated on name plus company. Each row stays linked to its photo, so any doubtful read can be checked against the source image in seconds.
The reads need spot-checks. OCR on a photographed badge mangles the occasional company name, and dedup on name plus company can miss a person who appears twice with slightly different employer strings. The fix is human review of the edge cases, which is minutes of work on 46 rows. The old alternative was an intern and an afternoon, and the intern made errors too.
Cross-reference everything against HubSpot
A list of 46 names is trivia until you know which of them the CRM already knows. So the badge table gets cross-referenced against HubSpot on a fuzzy match of name plus company. The result splits the list cleanly: 11 of the 46 badge people already exist as contacts, usually because they also booked a meeting or signed up at the kiosk, and 35 exist only as a badge.
That split is the real output of the whole system. The 11 matched people keep their existing record and pick up the badge as supporting context. The 35 unmatched people become the follow-up backlog, each one a real conversation that would otherwise have evaporated by the flight home. Fuzzy matching earns its own qualifier: it matches on name and company, so the edge cases were spot-checked by hand before anyone acted on the split.
Filter until the booth list is honest
The CRM side needs its own hygiene pass. “Contacts created since the show opened” is a tempting definition of booth leads and a wrong one. In the same window since Aug 3, our CRM also collected paid-search signups, organic newsletter and ebook signups, and test rows created by our own team while checking that the kiosk worked. Thirteen rows were excluded from the booth list for those reasons, and every exclusion sits in an audit list with the reason written next to it.
The audit list matters as much as the exclusions. A booth-lead count is what justifies next year's booth, and a count padded with paid-search signups tells the company the show performed better than it did. Keeping the excluded rows visible means anyone can challenge a call, and the 33 that remain are defensible.
The caveat that stays glued to the numbers
Badge scans at this show carry no email address. That sentence is written on the list itself, because it changes what the list is for. Email exists only where the person gave it: at the kiosk, on the demo form, or in a meeting booking. The 35 badge-only people start as a name, a title, and a company, so follow-up for them means enrichment before any sequence can send. Those rows feed the same pipeline as the AI sales intelligence system I run, which exists for exactly this shape of problem. Writing the limitation on the list keeps someone from pointing an email tool at rows that never had an address.
The whole system fits on an index card
Decide the capture paths before the show, and make every one of them end in the CRM. Photograph any badge that refuses to scan. Have AI read the photos into a table the same day, with each row linked back to its photo. Cross-reference the table against the CRM so every person is either matched or queued for adding. Keep an audit list of everything you excluded and why. And write the data's limitations on the list itself. These numbers are a point-in-time snapshot, generated Aug 6 with the show still running, and that timing is the point: when the booth comes down, the follow-up list is already done.