Which parts of the run of show should a planner review after the event to improve the next one?
The timeline you planned and the timeline that happened are two different documents. Comparing them within a week is the cheapest way to make the next event better.

Capture the actual times before memory smooths them over
By the following Tuesday, everyone remembers the event as roughly on schedule. On the night, the ceremony started twelve minutes late, the entree fired fifteen minutes behind that, and the band's last set was cut short. Those specifics evaporate fast, which is why the most valuable review habit is simple: on the day, someone marks the actual start time next to each planned line. It takes a few seconds per cue and produces a record no memory can match. Related: How do event planners build a minute-by-minute run of show that actually keeps the day on schedule?
If nobody logged times live, reconstruct them the next morning from whatever exists: photo timestamps, the DJ's set log, the caterer's fire sheet, radio messages, the venue's door log. It will be imperfect, but a partial record is far more useful than a general impression. Save the annotated timeline alongside the original so the two can be laid side by side.
Keep reading: How do event planners build a minute-by-minute run of show that actually keeps the day on schedule?, How can a planner share the event day timeline with every vendor so nobody works from an old version?, What is the best way to adjust an event timeline on the fly when the day is running late?. See how GigTimelinr helps you event day-of run-of-show timeline builder.
The four questions worth asking about every drift
With planned and actual times in front of you, the review is a matter of looking at each point where they diverge and asking a small set of questions. Was the planned duration wrong, meaning the item genuinely needed more time than allotted? Was the start late because of an upstream delay, meaning this item was a victim rather than a cause? Was the buffer placed correctly, or was there slack somewhere else on the day that never got used? And did the owner of the line know they were behind, or did the drift go unnoticed until it compounded?
The answers sort drifts into categories with different fixes. A wrong duration becomes a template correction. An upstream delay points to the real culprit earlier in the day. Misplaced buffer becomes a structural change to where you put slack. And unnoticed drift usually means a communication fix: a check-in cue, a clearer owner, or a better way to share updates in the room.
Reviewing with vendors, not just about them
Vendors see parts of the event the planner never does. The caterer knows the kitchen was ready ten minutes before the room was. The photographer knows the family portraits ran over because three people were missing, not because the shot list was long. A short call or a few emailed questions to each key vendor within the week will surface causes that the planner's own notes miss, and vendors generally appreciate being asked. Related: Why should every moment in an event run of show have a clearly assigned owner responsible for it?
Keep those conversations specific. Rather than 'how did it go', ask 'the salad went down at 6:58 instead of 6:45; what were you seeing at that point?' Precise questions get precise answers, and they also signal that the planner is examining the plan rather than assigning blame. The relationships that make future events smooth are built in exactly these low-stakes conversations.
Turning the review into a better template
A review that ends in a notes document nobody reopens has not accomplished much. The output should be edits to the timeline template you will use next time: corrected durations, moved buffer, added cues, an extra line for the thing that was forgotten. If you run similar events repeatedly, the template becomes more accurate with each review, and the gap between planned and actual shrinks in a way you can literally measure by comparing annotated timelines across events. Related: What details and cues should a run of show include beyond just the times for each event moment?
This is one of the reasons we built version history and per-line notes into GigTimelinr: a planner can mark actual times on the day and see the drift immediately, then push the corrections into the template. Any approach works, including a printed timeline with pen marks and a spreadsheet, as long as the corrections land in the document you will actually use for the next event rather than in a folder of good intentions. Related: How can a planner share the event day timeline with every vendor so nobody works from an old version?
- Log actual start times next to planned times on the day, or reconstruct them from vendor records the next morning.
- For every drift, ask whether the duration, an upstream delay, buffer placement, or unnoticed slippage was the cause.
- Ask each key vendor specific, time-stamped questions within the week to learn what they saw.
- Push every correction into the template you will actually reuse, not into a notes file.
A run of show that holds
Event day-of run-of-show timeline builder. GigTimelinr is built to help you put this into practice.
Build your run of showGet the GigTimelinr playbook
Practical guides on event production, straight to your inbox as we publish them. No spam, unsubscribe any time.



