Trade show lead capture: six tests to run before the show

Q: Should tools work offline?

If connectivity failure is plausible, test an [offline workflow](/offline-marketing-strategy) that does not weaken notice, security, accuracy, or later reconciliation.

What to take away

Test the capture tools in a rehearsal before the show, using the devices, network and staff the booth will actually have.
Offline behavior, export, access removal, and correction are pass conditions.
A scanner feature does not create valid permission or clean qualification.
Keep a manual fallback that preserves notice, data minimization, security, and reconciliation.

Lead capture is where trade show marketing meets real visitor data. Whatever scanner, app or form the booth uses, test it in a rehearsal first, so a failure shows up in the office and not in front of a visitor.

Six capture jobs to prove first

The six jobs that handle visitor data get tested before the others, because a failure there reaches real people. Each one has a pass condition you can check on a table in the office.

Job	Acceptance test	What to try in the rehearsal
Scan	Purpose and minimum fields can be controlled	Scan a test badge and list every field it stores
Notes	Visitor words and requested next step remain intact	Enter a note, sync it, and read it back unchanged
Identity	Individual staff access and authentication work	Sign in as each staff member on the show devices
Routing	Ownership, deadline, and escalation are enforced	Send a test lead and watch who owns it, and by when
Suppression	Declines and duplicate records stop outreach	Mark a decline, then try to send a follow-up
Archive	Records export and access can be removed	Export a test record and remove a user's access

Research, budget, floor plan, appointment, demonstration, and measurement jobs matter too, but they are planning work. The budget sheet should reconcile fixed, variable, internal, and cancellation costs, with exhibit space rates as one input.

Rehearse the booth workflow

A badge scanner is not a CRM. It captures organizer-provided and staff-entered data that still needs verification, purpose, routing, ownership, and retention control. The rehearsal checks that the rest of the chain does that work.

Run a normal workflow and a peak-load workflow.
Test loss of internet and a lost device.
Correct an identity and withdraw a follow-up choice.
Export records with timestamps, ownership, and permission context.
Remove a departed contractor's access.
Delete expired test and visitor data under policy.

Score mandatory controls before convenience. Test the exact plan, device, operating system, venue network, region, integrations, and export format that will be used. Record subcontractors and data locations.

Phones and tablets on the show floor

Show-floor phones and tablets carry the same risks as any mobile device, with more strangers nearby. CISA's mobile device cybersecurity checklist is written for its stated audience and scope, but its guidance on updates, authentication, apps, networks, data, and phishing raises useful test questions.

Apply the organization's current security controls and threat model. The checklist supplies questions to ask, not a pass mark.

Check privacy against the actual exhibit

The NIST Privacy Framework is a voluntary tool for identifying and managing privacy risk. It does not certify an event platform or decide legal compliance.

Use it to map data, people, purposes, actions, risks, controls, choices, and accountability for the actual exhibit. A scan that collects more than the follow-up needs fails that map even when the vendor's demo looks clean.

Score the rehearsal and keep the record

Give each tool the same source sample, user roles, required output, failure case, and export task. Measure setup time, recurring labor, specialist help, correction work, and shutdown effort.

Give a feature credit only when an intended user completes the task safely. Save the tested plan and date, because a current product page does not promise the same function or price later.

Keep the evidence record beside the decision, so a reviewer can reproduce the reasoning without relying on memory. Set the next review date, and name the change that would trigger an earlier check.

Record rejected options as well as the chosen path, because the original constraint may later change. Use the same definitions in the interface, export, meeting note, and correction log. The team's written workflow should say who runs the next rehearsal.