Why event registration breaks at the door, and what to measure

Nobody complains about registration in April. They complain at 08:40 on the morning of the event, in a corridor, to whoever happens to be holding a clipboard.

That is not because the door is badly run. The door is where every earlier decision is finally settled up. A form field that was ambiguous in April becomes a person standing in front of you whose name matches nothing. An approval that went out to an address that bounced becomes a delegate with no pass. A duplicate record created by a helpful assistant becomes two badges and one seat. The door does not create these problems. It presents the invoice.

The five ways a queue actually stalls

The name is not in the list. Almost always it is in the list — spelled differently, or under a personal address when the invitation went to a work one, or entered by an assistant under her own email. Searching by surname finds it in four seconds. Searching by exact email finds nothing, and the delegate hears "you are not registered", which is the sentence that turns a four-second problem into a four-minute one. Whatever you use at the door has to search the way a human remembers a name, not the way a database stores one.

They were approved and never received the pass. Approval and delivery are two different events. A system that reports only the first will happily tell you everyone is approved while a slice of those confirmations sat in a bounce queue for three weeks. Every one of those people arrives expecting to be expected.

They are at the wrong gate. Nobody reads which entrance is on the pass. This is not a failure of the delegate; it is a failure to notice that you built two doors and told people about one.

The record is a duplicate. Somebody registered, forgot, and registered again with a different address. Both were approved. Both hold a valid pass. The first scan admits them; the second one, at the other gate, twenty minutes later, is either a fraud alert or a shrug, and which one it is should not depend on who is holding the phone.

The decision needs a person. They cancelled by phone to somebody who was not in the room. They brought a colleague. They are the treasurer. There is no rule for this and there never will be — but there should be one named person with the authority to say yes, standing near the door, so that the queue does not stop while somebody calls the office.

Measure the exception rate

Most check-in dashboards report the number that is easiest to collect: how many people are in. That number goes up all morning and tells you nothing you can act on, because by the time it looks wrong the event has started.

The number worth collecting is the share of scans that did not complete cleanly on the first attempt. Call it the exception rate. Every exception is a registration-desk problem that survived until the morning and travelled to the door, where it costs the most to fix and has the largest audience.

Break it down three ways and it starts telling you what to change:

• By cause. Not found, no pass, already checked in, wrong gate, manual override. These map to four different upstream fixes and one policy decision.
• By gate. One gate with triple the exception rate is usually a signage problem or a device problem, not a delegate problem.
• By time. Exceptions cluster in the first twenty minutes, because the people who arrive early are the ones who were anxious about something.

A door that runs at a low exception rate can be staffed by volunteers with phones. A door running at a high one needs experienced staff and a supervisor, and you want to know which you have before you build the rota.

The measurements that are available a week early

Here is the useful part: most of the exception rate is knowable in advance, because most of it is upstream state you can query today.

How many approved registrations have a confirmation that was actually delivered? Not sent — delivered. If your platform records sent, delivered, opened, bounced and failed as separate states, this is a filter, and the answer is a list of people to chase. If it records only "sent", you will meet the difference at the door.

How many failures are sitting unlooked-at? A failures view is only useful if somebody works it. Treat it as a queue with an owner, not a report.

How many registrations look like duplicates? Same surname and same phone, same address with different capitalisation. Merging fifteen records in the office on Tuesday is a completely different job from resolving them one at a time in front of a queue.

How many people are approved but have not opened anything? Opens are unreliable — image proxies and mail prefetchers fire them, and privacy features suppress them — so never treat a missing open as proof. Treat a cluster of them across one email domain as a hint worth ten minutes.

How many have released their place? If delegates can hand back a seat themselves, the seat returns and you know who released it and why. If they cannot, they simply do not come, and you find out by counting empty chairs.

What to write down afterwards

The debrief is worth more than the dashboard, and it takes twenty minutes. Three things: the exception rate by cause; the two moments the queue actually stopped and what unblocked it; and the one upstream change that would have removed the largest bucket.

Then keep the audit log. Six weeks later somebody will ask why a particular person was admitted, or was not, and the only satisfying answer is a record of who did what, when. Not because anyone is suspected of anything — because "I think Priya waved them through" is not an answer you want to give a board.

The door is a measurement instrument pointed at everything you did in the previous six months. It is worth reading.