Write the report to support a decision
A useful trade show results report separates captured contacts, substantive conversations, completed promises, and meeting progress. Include the reporting date, clear definitions, open tasks with owners, and a small set of decisions for the next event.
A report showing only the number of collected contacts cannot tell a manager whether the event created useful conversations or whether the team honored its promises. Start with the decision the reader needs to make. They may need to allocate follow-up capacity, change the next booth's questions, or decide which demonstration should be improved. Organize the report around that decision instead of filling pages with every available number.
Keep immediate event output separate from later sales results. The booth team can report captured contacts and agreed actions at closeout. Meetings, opportunities, and revenue may develop later through the sales process. Use dated updates rather than pretending all outcomes are known the morning after the show. A concise report with clear unknowns is more useful than a polished claim the team cannot support.
Put the event period and reporting point at the top
Identify the event, operating dates, team, and the date and time of the report. Say whether the figures describe the whole event or one exhibition day. For a later update, explain what has changed since closeout. This stops readers comparing a cumulative seven-day summary with a single day's intake. Keep the same definitions between updates so the change reflects actual progress.
Use a header such as: Event [name]. Event dates [range]. Reporting point [date and time]. Coverage [whole event or day]. Prepared by [team]. Follow-up owner [person]. Open review date [date]. The header is a working format with placeholders, not a suggestion to publish private contact data. Most managers need grouped results and open responsibilities rather than a copy of the entire lead list.
Define the stages before counting them
Agree on the meaning of a captured contact, a useful conversation, a follow-up request, an accepted meeting, and a meeting held. Use criteria the team can check in the records. For example, a useful conversation may require a specific problem and an agreed next action. If your team uses a different criterion, state it. The definition should fit the reporting purpose rather than borrow a label that sounds more impressive.
| Report item | Example definition to agree internally |
|---|---|
| Captured contacts | Distinct people in the reviewed event records, with duplicate uncertainty noted. |
| Substantive conversations | Records meeting the team's stated criteria for a useful discussion. |
| Promised actions completed | The requested item or answer was actually delivered. |
| Accepted meetings | Both sides agreed to a purpose and time. |
| Meetings held | The agreed conversation took place; cancellation and proposals are separate. |
Do not present these stages as automatically equivalent. A single person can have several actions, and a proposal is not a held meeting.
Prepare a clean working snapshot
Export the event data, record the export time, and check incomplete contacts and possible duplicates before producing totals. BoothCatch's CSV export contains the whole event, regardless of the screen filters. Use the exported fields to build the necessary working views in your spreadsheet or sales system. Keep a clear distinction between correcting a reporting copy and changing the actual lead record.
For a multi-day show, use the latest full-event snapshot instead of appending overlapping daily exports. Review company-name variants if reporting company counts, and keep people counts separate. Where a figure cannot yet be verified, label it as pending review. That is better than silently treating missing information as zero or filling a blank with an estimate the reader will mistake for an observed result.
A one-page report format you can copy
| Section | Content to fill in |
|---|---|
| Event and reporting point | [Event], [dates], [snapshot time], [coverage]. |
| Purpose | [The visitor problem or conversation the booth aimed to support]. |
| Output | [Reviewed contact count], [substantive conversations], [definition notes]. |
| Delivery | [Promised actions completed], [open actions], [main reason still open]. |
| Meetings | [Accepted], [held], [cancelled], [pending timing], with the reporting period. |
| What visitors asked | [Recurring questions], [requested resources], [unresolved conditions]. |
| Next actions | [Task], [owner], [due point], [evidence of completion]. |
| Next event changes | [A small number of changes linked to observed problems]. |
Keep the first page readable without opening a spreadsheet. Put detail in the team's controlled working material and reference it through the normal internal process. The report should make the current state understandable while preserving the individual context for the people doing follow-up.
Use ratios only when the denominator is clear
A percentage can be useful when the reader understands what was counted. If reporting promise completion, divide completed promised actions by all actions due within the stated period. Explain whether the unit is actions or people. One contact may request two resources, so an action-based rate cannot be compared directly with a people-based response rate. Include the underlying counts beside the percentage.
If you do not have a reliable count of everyone who approached the booth, do not invent a visitor-to-lead conversion rate. You can still report reviewed contacts and useful conversations. If an item has no denominator or no observations, label it accordingly. A simple count with a clear definition is more defensible than a percentage built from a guessed footfall estimate.
Report conversation themes with examples
Group repeated questions into a few themes: workflow fit, implementation conditions, resource requests, or next-step uncertainty. Include a short anonymous example of the question where helpful. The example should reflect an actual reviewed note; if you create an illustrative example for training, label it as illustrative. Avoid copying private names or detailed project information into a broad report when a grouped theme will serve the decision.
Connect each theme to a practical response. If many notes lack the specific resource requested, improve the closing question. If staff repeatedly need a specialist for the same condition, prepare a suitable explanation before the next event. If meeting proposals stall because their purpose is unclear, rewrite the confirmation format. These observations turn the report into an improvement tool rather than a catalog of flattering comments.
Make unfinished work visible and owned
A report can show strong contact collection while concealing a queue of unanswered technical questions. Give open work its own compact section. Identify the task, owner, agreed timing, and reason it remains open. Use grouped counts for the manager and individual records for the people delivering the answers. An unnamed item to follow up later is not an action plan.
Separate work waiting on your team from work waiting on the visitor. A specialist answer not yet prepared is different from an unanswered meeting proposal. The distinction helps allocate capacity and avoids blaming visitors for promises the team has not fulfilled. If the plan changes, update the lead note and the next report so the owner and the reported state remain consistent.
Update sales progress through the actual sales process
If the company tracks opportunities in a CRM, use that system's stage definitions for a later sales update. Connect the relevant event context through the team's handoff process, and avoid claiming that a booth conversation automatically created an opportunity. A later meeting can be reported as progress without claiming revenue. When revenue is eventually attributed, use the company's established method rather than inventing a new attribution rule for this event.
BoothCatch provides contact context, notes, ownership, follow-up state, and CSV handoff. Use those records to check the promises made at the booth, then maintain meeting schedules and deeper sales reporting in the team's normal tools. A short later update can state what changed, which tasks are complete, and which questions remain. Keep the reporting point visible so the reader can assess the timing fairly.
Finish with a few changes the team can actually make
Choose changes that have an owner and can be checked before the next event. Examples include replacing a vague closing question, preparing a recurring technical answer, separating pickup from registration, or adding a review of unassigned actions before closeout. Each change should refer to an observed issue. Do not add a long wish list with no connection to the event records.
- Event dates, coverage, and reporting time are explicit.
- People, actions, and meetings are counted as different units.
- Duplicate uncertainty and overlapping exports have been reviewed.
- Percentages include their counts and denominator.
- Open work distinguishes team tasks from pending visitor decisions.
- Next event changes have owners and observable completion criteria.
Frequently asked questions
When should we write the first event report?
Prepare a dated closeout snapshot once the records have been reviewed. Add later updates for meetings and sales progress rather than waiting for every possible result to arrive.
Is a high contact count enough to show success?
It describes collection output. Add the event's stated purpose, conversation quality criteria, completed promises, and actual meeting progress so the reader can assess what the count means.
Does BoothCatch automatically produce this report?
Use BoothCatch's lead records and whole-event CSV as inputs. The team assembles the working report in its spreadsheet or sales process, with definitions and meeting outcomes checked separately.
Start the operating flow for your next event
Create an event and purchase an Event Pass to operate QR, card, lead management, and giveaway flows.