Retrospective: Rolling Out a Platform Across Multiple Shows

The Assumption That Breaks Everything

The brief sounded straightforward: one platform, many shows, shared exhibitor data, unified reporting. The team had already shipped a working portal for a single event — registration, stand allocation, document collection. Reuse it across the other five shows in the portfolio and call it done.

Show two went live three weeks after show one. Within a day, the support queue was full of exhibitors who couldn't find their bookings, floor managers who saw the wrong stand numbers, and freight agents submitting documents that disappeared into the wrong event bucket. The code was the same. The data was not.

That is the lesson that runs through every multi-show platform build: software is the easy part. Data governance is where rollouts come apart.

What "Multi-Show" Actually Means at the System Level

A single-show portal has one floor plan, one exhibitor list, one set of document deadlines, and one venue's rules for badge access. When you extend to a portfolio, every one of those things multiplies — and none of them multiply cleanly.

Floor plans differ by venue. Stand classifications (shell scheme, space-only, co-exhibitor, pavilion) vary by organiser. Exhibitor records that look the same on a spreadsheet are often duplicates with subtly different company names, ABNs, or postal codes. Document requirements change by country — what customs needs for a show in Melbourne is not what it needs for one in Birmingham. And freight deadlines are always different because venues have different lead times with their preferred handlers.

A platform that treats all of this as one entity fails at show two. You need a data model that represents the event as a configurable container, not a fixed schema. That means every show gets its own:

• Stand inventory with venue-specific categories
• Exhibitor classification rules (because a "co-exhibitor" means different things to different organisers)
• Document checklist, keyed to destination country and freight mode
• Deadline schedule, separate from the shared calendar
• Freight document routing, so PDFs land in the correct event folder — not a shared inbox

This sounds obvious when written down. It was not obvious during the first build, when the pressure was to ship fast and the assumption was that "it'll mostly be the same".

It mostly was not.

The Three Things That Broke First

1. Exhibitor identity across events

A company that exhibits at three shows in a portfolio is not the same record three times — but they expect a single login, a single profile and a single view of their bookings. The initial build created a new record per event. By show three, the same exhibitor had logged a support ticket saying they had three accounts with three different email addresses, none of which matched the one they used for invoicing.

Fixing this mid-rollout required a retroactive merge, which surfaced all the places where the original data import had used the booking contact's email rather than the company's master account. Not a catastrophic failure. A slow, expensive one.

2. Document routing

Freight documents submitted by exhibitors — carnets, packing lists, insurance certificates — need to land somewhere a human can act on them. In a single-show build, a shared inbox is fine. Across six shows running concurrently, a shared inbox is chaos. Documents from four different events, multiple freight agents, and two destination countries arrived in one queue. Nobody had built routing rules. The workaround was a part-time coordinator manually forwarding attachments to the right event folder.

This is exactly the kind of manual step that a system is supposed to eliminate — and exactly the kind of step that reappears when the system wasn't designed for the load it ends up carrying.

The fix: document submissions get tagged at upload with event ID, freight mode and document type. Routing is automatic. The coordinator becomes the exception handler, not the postbox.

3. Reporting that couldn't separate shows

Organisers wanted a single dashboard. What they got was a dashboard that summed everything. Total registrations, total stand revenue, total freight submissions — but no way to filter by event without exporting to a spreadsheet and pivoting manually. Which meant the reporting tool was, in practice, a spreadsheet with extra steps.

Useful reporting for a portfolio operator needs two levels: the aggregate view (how is the portfolio tracking overall?) and the event view (what does show four look like with two weeks to go?). Building that properly means the data model has to support it from the start. Retrofitting filters onto an undifferentiated schema produces ugly, slow queries and a lot of conditional logic that shouldn't exist.

What the Build Team Cut — and Was Right to Cut

There were features on the original specification that, in retrospect, would have made the rollout worse, not better.

Automated stand allocation. The spec called for a rules engine that would auto-assign stands based on exhibitor category, booking date and proximity preferences. We cut it from the MVP. At show one, the floor manager still wanted to make the final call. At show two, the venue had last-minute layout changes three weeks before doors. An automated allocator would have needed to be overridden constantly and would have created a false sense of certainty. The system now surfaces a recommended allocation; a human approves it. That's the right split.

Cross-show exhibitor analytics. The brief included a feature that would show organisers which exhibitors had attended multiple shows, with spend and attendance history. Genuinely useful, but it required the clean exhibitor identity model to work correctly — and as described above, that model was broken until mid-rollout. Shipping analytics on top of dirty data produces confident-looking nonsense. It was deferred until the merge was complete and the identity model was stable.

Bulk freight document generation. The system can already collect documents. Generating them — pre-filling carnets, packing list templates, draft insurance schedules from the exhibitor's product data — was in scope but pushed to phase two. Correctly. Document generation needs the data to be trusted, and trusted data takes one full show cycle to establish.

Cutting features at the right time is not a failure of ambition. It is the thing that keeps a rollout from collapsing under its own scope.

What a Better Build Process Looks Like

If you're commissioning or building a multi-show platform, the sequence that actually works is:

Run show one as the reference build. Don't generalise early. Let the first event expose every edge case — and there will be many — before you write the abstraction layer.

After show one, conduct a data audit before show two. Which fields were populated consistently? Which were left blank or filled with junk? Which document types arrived correctly? What did the freight coordinator actually do that the system didn't?

Only then design the multi-event data model. At that point you have real examples of divergence, not hypothetical ones.

Keep the event configuration separate from the application code. Each show's floor plan, deadline schedule and document requirements should be data — editable by an ops manager without a developer. If changing a document deadline requires a code deploy, you have already made a mistake that will cost you at 11pm before a show opens.

For teams thinking about where to begin with this kind of scoping, the Import/Export Quote-Time Estimator is a useful early sanity check on capacity — it won't spec your platform, but it forces you to put numbers on how much time the current manual process actually consumes, which makes the build case concrete rather than theoretical.

The Spreadsheets vs a Supplier Portal tension is real in exhibition ops too: organisers often start with spreadsheets per show, add a portal for show one, and then discover that scaling the portal without fixing the data model just moves the chaos into a more expensive system. And the Why We Kept Humans in the Export Document Review Loop principle applies directly here — document routing automation is valuable, but exception handling still needs a human, especially when a freight agent submits a carnet for the wrong show.

The AI-Assist Layer

Where AI tools shortened the build cycle in practice: classification tasks. Matching exhibitor-submitted company names to existing records (the deduplication problem) is tedious and error-prone when done manually. A classifier that flags probable duplicates for a human to confirm — rather than auto-merging — worked well in testing. The human stays in the loop; the volume of manual review drops significantly.

Document type classification — "is this a packing list, a carnet, or something else?" — is another area where a simple model running at upload reduces the load on the coordinator. Not perfect. Good enough to route the majority correctly and surface the edge cases for review.

Neither of these is a solved problem. Both are tractable problems where a lightweight model, tuned to the specific document and naming conventions of the organiser, performs well enough to justify the build. Discovery to working prototype on the classifier took weeks, not months.

The Decision You Face Next

If your portfolio has more than two events and you're managing them with separate spreadsheets or disconnected instances of the same tool, the question is not whether to consolidate — the question is when to fix the data model, and whether to do it before or after the next show.

Before is almost always cheaper.