AGM check-in: from a printed list at the gate to an app on every staff phone

Producing the register of participating policyholders used to be a multi-day name-matching exercise, and we had already automated it: a tool in our reporting suite builds the member list straight from the policy database in seconds. The list was correct, fast, and repeatable.

On the day of the meeting, though, that list was still paper at a gate. Check-in ran off laptops set up at the entrance, never more than two, with staff searching the core system manually while a queue formed. Each arrival took two to five minutes. Attendance went into a handwritten logbook, and when someone who wasn't a participating policyholder arrived, staff struggled to explain why they couldn't come in.

The gate had two jobs, and only the first had ever been given real thought. Let the right people in. Then turn the wrong people away in a way that leaves them feeling served, because a policyholder who isn't participating is still a customer, standing in front of you, who believes they should be admitted. "You're not on the list" helps nobody, and from the customer's side it sounds like "we've lost your record."

Most check-in tools model a single outcome: found, admit. We modelled every outcome a gate actually produces, because the difficult moments are the ones where the answer is no or unclear.

Making the "no" path work meant loading the full policy book alongside the member list, which cost us a 21MB import. In exchange, when a non-participating policyholder arrives, staff can see the person's actual record with its plan and status and say: you hold this product, and it isn't a participating policy. The person gets an explanation at the gate, on the spot, without a phone call.

Event software has an odd reliability profile. It may sit quiet for most of the year and then become operationally critical for a few hours, with no useful maintenance window once the queue starts. We therefore treated setup, incomplete setup, correction and recovery as ordinary parts of the workflow rather than admin edge cases.

The two source workbooks can arrive in either order. Participation is recomputed after every import, and if the member register is present before the full policy extract, the people on that register remain searchable through a fallback path. Staff do not have to understand the dependency graph or remember a special sequence. The screen also shows import history and row-level exceptions, so an upload that completed with rejected records cannot masquerade as a clean one.

Check-in itself is reversible but not erasable. An active check-in is preserved with its actor and time; an undo adds its own time instead of deleting the event. The same pattern applies to gift and refreshment pickup: the station blocks a duplicate and counts the blocked attempt. That distinction matters. On an event day, staff need a quick correction path, while the organisation still needs to know what happened.

The full search card is assembled in one server round trip, including participation, active check-in, a pending self check-in and pickup status. That was a performance decision, but also an interface decision: the person at the gate sees one complete answer rather than waiting for several panels to settle while the policyholder stands there. We also forced light mode after testing the phone interface in daylight. Small adaptations like that are not polish when the product is being used outdoors, under time pressure; they are part of whether it works.

Check-in averaged about 30 seconds per person, down from two to five minutes. Staff worked from their own phones, which removed the old two-laptop ceiling. Every staff member on the door became a lane.

Staff also reorganised around the tool in a way we hadn't planned. They split into two stations: one person checking the invitation (a human check, unchanged), and a second verifying the policy in the app. Gift and snack pickup ran faster still, on a station screen that blocks duplicate pickups and counts the blocked attempts.

Staff told us they wished they'd had it years ago, and kept calling it "really good software." They named the time saving themselves, unprompted. The executives got an Excel export where a handwritten logbook used to be, and the directors watched the attendance count move in real time on a phone during the meeting.

The gate app is not a second policy administration system. Staff cannot edit a name, product, status or address inside it. If the extract is wrong, the record is corrected at the source and uploaded again. That keeps one owner for policy data and prevents a hurried event-day correction from becoming a second, contradictory truth.

We also did not make the self-service route a public directory, and we did not automate the final identity decision. The QR page masks names and creates a pending request; a staff member still compares the person in front of them with the identity panel before admission. The app removes searching and transcription from the queue, not judgement.

Offline mode was considered and left out. The venue had connectivity, and synchronising competing offline check-ins would have introduced a new class of duplicate and reconciliation problems into a short-lived event workflow. A narrow tool with explicit boundaries was safer than a more impressive one whose hardest failure mode could not be exercised properly before the meeting.