One source of truth, many views
At 2:15 p.m. the florist arrives for a 4:00 ceremony, finds the loading dock blocked by the rental company's truck, and calls the planner. The planner is already on the phone with the caterer, who was told load-in was at 3:00 in an email from two weeks ago, before the timeline moved. The DJ has version four of the timeline as a PDF. The venue coordinator has version five. Nobody was careless. The schedule just lives in too many places.
A shared run-of-show fixes that: one timeline, one contact sheet, one list of what each vendor is responsible for, and one place where changes are announced, all readable on a phone at a loading dock. Here is how to design it before choosing any tool. TwoQM develops custom software, automation, CRM workflows, and connected systems for small businesses, including planners and venues whose day-of operations have outgrown a spreadsheet and a group text.
The core of a run-of-show is a timeline with an owner for every line. The mistake is sending that timeline out as a file. Files fork. Once a PDF is attached to an email, it is out of date the next time anything moves.
Instead, keep a single live record of the event and give each vendor a view of it. The planner sees everything. The caterer sees load-in, kitchen access, service times, the guest count, and the contacts they need. The photographer sees the ceremony start, the family photo window, and the sunset time the planner noted. Same data, filtered by role, always current.
What each line in the timeline needs
Here is an original illustration, not a TwoQM client or measured result. A planner running a 150-guest wedding reception in a hotel ballroom builds every timeline line with:
Time and duration. "3:00–3:45 p.m. catering load-in," not "afternoon."
Location detail. Which dock, which door, which service elevator, and where to park.
Owner. One vendor or staff member responsible, with a mobile number.
Dependencies. "Rentals must clear the dock before florist load-in." The system can show these as warnings when one line moves.
Status. Planned, confirmed by vendor, in progress, or done, with a timestamp when the vendor marks it.
Vendors confirm their own lines. When the florist taps "confirmed" on a 2:00 p.m. load-in, the planner stops wondering whether anyone read the email.
The contact sheet is part of the plan
A day-of contact sheet should not be a separate attachment. Build it from the same record: each vendor's on-site lead and mobile number, the venue coordinator, the security desk, and the one person who makes final calls. On a phone, every name should be one tap from a call or a text.
Keep each vendor's view limited to what that vendor needs. The DJ does not need the client's payment details or the full budget, and the caterer does not need every other vendor's contract.
Change notices that actually reach people
Timelines change. The ceremony gets pushed 20 minutes, rain moves cocktail hour indoors, the cake arrives early. The question is whether the right people find out.
This is where plain business automation pays for itself. When the planner moves a line, the system identifies which other vendors' lines depend on it, sends those vendors a short notice by text or email, and asks them to acknowledge it. The planner's dashboard shows who has acknowledged and who has not, so the follow-up call goes to the two vendors who haven't, not to all twelve. Every change is logged with the old time, the new time, and who made it.
AI can help with drafting, not deciding. A model can turn a planner's quick note ("rain plan: cocktails to Salon B, bar moves at 4:30") into a clear notice for each affected vendor, or summarize the change log at the end of the night. The planner reviews before anything is sent. Moving the timeline stays a human decision.
Built for a phone at a loading dock
Most day-of users are standing, carrying something, and working with a weak signal. Design for that: large tap targets, that vendor's next three items at the top, the venue map and dock instructions one tap away, and a bilingual view where crews prefer Spanish. In South Texas, a bilingual timeline is often the difference between a crew lead reading the change and guessing at it.
Think about what happens when the signal drops inside a concrete-walled ballroom, too. A view that keeps the last loaded timeline on the phone is more useful than a beautiful page that just spins.
Connect it to how you already book events
The run-of-show should not become a fresh data-entry job. If you track events and vendors in a CRM, the event record can create the run-of-show draft with the date, venue, guest count, and booked vendors already filled in. Vendor contacts come from the vendor records you already keep. After the event, the timeline and change log stay attached to that record for the next time you work with the same venue. That is the work TwoQM describes as connected systems.
Where to start this week
Take your next event's timeline and add an owner, a location detail, and any dependency to every line. Count how many versions of the timeline went out for your last event, and to whom. Then list which vendors need to see which lines.
If your planning team or venue wants a shared run-of-show built around how you already book events and vendors, TwoQM can scope it with you.