What a Zuant lead capture export looks like when it reaches the CRM

Two people are describing the same stand at the same show. Your post-show report credits the exhibitor with 1,240 leads. Their marketing operations manager, looking at her own system, says 853 contacts came out of it. She is not disputing your number so much as failing to recognise it, and the conversation goes nowhere useful because neither of you has named what you are counting.

Nothing has gone wrong. A Zuant lead capture export passes through several legitimate steps between the badge scan on the stand and the record in a CRM, and each step removes rows for a defensible reason. The trouble starts when both numbers get called leads.

Why does a lead sit in the cloud before it reaches the CRM?

Zuant pairs a mobile capture app with a cloud layer, and describes the handoff in a way that is unusually explicit about the gate: "Choose to filter leads in the Cloud and release manually, or run automatically in real-time" (Zuant, 2026). The cloud side is where an event lives and where release happens, described as "From creating events, to releasing leads for downstream processing, you do it all right here" (Zuant, 2026). The downstream target is left open, with the product positioned to "Integrate easily with any CRM or Marketing Automation Platform" (Zuant, 2026).

That gate is a good feature. Exhibitors have real reasons to hold leads: a rep scanned three competitors and a student, somebody tested the scanner on their own badge on Tuesday morning, and a qualification question was mis-set for the first two hours. Releasing that straight into a sales queue burns goodwill with the sales team faster than almost anything else.

The gate also means there are two populations at all times, and they diverge in both size and timing. What the organiser can see, if anything, is the capture side. What the exhibitor talks about is the released side.

The four counts, and why each is smaller

Work one exhibitor through the chain. Six scanners, three days, illustrative numbers with a realistic shape.

Scans captured: 1,240. Every tap on the app, including the ones taken by mistake.

Records approved for release: 1,156. Eighty-four removed in the cloud as staff, competitors, obvious tests and one rep who scanned the same colleague eleven times demonstrating the app.

Distinct people: 1,044. Of the 1,156 approved records, 112 are repeat scans of somebody who came back or spoke to two reps. Those repeats are real conversations and they are worth keeping as scan events. They are one person.

Net new CRM contacts: 853. Of the 1,044 distinct people, 63 carry no usable email address, captured from a badge that did not expose one or from a business card that was never transcribed. Of the 981 that remain, 128 already existed in the CRM from earlier campaigns, so they update rather than create.

Four counts: 1,240, 1,156, 1,044 and 853. The last is 68.8 per cent of the first. Every reduction was correct, and if you publish 1,240 while the exhibitor works with 853, you have handed them a reason to distrust your reporting on a point where you were not even wrong.

The gap is not constant across exhibitors either, which is what makes an unlabelled column dangerous in a league table. A disciplined team with a trained booth staff and a well-set qualification form loses perhaps 5 per cent between capture and release. A team who handed a scanner to two agency staff on Monday morning can lose 20 per cent. Rank exhibitors on captured scans and the second team looks better than they were. Rank them on net new contacts and the first team looks worse than they were, because their CRM already held most of the people they met. Neither ranking is meaningless, and neither means what the column header says.

What an organiser can see, and what stays on the exhibitor's side

Worth being clear about the visibility line, because it decides which of the four numbers you can even produce.

If lead capture is a service you supply, the capture side is yours: scan events, timestamps, device, and the badge identity behind each scan. That is enough for scans captured, distinct people scanned, and stand-level activity across the whole floor, which is the most useful thing an organiser can report because it is the only view that spans every exhibitor on comparable terms.

The release side is the exhibitor's. Whether they held 84 records or 300, whether they released once or four times, and what their CRM did afterwards are all facts about their systems, and asking for them is a request rather than a query. Some exhibitors will share readily, particularly the ones who want your help proving return on their stand. Others will not, and building a portfolio report that depends on their cooperation means building a report with holes in it.

The honest structure is two tiers. Publish the capture-side figures for everybody, on one definition, and treat released and CRM-side counts as a voluntary supplement from the exhibitors who provide them. Do not average the two tiers together.

What does the CRM do to the number after that?

The final drop happens outside anybody's event system. HubSpot's contacts API reference states that the "email address is the primary unique identifier to avoid duplicate contacts in HubSpot", and that an upsert keyed on email will update contacts that already exist and create the ones that do not (HubSpot, 2026). Whatever CRM sits on the far side will have some equivalent rule, and the one in force is the default unless somebody deliberately changed it. Find out which field yours treats as the unique key before the first release, rather than after.

Two consequences follow. Records without an email either fail, land in an error queue, or create something the CRM cannot deduplicate later. And any lead whose email already appears on a contact merges into that contact, which is right for data hygiene and invisible in a count of new records.

The craft of getting the highest possible match rate out of that, when email is the only key you hold on both sides, is a separate exercise with its own trade-offs. The point here is narrower: the CRM's deduplication is a fifth actor with an opinion about how many leads there were, and it acts after everyone has stopped watching.

Why the count keeps moving after the show

Timing is the other half of the drift, and it catches organisers who publish quickly.

An exhibitor running automatic release in real time has everything in the CRM before the show closes. An exhibitor running manual release may push a first batch on the Wednesday of show week, hold the rest for a qualification pass, and release the remainder three weeks later when a contract sales resource starts. Zuant's cloud layer supports both, and also supports triggering follow-up emails live or in bulk after the show (Zuant, 2026), so the release schedule and the outreach schedule are two separate decisions the exhibitor makes.

Take your snapshot on day three and this exhibitor shows 460 released. Take it on day thirty and they show 1,156. Neither figure is wrong and neither is comparable to last year unless last year used the same cut. Fix a cut date, publish it in the report header, and keep the earlier extract so somebody can reconstruct the difference.

One more timing hazard is worth naming. A second release of a batch that already went through will push the same records again unless something upstream prevents it, and the CRM will either duplicate them or update them depending on its keys. Making a push safe to repeat is what an idempotency key is for, and it belongs in the design before the first show rather than after the first mess.

What to agree with an exhibitor before the show

Four things, all cheap, all easier to settle in September than in November.

Which number goes in the post-show report. Scans captured is the one you can actually observe, so use it, and label the column scans rather than leads.

Whether repeat scans count once or every time. Both are defensible. Pick one, apply it to every exhibitor, and write it down.

What the exhibitor's own denominator is. Ask them what they will report internally. If they are going to quote net new contacts, you can put both numbers side by side and remove the whole argument in advance.

Which fields travel with the record. Qualification answers, notes, rep name, scan timestamp and stand location all change what the export is worth on the far side, and deciding those fields is a conversation that repays having early.

Where this stops

None of this measures whether the leads were any good. It measures how many rows survived each step, which is a question about plumbing. An exhibitor with 853 well-qualified contacts and one with 853 badge taps at a coffee stand look identical in every count above.

There is also a limit on what an organiser can see at all. Where the exhibitor brings their own capture tool rather than using yours, the scan events may never reach your systems, and the only figures you have are the ones they choose to tell you. Reporting a portfolio-level lead total in that situation means summing numbers collected under rules you do not control, which is worth a footnote rather than a headline, in the same spirit as everything else in the integration layer.

Start with one exhibitor and one show. Ask them for their released count and their net new contact count, put them beside your scan count, and work out where each gap came from. Twenty minutes on the phone gets you a chain like the one above, on your own data, and it will change how you label the column in the next report.