Muse for Event Planners: Run-of-Show Drafts, Vendor Follow-Ups, and Day-of Checklists That Hold

An event is a deadline with a hundred moving parts and no undo button. The venue has its load-in window, the caterer needs a final headcount by a date that passed yesterday, the AV lead wants the run of show by Friday, the keynote speaker is flying in for one slot, and the guest list changed again this morning. None of those parts is hard on its own. The job is keeping them all current at the same time, and the failure mode is always the same: someone works from the version that was true last Tuesday.

That is why event planning is mostly coordination. Planners work 15 to 20 hour days during peak cycles, according to Cvent’s 2019 planner research, and most of those hours go to chasing confirmations and updating documents, leaving little time for the creative work that made the event worth doing. This lesson sets up three jobs that run the same way every time. Muse drafts the run of show from your agenda, runs the vendor chase on a schedule instead of on memory, and keeps the guest list, the day-of checklist, and the post-event recap in one place. You keep the judgment calls, the vendor relationships, and every send. Muse does the drafting, the tracking, and the first pass.

One rule holds the whole setup together: the run of show is the single source of truth, and every number in it traces back to a contract, a vendor email, or the registration system. A headcount comes from registration. A load-in time comes from the venue contract. A price comes from the vendor quote. That keeps a fast workflow honest, and it keeps a wrong number from reaching a vendor on the day it matters most.

The Setup: The Production Binder

Call the whole arrangement the Production Binder. I run a small events practice, three to five corporate events a quarter, 80 to 300 guests each, and every event lives in one binder. The binder holds the run of show, the vendor tracker, the guest list, the day-of checklist, and the post-event recap, and every page in it is built from a source, not from memory.

The setup rests on the same pieces every time. A standing instruction from our memory guide sets the house rules: never send anything to a vendor, a speaker, or a guest without a human read; never state a headcount, a time, or a price from memory; and never let two versions of the run of show exist at the same time. The agenda and the venue contract are the sources for the run of show. The registration system is the source for the guest list. The vendor tracker is one table, and the chase runs on a scheduled routine, the same shape as a Friday expense review: the same day every week, the same check, the same report of what is overdue.

Prompt 1: Build the Run of Show

Run this six to eight weeks before the event, as soon as the agenda is roughly locked, and fill in the details three to four weeks out. A run of show is the minute-by-minute production document the crew runs the day from: every cue, its clock time, its owner, and what the room is doing at that moment. It covers the performance window, usually two to three hours, and it is an internal document, built for the people running the event rather than the guests attending it.

The prompt anchors on the times that cannot move, then breaks the event into cues. Doors, the keynote slot promised to a speaker flying in for it, the catering window the venue locked in, and the hard stop when the room reverts to another booking are fixed points, and everything else hangs off them. Each cue gets a duration as well as a start time, so the times recalculate when something runs long. Each cue gets one named owner, a person rather than a department. Buffer goes in at 10 to 15 percent across the day, placed after Q and A sessions, before VIP segments, and at meal transitions, because transition time almost always runs longer than planned. Contingency rows are written as executable instructions, with a named decider and a decision time.

Build the run of show for [event name], on [date], at [venue], doors at [time], hard stop at [time]. The event runs [start] to [end] for [guest count] guests. Build it as a table with one cue per row and these columns: clock time, duration, cue, owner, talent or speaker, AV and media needs, and contingency note. Anchor on the fixed times first: doors at [time], keynote at [time], dinner service at [time], hard stop at [time]. Break every block into cues: doors and check-in, welcome, each talk, breaks, meals, awards, entertainment, close. Give every cue a duration in minutes and one named owner, a person, not a department. Add 10 to 15 percent buffer after Q and A sessions, before VIP segments, and at meal transitions. For the three highest-stakes moments, write a contingency row as an executable instruction naming who decides and by when, for example, “If the keynote speaker is not on stage by 2:05 PM, the MC opens networking, stage manager decides by 2:03 PM.” Do not invent a time, a speaker, or a vendor detail: anything missing goes in a “needed from me” list at the end.

Agenda and speaker details: [paste the agenda, speaker names, and talk lengths]. Venue constraints: [load-in window, catering window, curfew, room turnover]. Vendor details: [AV lead, catering lead, stage manager names].

Read the run of show against the agenda and the venue contract before it goes to anyone. The most common error is a cue built from a rounded time, a 30 minute keynote that runs 25 minutes with a 5 minute walk-on, or a break that forgot the room reset. A five minute error in one cue is a five minute error in every cue after it, and the crew discovers it on stage. Check the owner on every line too: a cue with no named owner is a cue nobody runs, and that shows up on the day.

Lock the document 48 hours before doors. Production teams treat that as a hard rule, because locking early forces last-minute changes through one gatekeeper instead of five people editing at once. After the lock, changes go through the show caller only, are communicated over headset, and get reflected in the document in real time. Give each vendor and each speaker a role-specific extract showing only their cues, so nobody has to scan a hundred rows to find the three that belong to them.

Prompt 2: Run the Vendor Chase

Run this on the same day every week, from eight weeks out to the day of the event. A corporate event with 200 guests can involve 15 or more vendors, venue, catering, AV, photography, transport, hotel room blocks, entertainment, and every one of them has its own timeline, contract terms, and way of communicating. The chase is the job of knowing, at any moment, which vendor owes what by when, and who has gone quiet.

The prompt works from the vendor tracker, one table with a row per vendor and per deliverable. It drafts the nudge for each overdue item, flags the vendor who has missed two deadlines, and writes the escalation: two nudges, then a phone call, then it lands on your desk. It pulls contract dates, certificates of insurance, final headcount deadlines, and load-in windows out of the vendor emails and contracts and into the tracker, so the tracker is current without anyone retyping it. Drafts go to you first. Nothing goes to a vendor without a human read, and nothing goes out under your name that you have not seen.

Vendor calls are still meetings, and they deserve the same treatment as any other: a short brief before the call, clean notes after it, and the action items tracked until they close. That is the pattern in our meetings guide, and it fits the vendor chase exactly, because a vendor call that ends without a written next step is a vendor call you will repeat next week.

Muse Academy Muse for Meetings, End to End: Pre-Meeting Briefs, Clean Notes, and Follow-Ups That Land

Run this week’s vendor chase for [event name], on [date]. Work from the vendor tracker below and the attached vendor emails and contracts. (1) For every deliverable due this week or overdue, draft a short nudge email to the vendor, in my voice, naming the deliverable, the deadline, and the one thing I need from them. Do not send anything. (2) Flag any vendor who has missed two deadlines or gone silent for more than [number] days, and draft a one-line escalation for me: call, not email. (3) Update the tracker: mark what is confirmed, what is still open, and what changed since last week. (4) List any contract date I have not yet put in the tracker: deposit due dates, final headcount deadlines, certificate of insurance expiry, load-in windows. Rules: every date and every price comes from a contract or a vendor email, never from memory. If a vendor email and the tracker disagree, say so and use the email.

Vendor tracker: [paste the tracker]. Vendor emails and contracts: [attach or paste the relevant ones]. My voice for nudges: [one example of a nudge you have sent before, or “short, direct, no fluff”].

Check the tracker against the contracts once a month, and check the nudge drafts against the actual relationship before they go out. The two errors this prompt can make are a date pulled from a superseded email, and a nudge that reads like a form letter to a vendor you have worked with for five years. The first one costs a missed deadline. The second one costs goodwill, and goodwill is what gets a vendor to move a load-in when the freight elevator breaks.

The same tracker holds the money. Deposits, final payments, and the contingency buffer, 10 to 20 percent of the budget on most events, live in the same table as the deliverables, so a vendor who is paid and a vendor who is confirmed are the same row. A vendor who is confirmed but unpaid is a vendor who can still cancel, and the tracker should show that plainly.

Prompt 3: Wrangle the Guest List, the Day-Of Checklist, and the Recap

Run the guest-list half of this prompt weekly from four weeks out, the day-of half the day before the event, and the recap half within a week after it. The guest list is the one document every other document depends on: the caterer needs the final headcount, the AV lead needs the seating plan, the venue needs the check-in list, and all three need the same numbers. Registration is the source. The prompt pulls the headcount, the dietary flags, the VIP list, and the no-shows from registration, and it says plainly when a number is a registration figure and when it is your estimate, because a caterer who plans for an estimate plans for the wrong dinner.

Out-of-town guests add a second list: flights, hotels, and transfers. The travel half of that list follows the same pattern as our trip planning guide, one itinerary per guest with the confirmation numbers attached, and the same rule: a confirmation number comes from the booking.

Wrangle the guest list and the day-of checklist for [event name], on [date]. Work from the registration export below. (1) Build the guest list summary: total registered, total confirmed, VIPs, speakers, staff, dietary flags with counts, accessibility needs, and no-shows, each with the count and the source date. Flag any guest whose dietary flag or accessibility need has no named owner. (2) Build the seating and check-in notes: table assignments if provided, the check-in list in alphabetical order, and the three guests most likely to need a personal greeting. (3) Build the day-of checklist: the run of show is already the schedule, so this list holds everything that is not a cue, venue keys and access codes, the printed run of show and contact sheet, petty cash, the backup AV kit, the speaker gifts, the photographer shot list, and the one person who holds the client phone. (4) After the event, draft the recap: what was planned against what happened, the final headcount against the registered count, the three things that went well, the two things to fix next time, and the thank-you drafts for the client, the speakers, and the vendors, each under 100 words.

Registration export: [paste it, or attach the file]. Seating plan: [paste it if it exists]. Client and speaker notes: [anything the registration export does not say].

Read the guest list against the registration export before the final headcount goes to the caterer. The most common error is a headcount that includes the staff, the speakers, and the plus-ones twice, or a dietary count pulled from last week’s export. A headcount that is off by twenty is a dinner that is short by twenty, and the caterer finds out at service.

The recap is where the binder pays for itself. The run of show, the tracker, and the guest list from this event become the template for the next one, and the two things to fix are the first two lines of the next event’s plan. If the event produced content worth sharing, a recorded talk, a photo set, a quote from the client, the repurposing follows the same pattern as our creators and podcasters lesson: one recording turned into clips, posts, and a newsletter, with every quote checked against the source.

What Can Go Wrong: The Stale Run of Show

Here is the failure mode you will meet first. The run of show goes out as version 3 on Tuesday, the client moves the awards sequence on Wednesday, and by Friday there are three versions in circulation: the master, the one the AV lead printed, and the one the caterer is working from. The keynote walks on at the time on the printed copy, the catering team is setting the awards dinner for the time on theirs, and the stage manager is calling cues from the master. No single person made a mistake; the document did, by existing in three places at once.

The cause is the one our failure modes guide describes: a fluent output that reads cleanly gets less checking than a rough one, and the checking it skips is the checking that would have caught the error. A run of show is the worst place for that pattern, because a hundred people act on it at the same minute, and none of them can see that the person next to them is reading a different version.

The fix has three parts, and all three are already in the prompts above. First, Prompt 1 builds one document, and the lock 48 hours before doors means changes after that point go through one person, the show caller, and get reflected in the document in real time. Second, every version carries a version number and a timestamp, and old copies get destroyed, because a filed old copy is a copy someone will find and use. Third, each vendor and each speaker gets a role-specific extract showing only their cues, so the document they hold cannot disagree with the master on the cues that belong to them. A run of show counts when one person owns it and one version exists; without that, it is a schedule that three crews are reading three different ways.

The same caution applies to the guest list. A headcount that lives in a spreadsheet, a registration export, and a catering email is three headcounts, and the caterer will cook for the one they saw last. One source, one number, one date on it.

Start With the Next Event

Do not build the whole Production Binder this week. Take the next event on your calendar, or the most recent one, and run Prompt 1 on the agenda you have now. Check every cue against the venue contract, read every owner against the actual crew, and put the buffer where the day will actually need it.

Run it that way and one event tests the run of show, the owners, and the buffer before the next one arrives.

The run-of-show practices in this lesson, the 48-hour lock, one cue per row, clock times rather than elapsed times, one named owner per cue, the 10 to 15 percent buffer, and contingency rows written as executable instructions with a named decider, follow the run-of-show guides published by ANT Management, Guidebook, and Event70. The 15 to 20 hour peak-cycle days come from Cvent's 2019 planner research, as summarized by Joi. The 15 or more vendors on a 200-guest corporate event is the working figure used by OpenClaw's event planning guide, and the 10 to 20 percent budget contingency is the range recommended in Studio Cube's event production guide.