Exhibitor Intelligence: Prospect Identification for the Events Sector

The Problem

An event organiser’s revenue is exhibitor revenue, and the best predictor of a company exhibiting at your event is that it already exhibits at someone else’s. Reset Connect’s commercial team knew this. They had a long list of UK events whose exhibitors overlap with their audience: climate technology, solar, waste and resource management, sustainable construction. What they did not have was a practical way to turn that into a list.

The research does not fit the sales calendar

Building the list by hand means a researcher opening each event’s exhibitor directory and copying companies out, hundreds of exhibitors per show, with no record of which ones the CRM already held. At that scale the research rarely survives contact with a live sales calendar, and when it does get done, it goes stale before the next cycle.

New names were the expensive part

A raw list of exhibitors is not much use to a sales team. The value sits in two questions: is this company already in the CRM, and is it a fit for the event? Answering those by hand for a thousand companies is the part that did not get done.

The Shape of the Engagement

Giles Brown, my commercial partner on joint ventures, and I scoped this with Reset Connect in the spring as part of a wider data programme, proposed jointly by his company, Momentum Works, and Soltech. This engagement delivered the programme’s first phase: the prospect list itself, built and checked on real data in days, so the later phases could be argued from results.

The collaboration had a clear division of labour. Giles owned the client relationship and the commercial framing: he knew what a sales director would actually do with the output, and every client-facing document went through him before it went anywhere near the client. I owned the discovery, the build and the verification. The plan, the go decision and the delivery all went through both of us.

Two decisions made the timescale work. First, I did not start from scratch. Soltech owns Signal Monitor, a commercial intelligence platform already running in production for the events sector, and I concluded the right move was to fork that codebase into its own instance. The web app, the authentication, the run history, the PDF and email delivery already existed, so the only genuinely new code was collection and scoring. Each instance is fully separate, with its own database and its own access gate; Reset Connect’s data never shares a system with anyone else’s. Second, the first phase was explicit about what it leaves out: no SLA, no monitoring, no retry logic, and the plan said so in writing.

The go decision was a single page with four numbered questions: which events, which CRM export, who receives the output, and what counts as done. Reset Connect’s team came back quickly with direct answers and their CRM export, and where two answers pulled in different directions I wrote down the interpretation I was applying and sent it back for confirmation rather than guessing silently.

Collection reads published exhibitor directories only. It is sequential, waits a second and a half between requests, respects robots.txt, and identifies itself in every request with a user agent naming Soltech and linking to this site.

How it played out

1. Days 1 to 3

   Discovery

   Ten candidate directories checked for readability, published exhibitor counts checked by counting, and a fifty-company scoring prototype. The plan changed before a line of pipeline code existed.
2. Day 4

   Build

   Collection and scoring built on Soltech’s platform fork, and the system live behind its own Cloudflare Access gate the same day.
3. Day 7

   The agreed run

   Four events picked by Reset Connect’s team from the discovery findings, matched against their CRM export.
4. Days 8 to 9

   Verify, then deliver

   A full day reading the output against reality: five corrections found and released the same day, the shortlist’s stability measured, and the ranked deliverable produced.

Discovery First

Before writing the pipeline I spent a day checking the plan against the actual websites. Most of it did not hold.

The plan changed before the build

The original plan targeted the events with the thinnest existing data coverage. Checking the actual sites killed it in an afternoon: only three of the first ten candidate shows published a directory in a form the system could read plainly, and the thinly covered shows were thinly covered for a reason. The plan flipped to the well-published, well-attended shows, where the value became overlap analysis and net-new discovery. Nothing had been built yet, so the change cost an afternoon.

Estimates were replaced by counts

Published exhibitor counts are marketing figures. Twenty minutes of counting per directory replaced every estimate in the plan with a measured one, and the client-facing numbers were quoted from counts from then on.

A fifty-company prototype

Before committing to model-based scoring I ran 50 sample companies through two models against a draft rubric, an afternoon’s work. It caught a defect that would have been visible in a client deliverable: one of the source events itself scored as a strong prospect. Events, trade bodies and trade media now get labelled by deterministic rules before the model ever sees them. The prototype also corrected a metric. The two models agreed on 78% of “is this a strong prospect” decisions, a figure flattered by the easy rejections. On the shortlist itself the overlap was 50%.

The Pipeline

The system is a sequential pipeline where every stage’s ordering is a business rule, not an accident: deterministic labels are applied before the model scores, and the cap on labelled organisations is enforced after it, in code.

Nothing is deleted

No stage of the pipeline removes a company: a list that quietly drops rows cannot be checked, by me or by the client. The one outright exclusion is Reset Connect itself.

Where the model fits

A language model does one job here: reading what a company says it does and judging its fit against a rubric written for Reset Connect’s audience. Deterministic rules do the labelling; the model only judges fit. Scoring the full list takes minutes, which is what made repeated rescoring practical.

The Run

The agreed run covered the four events Reset Connect’s team picked from the discovery findings. It collected well over a thousand unique companies and checked every one against every name and every domain in the CRM export.

Companies already in the CRM were flagged, never removed, with the matching key recorded on each. 1,045 were entirely new to the business: companies exhibiting at events in Reset Connect’s own sector that had never reached the sales pipeline. Roughly one in five of the full list scored as a strong prospect, delivered in ranked order.

The deliverable stated its caveats in the covering note, not in a footnote. Name-based matching cannot catch a company the CRM holds under a different spelling, so the “new to you” figure is a generous one, and the note, which went through Giles like everything client-facing, said exactly that.

Verification

The build took days. Before delivery, I spent a further full day reading the output: not the code and not the test results, but the spreadsheet and the PDF, row by row, against the source websites and the CRM export.

Five corrections came out of that day, each released the same day it was found:

• A trade body scored as a strong prospect. The deterministic label and the model’s instructions were supposed to be two layers of protection, but only one was wired to the enforcement point. The cap now also acts on the model’s own sector answer. Rerun across two full scoring passes: 38 labelled organisations, zero leaks.
• Two exhibitors listed Google as their website, and a third had typed their domain with an extra letter. Junk domains were producing false CRM verdicts. The fix was replayed against all 337 collected domains, not just the three known cases.
• A trailing slash was silently discarding a large share of the export’s domain keys. It had produced two false “already in your CRM” verdicts. A false duplicate removes a real prospect from the client’s list without leaving a trace, so this one was fixed first.
• Three companies reached the spreadsheet with no score and no log line. The model had answered in a format one layer refused quietly. The design required a loud failure; that layer swallowed it. A scored row that fails to parse is now logged and surfaced.
• The confidence column was misleading, and the fix was editorial rather than technical. It is covered in the next section.

The test suite nearly doubled across those two days. Inspection found the defects; the tests were written afterwards, so none of them can recur.

Rerun Stability

A scored list raises an obvious question: rerun it, and do you get the same list? I ran it five times to find out, across both candidate models, in about twenty minutes.

On the stronger model, 92% of the strong-prospect shortlist survived a rerun, most of the shortlist appeared in every run, and no shortlisted company fell to the bottom band. The lighter model held 77%. That measurement chose the model for the delivered run, and the client’s method note says plainly that the list is stable rather than identical between runs.

The measurement also changed what the report prints. The steadier model expresses its confidence more cautiously: the top prospect would have printed with a 45 beside its name, which a client reads as “probably not”. So the report prints each company’s rank, which is what a salesperson working top down needs, and the confidence stays internal as a sort key.

Challenges and Trade-offs

Impact

Reset Connect’s commercial team now has 1,045 net-new companies active in their own sector, delivered in ranked order with the strongest prospects at the top, each one checked against what the business already holds and every verdict auditable.

The run that produced the deliverable is repeatable on demand in minutes. A hand-built list is fixed at the day it was built. This one can be rerun nearer the events, when the directories are fuller. The platform runs live behind Cloudflare Access, with the full run history browsable.

The first phase did what it was scoped to do: it replaced assumptions about the market with measured figures and gave the wider programme a starting point. Reset Connect answered discovery questions in days and supplied their CRM export the day it was asked for. For the partnership, it is the second commercial intelligence system running for the events sector, alongside Signal Monitor. A refresh run closer to the events is the next step, along with the enrichment and CRM integration phases scoped in the programme.

Tech Stack