Event Tech Notes

Field notes on the systems behind conferences and trade events — registration, check-in, apps, AV and the data they collect

How event technology actually behaves

Event technology fails in predictable ways, and most of the failures are visible before you sign. These notes explain the machinery so you can check it in advance.

Event technology is sold as a stack of solved problems. Registration is a form, check-in is a scan, the app is a download, the stream is a link. Then you run an event and discover that each of those is a system with its own failure modes, and that the failures cluster at the worst possible moments: the morning of day one, the week the contract renews, and the month after the event when someone asks for the data.

This site covers the practical side of that machinery. Not which vendor to pick, which depends on your events, but how the systems actually work: what a registration platform does underneath the form, how check-in queues form and clear, what attendee apps get used for versus what they get sold for, how AV and production contracts constrain everything else, and what happens to the data you collect along the way.

The three things that catch organizers out

Lock-in arrives through data, not features. Most platforms are easy to join and quiet about how you leave. The registration list, the session scans, the exhibitor leads: if you cannot export them in a usable format, on your schedule, you do not own them in any way that matters. The buying guide covers the contract terms that decide this, and the RFP questions page lists what to ask before a demo ever starts.

Systems that "integrate" often just exchange files. The vendor's diagram shows arrows between every product you own. In practice some arrows are real-time APIs, some are a nightly CSV, and some are a person re-typing. The difference decides whether your badge desk knows about a registration made ten minutes ago. The integrations page explains how to tell which arrow you are buying.

The venue runs its own software, and it does not talk to yours. Your registration count lives in your platform. The kitchen's count lives in the venue's function-sheet system, keyed to numbers you confirmed days earlier. The gap between those two figures is where meals run short, rooms get reset wrong, and the venue's Wi-Fi turns out to be sized for a different event than the one you are running. The event Wi-Fi page covers that last problem in detail, because it is the one that takes down everything else.

Where to start

If you are choosing a platform, start with registration and the buying guide, in that order. Registration is the system of record; everything downstream inherits its data and its limits.

If you are running an event on tech you already own, start with check-in and badging and event Wi-Fi. These are the two systems that fail in public, in real time, with a line of people watching.

If your event has a remote audience, read hybrid and streaming before you budget. The remote experience is a second production, not a camera at the back of the room, and it is priced like one.

If you have exhibitors, read lead capture before you sign the scanner contract, because who owns the scanned data is decided there and nowhere else.

And when the event is over, reporting and ROI covers what the numbers can honestly support, which is less than the dashboard implies but more useful once you stop pretending otherwise.

How to read this site

Every page tries to do the same three things: say what goes wrong, name the mechanism that makes it go wrong, and tell you what to check before you sign or ship. Where a real authority exists, we link to the source document rather than paraphrasing it. Where a cost matters, we explain what drives it and tell you to get the number from the vendor, because any figure printed here would be stale by the time you read it.

Nothing here is sponsored and no vendor pays for placement. The about page explains who publishes this and how to reach us.