1,100 RSVPs and one spreadsheet: event logistics is a systems problem

At 8:40 on the morning of Google I/O Extended Hanoi 2026 — 15 August — the check-in line went out the door, around the corner, and past the point where people could see the door. Doors had opened at 8:30. The keynote was at 9:00.

I was the person responsible for that line. Here's what I've learned, across that event and the ones since, that I think anyone who builds systems will recognise.

Watch on Facebook

Check-in is a queue, and you have to do the math

1,100 RSVPs. A bit under half show up to a free weekend event, so call it 500 people in the room. Almost all of them arrive in the 30 minutes between doors and keynote. That's about 15 people per minute at peak.

A volunteer scanning a QR code, finding the name, handing over a badge and a lanyard takes about 25 seconds if nothing goes wrong. That's 2.4 people per minute per lane. To clear 15 a minute you need seven lanes running at full speed with no problems. We had four.

Four lanes clear 9.6 people a minute against 15 arriving. The queue doesn't stay the same length — it grows by five people every minute, which is exactly what "out the door and around the corner by 8:40" looks like from the inside.

You don't need a queueing theory course to see the problem. But you do need to do the arithmetic before the day, and the first year I didn't. Now it's the first thing I do for any event: arrival rate ÷ service rate = lanes, then add 50% because things go wrong.

Backpressure: what to do when the queue is longer than the room

When a service is overloaded you have three options: add capacity, shed load, or slow the input. Same at a door.

Add capacity: we split lanes by first letter of last name — fewer people per lane, faster lookup, and the sign tells people where to go so a volunteer doesn't have to. Later we added a fast lane for people who'd pre-downloaded their QR (service time drops to ~10 seconds).

Shed load, gracefully: anyone in line at 8:55 got waved into the hall with a "check in at the break" sticker. The keynote starting on time with people in seats matters more than every badge being correct at 9:00. A degraded check-in is better than a delayed event. That's graceful degradation, and it needs to be decided in advance — you can't make that call well while 300 people are staring at you.

Slow the input: stagger. Email the day before with "doors 8:30, keynote 9:00, come at 8:30 if you want good seats" produces a spike at 8:30. "Check-in opens 8:00, coffee's ready" spreads it. The wording of one email is a rate limiter.

The spreadsheet is the database, so treat it like one

Everything ran off one Google Sheet: RSVPs, check-in status, volunteer shifts, speaker arrivals. It was, honestly, the right tool — everyone can open it, it works on phones, and it has version history. But a shared sheet with 15 people editing it at 8:45 has the same failure modes as any shared mutable state:

• Two volunteers checked in the same person because both searched the name at once. Fix: the check-in form writes a row; the sheet is derived. Append-only log, materialised view. It's a database pattern and it's also just "don't let people edit the master list by hand".
• A volunteer sorted the sheet and every row's meaning shifted under everyone else. Fix: freeze the header, protect the ranges, and give volunteers a filtered view, not the sheet.
• Nobody knew the current state because the state was spread over three tabs. Fix: one "Now" tab with the numbers that matter — checked in, in line (estimated), volunteers on shift, next milestone — updated by formula, read by everyone.

Evy, our task-management agent, exists partly because of mornings like this one: the sheet is fine as storage, but asking questions of it through Chat is a much better interface for 15 people on their phones than opening the sheet is.

Runbooks beat heroes

The first year, the answer to every problem was "find Phuong". That doesn't scale, and it's a single point of failure with a phone at 3% battery.

Now every event has a runbook: one page per role (door lead, hall lead, speaker liaison, floater), with what to do for the ten most likely problems. "Speaker's slides won't load → USB in the podium drawer, backup PDF in the shared folder, tell the MC to stretch 3 minutes." Most of the runbook is written by AI now — I describe the venue and the schedule and ask for the failure list, then spend my time fixing what it gets wrong about this room (it never knows where the fuse box is). That's a much better use of an organiser's attention than writing the 80% that's the same every time.

The test of a runbook: can a volunteer who joined two days ago handle the door for an hour while I'm dealing with the missing extension cords? Since the runbooks, yes.

Observability for rooms

You can't fix what you can't see. Two things changed how I run the day:

A shared "Now" channel in Chat where every lead posts a one-line status every 15 minutes: "Door: line ~40, 3 lanes, no issues." "Hall: 620 seated." It's logging. It means I can tell from across the venue whether the door needs me.

Postmortems, the blameless kind. Within 48 hours, the team writes down what went wrong, what we'd change, and what we'd keep. The 8:40 line is in there. So is the fix. The next event's runbook is built from the last event's postmortem. That loop — ship, observe, write it down, ship again — is the same one I use for software, and it's the reason I don't think of "organiser" and "engineer" as two different jobs.

What I'd take to the next one

Three lanes short is not a staffing problem, it's an arithmetic problem, and arithmetic is available the week before. The fast lane for pre-downloaded QR codes did more for the line than an extra volunteer would have. And the degradation policy — wave people in at 8:55, check them in at the break — was the only decision that morning I didn't have to make under pressure, because I'd made it the day before.

If you're about to run your first event with more than a few hundred people: do the queue arithmetic, decide your degradation policy the day before, make the sheet append-only, and write the runbook so it's not you. The rest is lanyards.