Insights · 14 September 2026 · 4 min read
The day always looks fine by five o'clock.
Event day has a way of hiding its own damage. The queue moves, the gate closes, everyone goes home tired and relieved — and the actual cost doesn't show up until someone opens the numbers three weeks later.
There's a particular feeling at about five o'clock on event day, once the last coach has gone and the site's emptying out, where everyone breathes out and says something like "well, that went alright." I've said it myself more times than I can count, usually while standing in a field holding a radio that's stopped crackling. And most of the time it's true — the day did go alright, in the sense that nothing collapsed in front of the public. But I've learned to be a bit suspicious of that feeling, because event day is very good at hiding its own damage until later.
The saves nobody writes down
Here's the thing about a good team on event day: they fix problems by making calls, not by following a script. A gate steward waves someone through without a proper scan because the queue's backing up onto the road. Someone on the phones tells a group they can swap their morning slot for the afternoon one because their coach broke down, and just says yes because saying yes is obviously the right thing to do at that moment. A supplier turns up short two vehicles and somebody reshuffles who's going where, on the fly, from memory.
None of that is a failure. That's the job done well. I'd rather have staff who make a sensible call under pressure than staff who freeze because the system doesn't have a button for it. We built our whole reputation on people who could do exactly that.
Where the call goes afterwards
The problem isn't the decision on the day. It's that the decision usually goes nowhere. It lives in someone's head, or a scribble on a clipboard, or a text message that gets deleted along with a hundred others once the phone fills up. The booking system still says the original slot. The finance sheet still expects the original coach count. As far as the record is concerned, the day went exactly to plan — because the only place the actual events of the day were captured was in the memory of whoever was holding the radio.
We ran on paper-and-memory for longer than I'd like to admit, and it worked, right up until it didn't. The days themselves were fine. It was always what came after that bit us.
The bill that arrives on a Tuesday
Three weeks later someone's reconciling the accounts and finds a coach that was paid for but never used, and a group that was moved onto it but never billed for the change. Someone's chasing a customer for a no-show fee, except they weren't a no-show, they were the ones who got waved through the gate to keep the queue moving. Someone's planning next season's capacity off a report that says Saturday's afternoon slot was quiet, when in fact it was rammed with people who'd been shuffled there by hand and never logged as such.
None of this shows up on the day. It shows up as a mismatch nobody can quite explain, a customer complaint that seems to come from nowhere, a forecast that's confidently wrong. The day looked fine because the improvising worked. The record is wrong because the improvising never got written down anywhere the system could see it.
What's changed the way I build things is treating the on-the-day override as a first-class action, not an exception to tidy up later. If a steward can wave someone through, there should be a five-second way to log it right there — not a form to fill in on Monday, something that takes less effort than not doing it. If a booking gets moved on the phone, that move should land in the same system the finance sheet reads from, the same afternoon. The goal isn't to stop people improvising. It's to make sure the system remembers what they did, at the speed they did it, so the good call on the day doesn't turn into a bad number on the Tuesday after.
What I'd actually check
If you want a rough test of your own setup, don't watch the queue on event day — watch what happens to a decision made in the queue. Follow one override, one manual swap, one exception someone made under pressure, and see how long it takes to reach the booking record, the finance sheet, and the supplier invoice. If the answer is "it doesn't, someone has to remember to key it in later," that's not a training problem, it's a design gap, and it'll find you at the worst possible moment — usually when the person who made the call has gone on to the next job and can't remember the details either.
If any of that sounds familiar, I'm happy to have a look and talk through what it'd take to close that gap — no pressure, just a conversation.
Written by Alex O'Neill— founder & lead product engineer, Pivot. About Alex →