It's Thursday afternoon and the lighting tech for Saturday's wedding has just texted asking what time he can load in. The contract said 2 PM, but the venue's coordinator confirmed last week they'd moved the morning rehearsal back, so the actual call is 3 PM. The bride emailed yesterday with a change to the head-table layout that would shift where the uplighting needs to go. Your assistant has been running the corporate offsite that wraps Thursday night, and the gala timeline you've been sketching for the December event has the catering rep waiting on a callback.
Most event planners hold this in a combination of email threads, a couple of color-coded spreadsheets, and the working memory that gets sharper the closer the event gets. The shape works until two events overlap by 72 hours, at which point something always slips through.
This post is about what an event planner's working notes look like when the vendor list, the timelines, the day-of run-of-show, and the post-event learnings all live in one searchable place — and an assistant can actually read across all of it.
What planners need from a notes system
The shape is specific:
- Per-event continuity — a single workspace for each event holding the brief, the timeline, the vendors, the contracts, the seating chart, the day-of run-of-show
- Vendor relationships that span events — a florist you've used eight times, a DJ you've worked with twice, a caterer you're trying for the first time — each with their own page that accumulates context
- Cross-event pattern memory — the venue that always runs late on load-in, the AV company that requires final cue-sheets 72 hours out, the lesson learned from last September that the cocktail-hour timing always shifts
- Day-of operational sheets — the run-of-show, the call sheet, the emergency contacts, the vendor directory printed (or pulled up on a phone) the morning of
- Reference material — venue floor plans, vendor menus, contract PDFs, the inspirational images the client sent in February
Plus: it has to work on a phone. The day-of, you're walking the venue with a clipboard or a tablet. The system has to be readable and editable in that mode. Adjacent operational shapes — vendor coordination and day-of run sheets — show up in AI Notes for Construction Project Managers and AI Notes for Facilities Management.
Page-per-event, with a vault of vendor pages alongside
In Docapybara, every event gets a top-level page. The title is usually the client name, event type, and date — Garcia–Patel Wedding, 2026-09-12. Page nesting holds the structure underneath: brief, timeline, vendors, day-of, post-event review.
Separately, every vendor gets their own page in a vendors section. A common shape:
Events → 2026-09-12 Garcia-Patel Wedding → Brief, Timeline, Vendors, Day-Of, Post-EventEvents → 2026-10-04 Acme Corporate Offsite → same structureVendors → Florists → one page per floristVendors → Catering, AV, Photography, DJ/Music, Rentals, VenuesTemplates → reusable templates for brief, timeline, run-of-show, post-event review
Plain markdown means the pages are searchable, copyable, exportable. When the client asks for a copy of the day-of run-of-show, you can hand it over as text. When the venue's coordinator asks for the vendor list, you can paste it into an email.
A live vendor database that updates as you work
Embed a :::database::: directive on the event's Vendors page. Six column types — text, number, date, select, checkbox, link — cover most of what an event needs. A wedding vendor table might have:
| Vendor |
Role |
Contract Status |
Deposit Paid |
Final Due |
Load-In |
Cell |
| Bloom Studio |
Florist |
Signed |
Yes |
2026-09-05 |
2026-09-12 09:00 |
(415) 555-… |
| Element AV |
Lighting |
Signed |
Yes |
2026-09-10 |
2026-09-12 15:00 |
(510) 555-… |
| Hudson Catering |
Caterer |
Pending |
No |
2026-09-08 |
2026-09-12 13:00 |
(415) 555-… |
Sort by load-in time, you have the day-of arrival sequence. Filter by contract status, you see what's still open. When the lighting tech texts asking about call time, the answer is in the database, on the page, one tap away.
The same shape works for the master timeline — a database with rows for each milestone, columns for time, location, owner, status. The day-of run-of-show is the sub-page that pulls the timeline into a minute-by-minute version everyone on the team can read.
The agent reads across your whole event history
Capy, the assistant inside the workspace, can read across every event you've planned. The kinds of questions that get fast:
- "When I worked with Bloom Studio for the Henderson wedding last year, what did the post-event notes say about how their setup went?"
- "Pull every event I've done at the Hawthorne Garden venue and tell me what time the morning ceremony usually starts."
- "Across my last six weddings, which catering vendor had the lowest rate of last-minute headcount changes?"
Cross-event retrieval is where vendor relationships compound. The eighth wedding you do with Bloom Studio is materially better than the first because the workspace remembers exactly what worked at events three through seven.
The agent can also draft the routine pieces. "Draft a vendor confirmation email for the Garcia-Patel wedding, listing each vendor's load-in time and the venue contact, and pulling any vendor-specific notes from their pages." You review and send. Forty-five minutes of writing becomes five minutes of reviewing. The agent-acts-on-docs idea behind that is described in Claude Code for Documents.
Recording the discovery call so the brief writes itself
The discovery call with a new client is where the entire event takes shape — preferences, budget, must-haves, the photo from Pinterest the bride keeps coming back to, the awkward family-dynamic the groom mentions in passing. Most planners take notes by hand and then spend an hour after the call writing the brief from memory.
Drop the recording on the new event page. The transcript drops in with speaker labels — so when you replay it, you can see what the client said versus what their partner said versus what their mother-in-law (sitting in the third call) said.
Then ask the agent to draft the brief: "Read this discovery transcript. Pull out: (1) event basics — date, location, headcount, budget range, (2) preferences — color, style, vibe, (3) must-haves and dealbreakers, (4) family dynamics or sensitivities the client mentioned, (5) any vendor preferences. Format as a one-page brief."
The brief comes back in minutes. You review, edit, and send to the client for confirmation. The conversation that took ninety minutes becomes a brief in fifteen.
Old contracts, vendor menus, and floor plans
Most planners accumulate PDFs by the wedding — vendor contracts, catering menus, venue floor plans, COI certificates, the venue's house policies, the client's signed timeline. They're useful when findable and a problem when not.
Drop the PDFs into the event's page (or the vendor's page, depending on what they are). Each one is converted to markdown automatically, which means the agent can read across them. When you ask "what does the venue contract say about overtime past midnight?", the agent pulls the relevant clause as text. When you ask "does the caterer's COI cover the venue's required limits?", it cross-references the two.
The original PDFs are one click away when you need to see the signed version. The day-of, you can pull up the floor plan and the COI from your phone without digging through email attachments.
The day-of run-of-show
The run-of-show is the single most important page in the workspace on event day. It needs to be readable in low light, on a phone, while you're walking. A working format:
- Top of the page: emergency contacts, key vendor cells, the venue coordinator's name and number
- Minute-by-minute timeline as a database, sorted by time, with columns for time, what's happening, who owns it, where it's happening, and notes
- Below the timeline: contingency notes — what to do if the ceremony runs late, where the rain plan is, what the cue is for the cake cut
The day before, ask the agent to do the final pass: "Cross-check the timeline against each vendor's confirmed call time. Flag any conflicts or missing pieces." The agent reads across the vendors database and the timeline and reports what doesn't match. You resolve, finalize, and the run-of-show is locked.
The morning of, you (or your assistant, or the venue coordinator) opens the page and works the day from it. Updates happen in real time. After the event, the page becomes the source for the post-event review.
The post-event review that compounds
Every event ends with one short page: what worked, what didn't, what we'd do differently, vendor performance notes, anything to flag for the next time we work with each vendor.
Five minutes of writing the day after. Multiplied across a hundred events, this is what makes the eighth wedding with the same florist materially smoother than the first. The vendor's page accumulates the post-event notes from every event you've done with them. When you start planning the next wedding and you're considering them again, the agent can pull "every post-event note about Bloom Studio across the last three years, and any pattern in what went well or didn't" and you decide.
This is the layer that turns event planning from running on adrenaline into running on accumulated context. The day-of still requires presence and judgment. The lead-up gets calmer because the workspace already knows what it learned the last time. The repeatable-process layer specifically is covered in Standard Operating Procedures, Without the Wiki Maintenance Tax.
Try Docapybara free
The fastest test: pick the next event on your calendar that's at least four weeks out. Open Docapybara, create the event page, drop in the discovery-call notes (or the recording, if you have one), build the vendor database from your existing email confirmations, and let the agent draft the timeline and the day-of run-of-show. Try Docapybara free, bring one upcoming event and three vendor folders, and see whether the workspace can hold the shape of an event the way your sticky-note system currently does — only searchable.