Repository navigation
Ops Manual
Venue Operations Manual
A plain-English guide to booking shows, running nights, and closing events — written for the people who actually do the work.
System: Panic Backstage
Audience: Management & Staff
Edition: June 2026
Status: Living document — updated as the system evolves
How to Use This Manual
Think of Panic Backstage as having two guides: the Reference (the ? help icons inside the app that explain every field) and this — the Learning book that walks you through whole workflows from beginning to end.
When you're staring at a field you don't recognize, click the ? link next to the section heading to open the in-app reference for that area. When you want to understand why something works the way it does, or how all the pieces fit together across a show's lifecycle, that's what this manual is for.
Panic Backstage is the internal management system for your venue. It tracks every show from the moment someone asks "are you free on the 14th?" all the way through settlement and closing the books. It's the single source of truth — what's in Backstage is what's real.
Staff access Backstage through a web browser. Most things you'd want to do during a show (check in guests, scan tickets, look up the run sheet) work fine on a phone.
📋 The Three Workflows
This manual covers the three major workflows in order:
Chapter 1 — Booking: From the first inquiry call to the contract signed and date locked.
Chapter 2 — Run of Night: Everything that happens the day of the show, from load-in to last call.
Chapter 3 — Post-Event: Settlement, archiving, and closing the books.
Backstage has three ways to look at your shows, and you'll use all of them:
| View | Best for | How to get there |
|---|---|---|
| Calendar | Seeing what's booked on a given date; spotting conflicts | Events → Calendar in the sidebar |
| Pipeline | Seeing where every active show stands in the booking process | Events → Pipeline |
| Events List | Searching, filtering, and quickly jumping to a specific show | Events → List, or use the search bar at the top |
💡 Quick search
The search bar in the top header works across all events. Type a band name, date, or artist and it'll find it immediately — no need to navigate to the list view first.
Part I
From the first inquiry to an approved deal — before an event even exists in the system.
Chapter 1
Most bookings don't start as events — they start as leads. The Lead Pipeline is where you evaluate inquiries, run the numbers, and decide what to book before anything hits the calendar.
Before an event is created, most bookings start as a lead — an inquiry or opportunity that needs evaluation. The Leads Inbox (sidebar nav → Leads) shows all leads in a pipeline view.
The inbox table shows the following columns:
| Column | What it shows |
|---|---|
| Title | The lead name or inquiry description |
| Source | Where the inquiry came from |
| Contact | The inquiring party's name |
| Date | Expected or requested event date |
| Status | Current pipeline stage |
| Margin % | Projected deal margin from the Deal Evaluator (if calculated) |
| Actions | Quick links to open, convert, or decline |
Status filter tabs across the top let you narrow the view: All | New | Triage | Evaluating | Needs Review | Approved.
Needs Review badge
A Needs Review badge appears on the sidebar Leads link when leads are stalled and need manager attention. The dashboard card Leads Needing Review shows the count for venue admins so nothing slips through.
Each lead has a source that tracks where the inquiry originated. Available sources: Website, Promoter, Peerspace, Eventective, Giggster, Phone, Email, Manual. This data is preserved for reporting — over time you can see which channels generate the most bookable leads.
Click
+ New Lead to open the create form. Required fields:
New Lead — Required Fields
| Field | Description |
|---|---|
| Title | A descriptive name for the inquiry. e.g. "The Midnight — July booking inquiry" or "Corporate holiday party". |
| Event Type | Concert / Private Event / Festival / Comedy Show / Other — affects which evaluation fields appear. |
| Venue | Which room or configuration is being requested: Upstairs, Downstairs, or Both. |
| Contact Name | The person or organization making the inquiry. |
Optional fields: contact email, source, expected event date, description/notes. The lead starts in new status and appears at the top of the New tab immediately after saving.
Each lead has a status that tracks where it is in the evaluation process. Status buttons on the lead detail panel advance (or close) the lead:
New
Inquiry received, unreviewed
The lead just came in. No action taken yet.
Acknowledged and gathering info ↓
Triage
Acknowledged; gathering details
You've made contact and are collecting the information needed to evaluate the deal.
Actively running numbers ↓
Evaluating
Deal Evaluator is open; numbers being run
You're actively using the Deal Evaluator to assess margin, break-even, and risk. A lead can be converted to an event from this status if the deal is ready.
Waiting for management sign-off ↓
Needs Review
Awaiting manager sign-off
Numbers are done. A manager needs to review and approve before booking proceeds. This status triggers the dashboard badge.
Greenlit — ready to book ↓
Approved
Deal greenlit — ready to convert to event
Management has approved. Click Convert to Event to create the booking.
Terminal statuses: Declined (not a fit — preserved for reporting) · Canceled (went cold without a formal decline)
Declining vs. canceling
Use Declined when you've actively decided not to book the inquiry — you had the information and said no. Use Canceled when the inquiry simply went cold — the contact stopped responding or withdrew without a formal decision. Both are preserved in the system for reporting purposes; neither is deleted.
On the lead detail panel, the right column is the Deal Evaluator — a financial projection tool that tells you whether a show is worth booking before you commit to it.
Deal Evaluator Inputs
| Field | Description |
|---|---|
| Room capacity | The hard legal limit for the room. Used to flag if attendance assumptions exceed the room. |
| Expected attendance | Your projected headcount. The key variable — small changes here move the numbers significantly. |
| Ticket price | Advance ticket price. Used to calculate gross ticket revenue and break-even. |
| Ticket fee per ticket | Service/processing fee charged on top of the ticket price (if any). Added to ticket revenue. |
| Rental fee | For private events — the flat venue rental amount. |
| Artist guarantee | The artist's minimum guaranteed payment, regardless of ticket sales. |
| Projected bar spend | Your estimate of bar revenue for the night based on expected attendance and historical averages. |
| Bar minimum | The minimum bar commitment (if any). The higher of bar spend and bar minimum is used in the calculation. |
| Labor forecast | Estimated total labor cost for the night (security, bar staff, door, etc.). |
| Production costs | Sound, lighting, backline, staging. |
| Facility costs | Cleaning, utilities, equipment wear. |
| Other costs | Anything else that isn't covered by the above categories. |
Click
Calculate — all math is done server-side. Never trust a browser total for booking decisions.
| Line | Formula |
|---|---|
| + Gross Revenue | (attendance × ticket price) + (attendance × fee) + rental + max(bar spend, bar minimum) |
| − Estimated Cost | guarantee + labor + production + facility + other |
| = Venue Net | Gross Revenue − Estimated Cost |
| Margin % | (Venue Net / Gross Revenue) × 100 |
| Break-even tickets | ⌈Estimated Cost / Ticket Price⌉ — must sell this many to cover fixed costs |
| Minimum guarantee tickets | ⌈Guarantee / Ticket Price⌉ — tickets needed just to cover the artist |
After calculating, the evaluator shows color-coded risk badges on the results panel:
| Flag | Severity | What it means |
|---|---|---|
| Negative margin | Red | Costs exceed revenue at projected attendance — this show loses money as modeled |
| Venue net negative with guarantee | Red | The venue is upside-down — the guarantee alone exceeds the projected net |
| Low margin under 15% | Yellow | Positive but thin — any shortfall in attendance or bar will push it negative |
| Attendance below break-even | Yellow | The projected headcount doesn't cover fixed costs — you're counting on selling more than expected |
| Bar spend below minimum | Yellow | The bar minimum kicks in — use the minimum figure, not the projection, in your net calculation |
| Projected attendance exceeds capacity | Orange | The attendance assumption exceeds the room's legal limit — not a valid scenario |
Model your scenarios
Run the evaluator at multiple attendance levels: your best case, your realistic case, and your floor case (70% of expected). A deal that only works at full capacity is riskier than one that works at 70%. The evaluator saves your last calculation — you can adjust inputs and recalculate as many times as you need.
When a lead is in approved status (or evaluating if the deal is ready to go), click
Convert to Event.
Backstage creates the event in a single transaction:
- A new event record is created using the lead's details (title, event type, venue, expected date)
- The lead is linked to the event with a permanent reference
- Audit notes are written on both the lead and the new event
- You're taken directly to the new event workspace to continue setup
After conversion, the lead is marked converted and becomes read-only. Its evaluation data — all projections, risk flags, and the calculation results — is preserved permanently on the lead record for audit and historical comparison against the actual settled numbers.
The lead lives on
Converting a lead does not delete it. A venue admin can always navigate back to the original lead from the event workspace to see what the deal looked like at evaluation time — useful for post-show retrospectives comparing projected vs. actual margin.
Part II
From the first inquiry to the contract signed and date locked in the system.
Chapter 2
The booking process is a pipeline. Every event enters at the bottom (Hold) and works its way up. The system enforces what you need at each step — no contract, no Booked status.
Inquiries come in by email, phone, web form, and sometimes someone just walking in the door. Regardless of how it arrives, the first thing you do is create an event in Backstage. Don't wait for details to be confirmed. Getting it in the system — even as a stub — is what holds the date.
The calendar color-codes by room:
- Downstairs — orange tones
- Upstairs — blue tones
- Additional spaces — green tones
Putting an event on Hold blocks the date visually on the calendar, but it does not commit the venue. A Hold means "this date is being considered." It becomes a firm commitment at Booked — which requires a signed contract.
Click the
+ New event button in the top-right corner of the screen. This opens the Event Creation Wizard — a 7-step guided form that collects everything needed for a new show: event basics, deal structure, contact details, financial terms, production requirements, and promotion settings. When you finish, the wizard creates both the event and a pre-populated contract draft in one click. This is the recommended path for any show that will have a booking agreement.
If you need a quick placeholder first and want to deal with the contract separately, click ⚡ Quick Create instead in the wizard's sidebar. A compact modal appears: pick a template (or Blank event), confirm date, title, and door/show times, and click Create event. The new event opens immediately in its workspace. Any date already entered in the wizard carries over to the modal.
The most important decision you make at creation time is Event Type. This changes how the event behaves throughout the system:
🎵 Public Show
Live music, DJ night, comedy, open mic, karaoke, etc. Has a full pipeline including promotion, ticketing, and a public event page. Uses Producer/Artist and Booker contacts.
🔒 Private Event / Rental
Corporate parties, birthday rentals, film shoots, album release parties, etc. Never publicly listed. Uses a Client contact. Has a shorter pipeline — no promotion stages.
Once you set the type to Private Event, both the wizard and the Quick Create modal change layout to show client fields instead of booker/artist fields. For detailed private event instructions, see Private Event Rentals later in this chapter.
Whether you use the full wizard or the Quick Create fallback, these are the minimum fields the system requires to create an event and hold the date:
Quick Create Modal — Minimum Fields
Title
*
Summer Kick-Off feat. The Midnight
Date
*
2026-07-12
Location
*
Your Venue — Downstairs
Event Type
*
Live Music
Doors
*
7:00 PM
End Time
*
11:00 PM
⏰ Time auto-fill
If you set Doors, the system will automatically suggest Show time (1 hour after doors) and End time (5 hours after doors) if you leave those blank. You can always override. This saves time on common show formats.
Most shows are a single night. Some aren't — a two-day festival, a weekend private rental, a multi-day workshop or artist residency. For those, set an End Date alongside the regular Date and the event spans every calendar day from Date through End Date instead of just one.
You can set End Date in the wizard's Event Basics step, in the Quick Create modal, or later from the event's own
Details tab. Leave it blank (the default) for an ordinary single-day show — the field only matters when it's filled in.
📅 How it looks on the calendar
Instead of a single day's chip, the event renders as one continuous chip spanning every day in its range, on both the monthly calendar and the agenda view.
🚪 Room conflicts
The room is considered booked for the entire range. Another booking that overlaps any day inside that span — not just the first day — will be blocked as a conflict.
Everything else about the event — contract, staffing, ticketing, guest list, settlement — stays attached to that single event record exactly as it would for a normal show. A multi-day event is still one event; it just occupies a wider footprint on the calendar.
💡 Not the same thing as a recurring event
Multi-day is one event spanning several consecutive days (a festival). A recurring event is several separate events on a repeating schedule (a weekly karaoke night) — each with its own date, contract, and staffing. See the next section.
A recurring series is not a single event that magically reappears on multiple dates. Every occurrence is created as its own fully independent event — its own contract, staffing, ticketing, guest list, and status ladder. Occurrences are linked only so the app can show you the rest of the series and let you jump between them. Editing, cancelling, or rebooking one occurrence never touches any of the others.
There are two ways to spin one up:
- From the event wizard — check Recurring Event on Step 1, Event Basics. The pattern is applied right after the first event is created, so the whole series exists by the time you finish the wizard.
- From an existing event — open its Details tab and use the Recurrence panel underneath it. This turns that single event into the first occurrence of a brand-new series. (An event that's already part of a series can't be turned into the start of a second one.)
The weekday (for weekly patterns) or day-of-month (for monthly patterns) is always taken from the date you're starting from — nobody picks it separately, so the pattern can never disagree with the date it was built from.
Recurrence picker
Repeats
Weekly — every other week — on Tuesday
Ends
After 12 occurrences
Supported patterns:
- Weekly — every week, every other week, every 3rd week, or every 4th week, on whichever day of the week the starting date falls on (e.g. "Every other Tuesday").
- Monthly by weekday — the same ordinal weekday every month (e.g. "First Thursday of the month", or "Last Friday of the month").
- Monthly by date — the same day-of-month every month (e.g. "the 15th").
An end condition is required — either after N occurrences or on a specific date — and the total is capped at 52 occurrences per series. A live preview lists the dates that will be created so staff can double-check before committing.
Every generated date is checked against existing bookings at that venue, exactly like a normal event create. If any date in the pattern conflicts with an existing booking, nothing is created — you'll see an error listing which date(s) collided so you can adjust the pattern (a different weekday, a shorter range, fewer occurrences) and try again.
Open any occurrence's
Details tab — the Recurrence panel lists every sibling in the series with its date and status, and links to jump straight to any of them. If one occurrence needs to drop out (it was cancelled, moved to a different venue, whatever), use Remove this event from the series on that occurrence. It becomes a fully standalone event again; the rest of the series is unaffected.
💡 No bulk edit across a series
There's no "change this and all future occurrences" action. Each occurrence is a completely normal event once created — update its time, venue, staffing, contract, or anything else the same way you would for any other show, one at a time.
Every event automatically gets a scannable QR code linking straight to its public page — no third-party QR generator needed. It shows up in two places: inline on the public page itself, next to the flyer, and in a QR Code panel you can pop open from the event header (next to Public Page).
📱 Header panel
Click QR Code in the event header. The panel shows the code, the link it encodes (click the field to copy it), a Download PNG link, and a Save to Assets button.
🖨️ For flyers & print
Click Generate QR code in the event's Assets panel — or Save to Assets in the header panel — to save it as a downloadable PNG asset (a qr_code type, alongside flyers and photos).
Regenerating replaces the event's existing QR asset in place rather than piling up duplicates — there's only ever one qr_code asset per event.
🔗 The link never goes stale
The code encodes the event's stable, id-based public URL rather than its title-based slug, so a code printed weeks ago keeps working even after the title or date changes and the slug changes with it.
Generating or regenerating a QR code requires the upload_assets capability — the same gate as uploading any other asset.
Every event moves through a defined sequence of statuses. You can't skip ahead — the system enforces what's required at each transition. Think of statuses as checkpoints that protect you from letting something slip through.
Here's the full pipeline for a public show:
Hold
Date informally blocked
Inquiry received; date held on the calendar. No commitment yet.
All contact info confirmed ↓
Intake Complete
Details confirmed; contract being built
Deposit, capacity, ticket price, and age restriction locked in. The venue admin drafts the contract.
Contract signed/approved ↓
Booked
The show is happening — firm commitment
Contract on file. The date is locked. Assets and promo work begins.
Promo stages: Needs Assets → Published ↓
Published
Public event page is live
Tickets on sale. Promotion running across channels.
Show date passes — auto-archived ↓
Archived
Show happened; settlement pending
Set automatically the morning after the event date. Settlement team notified.
Settlement filed ↓
Settled
Books closed
Settlement filed and approved. This event is done.
Note: Any event can be moved to Cancelled at any time, which removes it from the calendar view.
When a Hold is created, the system enforces a minimum set of information. You cannot save a Hold without these fields filled in:
- Event name
- Date
- Event type
- Location / Venue
- Doors time
- End time
- Producer/Artist name
- Producer/Artist email
- Producer/Artist phone
- Booker name
- Booker email
- Booker phone
📞 Producer/Artist vs. Booker
The Producer/Artist is the person putting on the show — the band, the DJ, the comedy promoter. The Booker is the person at the venue (or agent) who arranged the deal. These can be the same person. Both are required at Hold because the automatic email notifications need them.
Once the Hold is saved, the event appears on the calendar with a colored chip showing the event name and door time. Other staff can see the date is taken.
Intake Complete means all the financial and logistical details are confirmed and you're ready to build the contract. Think of it as the "everything we need to write the deal" checkpoint.
To advance from Hold to Intake Complete, you must have the following on top of the Hold requirements:
Required for Intake Complete
| Field | Description |
|---|---|
| Deposit amount | The dollar amount of the deposit agreed to. This will appear in the contract. |
| Ticket price | The advance ticket price for the show. Required so the contract and ticketing setup can reference it. |
| Capacity | The hard maximum attendance. This is a venue and safety constraint — not an estimate. |
| Age restriction | e.g. "All Ages", "18+", "21+" — affects door operations and contract language. |
When the status changes to Intake Complete, the system automatically emails venue admins with a notification so they can begin contract drafting.
💡 Load-in time
While not strictly required for Intake Complete, this is a good time to confirm and enter the
Load-In / Tech time. The band's crew and sound tech need to know their call time, and it shows on the calendar chip so operations staff can see it at a glance.
Booked is the biggest gate in the pipeline. An event cannot reach Booked status without a contract on file. The system checks the Contracts tab — if there's no contract in approved, sent, or signed status, the status change will be blocked.
When a show reaches Booked:
- The date is locked — the system treats this as a firm commitment
- All venue admins are notified
- The event moves from the "pending" part of the pipeline to the "active show" section
- The next step is getting promotional assets from the producer
Contracts live in the
Contracts tab inside the event workspace. The system has a built-in deal builder — you don't write the contract from scratch, you fill in the terms and the system assembles the document.
In the Contracts tab, click
+ New contract. You'll be prompted to choose a template. For most shows, you'll use one of these:
| Template | When to use |
|---|---|
| Promoter / Production Show | External promoter producing the event. Split-revenue or flat-rental deal. |
| Artist / Band Performance | Direct booking. Band plays for a guarantee and/or door split. |
| Famous / High-Draw Artist | Headline shows with larger guarantees, radius clauses, and hospitality riders. |
| Private Event Rental | Venue rental — corporate, personal, or private event. |
| Recurring Night Agreement | Monthly or weekly residency. Has recurrence, review, and termination terms. |
After choosing a template, the system will pre-populate smart clauses based on the deal terms. For example: if the show is "All Ages," the underage admission clause is automatically included. If there's a bar minimum, the bar minimum clause appears. You can add or remove clauses from the list.
Contracts move through two phases. First, the draft phase (internal review and approval), then the e-sign phase (sent out, signed by all parties, and fully executed). Each phase has its own status progression:
Draft phase
Draft
→
Needs Review
→
Approved
→
Ready to Send
E-sign phase
Sent
→
Viewed
→
Partially Signed
→
Signed by Client
→
Countersigned
→
Fully Executed ✓
Terminal states (can occur at any point):
Voided
Declined
Expired
Cancelled
Superseded
The event can be moved to Booked once the contract reaches Approved status or better. When a contract reaches Fully Executed, the event is automatically advanced to Booked.
Before you can mark a contract as Sent or Signed, every required field in the included clauses must be filled. The system will show you a list of what's still missing. Common ones: marketing_deadline, insurance_amount, and the guarantee amount if there's a guarantee clause.
Every contract has two parties: the venue and the counterparty — whoever is on the other side of the deal.
| Scenario | Counterparty is… |
|---|---|
| Band / artist booking | The artist, band, or their booking agent |
| Promoter deal | The external promoter or event organizer |
| Private / venue rental | The client or their organization |
Set the counterparty in the contract editor using the
Counterparty Name,
Organization, and
Email fields. The name and organization combine on the printed contract — e.g., "Chris Robison (The Panic Band)". The email address is used when you send the contract.
📋 Private events auto-fill the counterparty
For private events, the counterparty name and organization are pulled from the Client / Primary Contact fields on the event. You don't need to enter them again — just confirm they're correct when you open the contract editor.
Once the contract has content, two export buttons appear at the top of the contract editor:
| Button | What it does |
|---|---|
| ⬇ Download PDF | Generates a formatted PDF on the server and downloads it to your device instantly. Works on all platforms — desktop and mobile — because the PDF is built server-side. Use this when you need to email the file or keep a copy on record. |
| 🖨 Print / Save PDF | Opens the contract in a new browser window, formatted for print. Use your browser or OS print dialog to save as PDF or send to a printer. Best on desktop. |
📱 Exporting on a phone
Use Download PDF on mobile devices. The Print option relies on your device having a print-to-PDF option in its system print dialog — which not all phones support. Download PDF bypasses that limitation entirely.
Panic Backstage has a built-in electronic signature system — no DocuSign or third-party account required. Once a contract is approved, you send it for signature with a single click. Each signer receives a secure, personalised email with a time-limited signing link. When all parties have signed, the system generates a tamper-evident Final Executed PDF — the legally authoritative copy — and automatically advances the linked event to Booked.
📋 No account needed for signers
The counterparty and other external signers do not need a Backstage account. They sign directly through a public link (/sign.html?token=…). The link is personalised, single-use, and expires after the configured time window (default 7 days).
- Open the contract in the builder. It must be in Approved or Ready to Send status and have no missing required terms.
- Click Send for Signature in the right-hand panel. A confirmation dialog appears showing the signer list — name and email address for each party.
- The counterparty's details are pre-filled from the contract's Counterparty fields. Add, remove, or edit signers as needed. You can include extra signers such as a guarantor or an artist representative.
- Click Confirm & Send. Each signer receives a personalised Please sign: [Contract Title] email with a Review & Sign button.
- The contract status advances to Sent. The Signers panel in the right rail shows each signer's live status: Pending, Viewed, Signed, or Declined.
| Signer status | Meaning |
|---|---|
| Pending | Email sent; signer has not yet opened their link |
| Viewed | Signer opened the link and saw the contract |
| Signed | Signer completed and submitted their signature |
| Declined | Signer clicked Decline (a note may be attached) |
The
Send for Signature button is disabled if any required clause variable is still blank. Use the Review panel to find and fill what's missing before sending.
When a signer clicks the Review & Sign button in their email they land on a clean, mobile-friendly signing page. Here is what happens:
- The full contract text is displayed for review.
- At the bottom, two signing methods are offered side by side:
- Type Signature — the signer types their name; it is rendered in a cursive font as a legal signature.
- Draw Signature — a canvas lets them draw their signature with a mouse or finger.
- The signer checks the consent box: "I agree to use electronic records and signatures for this agreement…"
- The Sign Agreement button becomes active once a method is chosen and consent is given. Clicking it records the signature.
- A confirmation screen thanks the signer and notes when the fully-executed copy will be emailed to them.
If the signer decides not to sign, they can click
Decline at any time. A short dialog lets them leave an optional note explaining why. You will be notified by email and the contract status will reflect the decline.
📱 Works on any device
The signing page is optimised for phones and tablets. The draw canvas is touch-enabled and renders at full device pixel ratio for crisp signature images on retina screens.
These actions are available in the Signers panel on the right side of the contract editor, visible once the contract has been sent.
| Action | When to use | Effect |
|---|---|---|
| Resend link | Signer says their link expired or they deleted the email | Generates a fresh signing link for that signer only and re-sends the email. The old link is immediately invalidated. |
| Void contract | Terms changed significantly; deal fell through; wrong contract sent | Cancels the signing process, invalidates all outstanding links, and records a reason. Status becomes Voided. You must start a new contract to re-engage. |
| Countersign | All external signers have signed (status = Signed by Client) | Admin provides their own typed or drawn signature to countersign on behalf of the venue. Triggers final PDF generation and event advancement. |
Voiding a contract cannot be undone. All outstanding signing links become invalid immediately, and any signer who tries their link will see a message that it is no longer valid. If you need to fix terms and re-send, create a new contract (you can copy the deal terms) and send that one instead.
Every action on a contract is recorded in an immutable Audit log. Open it from the contract editor's right rail by clicking
Audit log. The log captures:
| Field | What it contains |
|---|---|
| Action | The event that occurred: contract_sent, contract_viewed, contract_signed, contract_declined, contract_voided, countersigned, fully_executed, and others. |
| Signer | Name and email of the person who triggered the action, or Admin for venue-side actions. |
| Timestamp | The exact date and time (UTC) the action occurred. |
| IP address | The IP address from which the signing action was performed. Useful for legal or dispute purposes. |
| User agent | The signer's browser/device string. |
📋 Append-only
The audit log is append-only at the database level — no entry can ever be edited or deleted. It is reproduced in full on the last page of the Final Executed PDF as the audit certificate, giving both parties a permanent, self-contained record of every step in the signing lifecycle.
When a contract reaches Fully Executed status, Backstage generates a single locked PDF that becomes the authoritative contract record. It contains:
- The full contract body exactly as it was approved — no edits are possible after the first signer signs.
- A signature block for each signer showing:
- Their typed or drawn signature (reproduced at full quality)
- Full name, title (if provided), and company
- Date, time, and IP address of signing
- A final Audit Certificate page listing every lifecycle event from contract creation through full execution.
- A document hash — the SHA-256 fingerprint of the PDF bytes, stored in the database so the file's integrity can be verified at any time.
To download the final PDF, open the contract and click
⬇ Download Final PDF in the right rail. This button only appears on contracts in Fully Executed status.
💡 Verifying the document hasn't changed
The SHA-256 hash shown in the audit log and stored in the database lets you confirm the downloaded PDF is the original, unmodified copy. If the file's hash matches the database record, it hasn't been tampered with. If they differ, treat the file as suspect and contact Backstage support.
📋 Email notification when fully executed
When a contract is fully executed, each signer automatically receives a Your agreement is signed email with a link to download their copy of the final PDF. Venue admins receive a separate notification confirming the execution.
The system sends emails automatically at key moments. You don't have to remember to do these — they happen when the status changes. Here's the full map:
| When | Who gets an email | Why |
|---|---|---|
| Status → Intake Complete | Venue admins | Signal to begin contract drafting |
| Status → Booked | All venue admins | Firm booking confirmation |
| Status → Needs Assets | Producer + Booker | Request for flyers, press photos, social images |
| Event date passes | Settlement team | Reminder to file settlement (auto-archive notification) |
| Contract e-signature notifications | ||
| Contract sent for signature | Each signer | Personalised Please review & sign email with their signing link |
| A signer signs | All venue admins | Confirmation of who signed, with a link to the contract |
| Contract fully executed | All signers + venue admins | Congratulations email with link to download the final executed PDF |
| Contract voided | All venue admins | Notification that the contract was voided and the reason given |
Private events are venue rentals: corporate parties, birthdays, film shoots, wedding receptions, album releases, and similar occasions. They behave differently from public shows throughout the system.
- No public page — private events are never listed publicly and have no ticket purchase page
- No promotion — the Promote, Needs Assets, and Published stages don't exist
- Shorter pipeline — Hold → Intake Complete → Booked → Archived → Settled
- Different form — uses Client / Primary Contact fields instead of Producer/Booker
- Venue admin auto-assigned — a venue admin is automatically set as the event owner on creation
- Visual distinction — shows a 🔒 lock icon on the calendar chip and event header
Private Event — Client / Primary Contact fields
| Field | Description |
|---|---|
| Name | The client's full name — the person responsible for the rental. |
| Used for the automatic confirmation email when the event reaches Booked status. | |
| Phone | Contact number for day-of coordination. |
| Organization | The company, family, or group booking the venue. Appears in the contract as the counterparty. |
| Estimated guests | Expected headcount — different from Capacity (the hard maximum). Both fields exist separately. |
| AV / Tech requirements | Sound system, lighting, projector, microphone needs. Used for venue setup and staffing. |
| Catering / Bar notes | Bar service preferences, outside vendors, alcohol restrictions. |
💰 Rental pricing
For rental pricing guidance, contact venue management. The approximate ranges are Downstairs ~$2,000/day and Upstairs ~$3,000/day, but actual quotes depend on the event type, duration, and requirements.
When a private event is confirmed (status → Booked), the client automatically receives a "Your event is confirmed" email at the address listed in the Client / Primary Contact field.
Private Event Booking Checklist
- Create event and set Type to Private Event
- Fill in client name, email, phone, and organization
- Enter date, load-in time, doors time, and end time
- Note AV / tech requirements
- Note catering / bar preferences
- Advance status to Hold (system confirms minimum fields)
- Confirm deposit amount and estimated guest count
- Advance to Intake Complete
- Build contract using the Private Event Rental template
- Get contract approved or signed
- Advance to Booked — client receives automatic confirmation email
Backstage and the connected tracking spreadsheet stay in sync automatically. You don't need to update both — changes in Backstage push to the sheet within seconds, and the sheet feeds back into Backstage every five minutes via a scheduled sync.
Fields the system writes back to the sheet when you update them in Backstage:
- Event status (as a human-readable label)
- Potential revenue
- Ticket system
- Contract URL
- Walk-through done (Yes/blank)
- Ticket URL
- Settlement document URL
📊 Sheet is the source for some fields
The spreadsheet is the source of truth for referral source, promoter name, title, date, and room assignment — the system won't overwrite those when it syncs. Backstage is the authority for everything else.
An event cannot move to booked status without two gates cleared:
-
Fully executed contract — the contract must be in
signedorfully_executedstatus. A sent, partially signed, or draft contract is not enough. -
Deposit received (or waived) — the deposit status must be
received,waived, ornot_required.
The
Payments tab in the event workspace tracks all money movements: deposits, balance payments, refunds, credits, and adjustments.
Click
+ Add Payment to record a payment. Each payment record includes:
Payment Record Fields
| Field | Description |
|---|---|
| Payment type | Deposit, Balance Payment, Refund, Credit, or Adjustment. |
| Direction | Inbound (money coming to the venue) or Outbound (money going out). |
| Amount | Dollar amount of the payment. |
| Due date | When the payment is expected. Overdue deposits appear on the dashboard. |
| Payment method | Check, wire transfer, ACH, cash, credit card, etc. |
| Notes | Any relevant details — check number, confirmation code, who delivered it, etc. |
When a deposit payment is marked received, the deposit_status updates automatically to received and the gate opens — the event can now be advanced to Booked (assuming the contract is also executed).
Some events don't require a deposit — longtime promoters, house-produced shows, or venue-discretion bookings. To waive the deposit requirement:
- Requires the
waive_depositcapability (venue admin by default) - A mandatory reason must be entered — it cannot be left blank
- The waiver is permanently audited: who, when, and why
- Once waived, the deposit gate is cleared and the event can proceed to Booked
Legacy events
Events created before the deposit gate was introduced default to not_required and are unaffected by the gate. They can be advanced to Booked without a deposit record. This ensures no historical events are retroactively blocked.
Deposits Overdue dashboard card
The dashboard card Deposits Overdue highlights deposit payments that are past their due date. Check this weekly — an overdue deposit often means a follow-up call is needed before the event can be fully locked.
Part III
The day of the show. From load-in to last call.
Chapter 3
The best-run shows aren't spontaneous — they're planned in detail and then executed smoothly. Backstage gives you the tools. Here's how to use them.
"Advancing the show" means confirming every detail with the artist or producer before they arrive. Ideally this happens 48–72 hours out. It's the conversation that prevents surprises.
Before day-of, make sure the following are confirmed in Backstage:
Pre-Show Advance Checklist
- Load-in time confirmed with production
- Run sheet drafted and reviewed
- Full staffing roster confirmed (no TBD shifts)
- Guest list finalized (or at least opened for the band)
- Ticketing scanner link created (if using in-house ticketing)
- All open items resolved or assigned
- Walk-through done checkbox checked (if venue walk-through happened)
- Print the Master Event Packet (optional but recommended)
🖨️ Print the packet
Click the
Print ▾ menu in the event workspace header and choose Master Event Packet. This generates a single printable document with the run sheet, staffing schedule, band lineup, and guest list — everything the floor team needs in paper form if phones die.
The Run Sheet is the minute-by-minute schedule for the night. It lives in the
Schedule tab of the event workspace. Think of it like the stage manager's bible — if it's not on the run sheet, it doesn't exist.
Each item on the run sheet has:
Run Sheet Item Fields
| Field | Description |
|---|---|
| Item | The name of the schedule item. Be specific: "The Midnight — Main Set" is better than "Band". |
| Type | Category of item: load_in, soundcheck, doors, set, changeover, curfew, staff_call, other. |
| Start | When this item begins. |
| End | When this item ends. Used to calculate changeover time and curfew compliance. |
| Notes | Anything the floor team needs to know about this item. "No fog machine during this set" or "Need 15 min for stage change". |
| Time | Item | Type | Notes |
|---|---|---|---|
| 3:00 PM | Load-in opens | load_in | Stage door open, sound tech on site |
| 4:00 PM | Opening act soundcheck | soundcheck | 45 min max |
| 5:00 PM | Headliner soundcheck | soundcheck | 60 min |
| 6:00 PM | Changeover / Dinner break | changeover | Crew break. Bar opens at 7. |
| 7:00 PM | Doors open | doors | All staff at posts |
| 8:00 PM | Opening Act | set | 30 min set. No encore. |
| 8:30 PM | Changeover | changeover | Stage crew 20 min |
| 8:50 PM | Headliner — Main Set | set | 90 min. Hard curfew 10:30 PM. |
| 10:30 PM | Curfew | curfew | Music off. Last call. |
| 11:30 PM | Venue clear | other | All guests out. Crew strike. |
📋 Adding items
Click the
+ Add run sheet item button in the Schedule section header. To edit an existing item, hover over the row and click the pencil icon that appears. Changes save immediately.
Staffing lives in the
Staffing tab. Shifts are drawn from the staff roster in Admin → Staff. Each shift has a role, call time, end time, hourly rate, and status.
Staff roles available:
Manager
Security
Bartender
Barback
Door
Sound
Lighting
Stagehand
Runner
Cleaner
Other
Shift statuses tell you at a glance what the staffing situation looks like:
| Status | What it means |
|---|---|
| Scheduled | On the schedule but not yet confirmed by the staff member |
| Confirmed | Staff member has confirmed they'll be there |
| Declined | Can't make it — need to find a replacement |
| No Show | Didn't show up. Set this on the night for accurate records. |
| Completed | Worked the shift |
| Canceled | Shift removed |
The staffing header shows a summary: "8 shifts · 7 confirmed · 1 TBD" — so you can see at a glance if you're still short-staffed.
A shift with no staff member assigned is marked TBD. These need to be filled before the show. You can print the staffing schedule from the Print menu to share with your floor manager.
The guest list lives in the
Guest List tab. Entries are grouped by list type: VIP, Press, Industry, Comp, Guest, and Will Call — in that priority order for the door.
| Type | Who it's for | Notes |
|---|---|---|
| VIP | High-priority guests, sponsors, ownership | First to be let in, often get wristbands |
| Press | Photographers, journalists, media | May need photo pass coordination |
| Industry | Other venue staff, agents, managers attending as guests | Professional courtesy list |
| Comp | Free ticket holders — issued QR tickets via the ticketing system | Should have a digital ticket to scan at door |
| Guest | General guest list — names left by the band | Most common type |
| Will Call | Paid tickets held at the box office | Customer paid but didn't print or download |
Each guest has a check-in checkbox in their row. Checking the box marks them as admitted and updates the count in real time. The header shows: "14 entries · 20 seats · 11 checked in (15 seats)" — giving you a live headcount at a glance.
📱 Works on phones
The guest list check-in works well on a mobile browser. Open the event in Backstage on a phone, go to the Guest List tab, and your door person can check guests in live. The check-in updates the headcount immediately for anyone else looking at the same event.
Each guest entry has a
Party field. When a band puts "The Midnight +3" on the list, add the guest as "The Midnight" with a party size of 4. The system will count 4 seats even though it's one entry — which is important for capacity tracking.
If the event is using in-house ticketing, you can issue a comp QR ticket directly from the guest list. Next to any guest with an email address, you'll see an
Issue comp button. Clicking it creates a ticket and emails the QR code to the guest. The ticket will appear in the Comp section of the ticketing dashboard.
If the event uses in-house ticketing (not TIXR), ticket holders receive a QR code by email. The door team scans these with the Backstage scanner.
- Go to the event's Ticketing tab
- Scroll to Scanner Links and click Create scanner link
- Give the link a label (e.g., "Main Door", "Side Entrance") and optionally set a PIN
- Copy the secret URL — it's only shown once
- Open that URL on the door device's browser to get the scanner
🔑 Scanner secret is shown only once
The scanner link secret (the URL with the embedded token) is only displayed at creation time. Copy it immediately and paste it somewhere safe (or open it on the door device right away). If you lose it, revoke the link and create a new one — there's no way to retrieve the secret after you navigate away.
The scanner shows a camera viewfinder that reads QR codes. It also has a manual text entry field for situations where the camera can't read the code (e.g., screen glare, damaged phone display). Every scan — admitted, already used, or invalid — is logged in the audit trail.
| Result | What it means | What to do |
|---|---|---|
| ✅ Admitted | Valid ticket, first scan | Let them in |
| This QR was scanned before | Ask to see the ticket email; check for duplicate | |
| ❌ Void | Ticket was canceled/refunded | Do not admit. Direct to box office. |
| ❌ Not found | QR code not in the system | Could be wrong event; check the ticket email |
| ❌ Wrong event | Valid ticket but for a different show | Direct them to the correct venue/date |
Once the show is running, the two tools you'll use most are:
The
Open Items tab is for anything that needs follow-up — "Get the band's set list for social posting," "Follow up on missing deposit check," "Confirm encore permission with the artist." These don't fit neatly into tasks but need to be tracked. Mark them Resolved when done. Unresolved items show on the Overview tab readiness indicator.
The Overview tab (the first tab in the workspace) shows a Readiness section — a live checklist of whether the event is in good shape. It checks things like: are all tasks done? Are there open items? Has the event been published? This is your dashboard for "how ready is this show?"
💡 Next Recommended Action
Just below the event summary on every event page, there's a Next Recommended Action card that tells you the single most important thing to do next for this event. Click
Refresh to update it as things change throughout the night.
The
Vendors tab in the event workspace tracks every external vendor associated with the event: caterers, photographers, security firms, AV/lighting companies, DJs, florists, transportation providers, and anyone else you're bringing in.
Click
+ Add Vendor to create a vendor entry. Required: vendor name and service category. Optional: contact info, quote amount. The entry is saved to the event immediately.
To edit an existing vendor row, click
Edit and update amounts (quote → approved → actual) and COI details inline.
The venue requires a COI from vendors who bring equipment or staff on-site. The COI status on each vendor row reflects where the certificate stands:
| Status | Meaning | Gate cleared? |
|---|---|---|
not_required |
No COI needed — software vendors, remote services, any vendor without on-site presence | Yes |
pending |
COI requested but not yet received from the vendor | No |
received |
COI is on file — vendor is cleared | Yes |
expired |
COI passed its expiry date — vendor must renew before working the event | No |
Expired COIs block vendor clearance
A vendor with an expired COI should not be permitted on-site with equipment or staff until they provide a current certificate. Update the COI status to received and note the new expiry date once the renewal is in hand.
Each vendor has a payment status that tracks whether they've been paid:
| Status | Meaning |
|---|---|
| Unpaid | No payment issued yet |
| Invoiced | Invoice received; payment pending |
| Paid | Payment issued |
| Refunded | Payment was returned |
When a vendor confirms day-of attendance, mark them Confirmed on their row. This feeds into the closeout checklist — the Vendors Confirmed item won't clear until all on-site vendors are confirmed.
The totals row at the bottom of the vendor list shows aggregate Quote, Approved, and Actual cost summaries — useful for tracking how actual spend compares to what was estimated at booking time.
COI policy is set in Admin
The venue-wide COI requirement is configured in Admin → Venue Policy. If COI is set to required globally, all on-site vendors should have received status before the event date. See Venue Policy in the Admin chapter for details.
During the event, the
Execution tab captures a timestamped log of everything that happens. Think of it as the real-time incident and change log for the night — permanent, structured, and available to the right people.
| Type | Color | When to use | Financial impact? |
|---|---|---|---|
| Incident | Red | Fights, medical events, property damage. Restricted visibility — only staff with view_incidents or manage_incidents capability can see these records. |
No |
| Change Order | Blue | Scope changes from the agreed plan. If a dollar amount is entered, a cost ledger entry is automatically created. | Yes — auto-creates ledger entry |
| Bar Note | Green | Bar performance observations: early/late close, pace notes, pour complaints, running low on product. | No |
| Damage | Orange | Property damage with estimated repair cost. | Yes — auto-creates a cost entry |
| Overage | Purple | Costs that ran over plan. | Yes — auto-creates a cost entry |
| Checklist | — | Run-of-show checkpoint notes. | No |
| Deviation | — | Departures from the agreed plan that don't rise to the level of an incident or change order. | No |
| Safety Note | — | Venue safety observations that should be on record. | No |
| General | — | Anything that doesn't fit the above categories. | No |
Click
+ Add Record. Each record requires a type and a summary (required). Optional: a body (longer narrative — collapses to 2 lines in the list, click to expand), and a financial impact amount.
Restricted flag on incidents
Incident-type records can be marked Restricted at creation time. Only staff with the view_incidents or manage_incidents capability will see restricted records. Other staff members see that a record exists but not its contents. Use this for sensitive matters — medical events, altercations — where visibility needs to be controlled.
Execution records with financial impact don't just live in the Execution tab — they flow into the event's financial ledger automatically:
- Change orders with a dollar amount appear in the Closeout ledger as cost entries
- Damage records auto-create a cost entry in the ledger with the repair estimate
- Overages create a cost entry matching the amount entered
This means the night-of team can document what happened in real time, and the closeout team picks up accurate numbers without manual re-entry.
Part IV
After the last guest leaves: settlement, archiving, and closing the books.
Chapter 4
The show is over. Now you count the money, pay the bands, and close the books. Here's how the system handles the end of an event's life.
You don't need to manually close out shows. Every morning, the system checks whether any active events have a date that's already passed. If an event is in any active status (Booked, Published, etc.) and its date is in the past, the system automatically moves it to Archived.
When an event is auto-archived:
- The status changes to Archived
- The settlement team receives an email reminder to file settlement
- The event moves to the "past shows" section of the pipeline board
- The public event page is hidden (if it was live)
📅 When does it happen?
The auto-archive cron runs every morning. So if your show was Saturday night, expect the event to be archived by Sunday morning. If an event date passes and the show was canceled, it will also be archived — so check the status after archiving if you need to record a cancellation instead.
Settlement is the financial close-out of a show. You're reconciling what came in (ticket sales, bar) against what went out (expenses, band payments, promoter payout) to arrive at what the venue actually made.
The settlement process has two parts:
- The night-of settlement doc — the physical or digital tally sheet done at the end of the show, often a Google Sheet or a handwritten form. The person running money tracks sales and expenses in real time during the event.
- Entering it in Backstage — once the night-of doc is finalized, those numbers get entered into the Settlement tab so the system has a record.
🔗 Link your settlement doc
In the Settlement tab, there's a field for
Settlement document — a URL or note pointing to your night-of tally (e.g., a Google Sheets link). Paste it here. This connects Backstage to the source document and also syncs the URL back to the connected tracking spreadsheet.
Open the event workspace and click the
Settlement tab. You'll see a form with the following fields:
| Line | Formula |
|---|---|
| + Gross Ticket Sales | + total ticket revenue |
| Tickets Sold | count (for records) |
| + Bar Sales | + bar revenue attributed to event |
| − Expenses | − production, staffing, supplies |
| − Band Payouts | − total paid to all performers |
| − Promoter Payout | − promoter share (if applicable) |
| = Venue Net | = what the venue keeps |
Click
Calculate venue net and the system will fill in the bottom line automatically from the numbers above. You can also let it calculate in real time as you type — the Venue Net field updates as you change any of the input fields.
📝 Notes field
The settlement form has a Notes textarea at the bottom. Use it to record anything unusual about this settlement — partial payments, disputed amounts, payment method, or explanations for numbers that look off. This is the paper trail that saves you six months from now.
Settlement Fields
| Field | Description |
|---|---|
| Gross Ticket Sales | Total ticket revenue before any splits or fees. If using Panic Booking, this number comes from the ticketing dashboard. If using TIXR, pull from their settlement report. |
| Tickets Sold | Count of paid tickets (not comps). For reference and reporting — doesn't affect the venue net calculation. |
| Bar Sales | Bar revenue for the event. Use whatever figure your POS system reports for the show period. |
| Expenses | Production costs, staffing, security, catering, equipment rental, and any other out-of-pocket costs for this show. |
| Band Payouts | Total paid to all performers — guarantees, door-deal payouts, merchandise advances, etc. |
| Promoter Payout | Promoter's share, if any. On house-produced shows this is 0. On external promoter shows, this is the promoter's agreed cut after expenses. |
| Venue Net | Calculated automatically: Gross Ticket Sales + Bar Sales − Expenses − Band Payouts − Promoter Payout. This is what goes to the venue. |
Once settlement is filed and approved by the accounting team, manually change the event status to Settled. This is a deliberate manual step — it requires a human sign-off, not just data entry.
To change the status, go to the
Details tab, find the Status dropdown, and change it to Settled. The system will save automatically.
Settled events are:
- Hidden from the active pipeline board
- Permanently in the events list for historical reference
- Searchable by name, date, or artist
- Still auditable — the activity log preserves everything that happened
Post-Event Close-Out Checklist
- Confirm event auto-archived (check morning after show date)
- Retrieve night-of settlement doc from the floor manager
- Paste the settlement doc URL into the Settlement tab
- Enter all settlement figures: ticket sales, bar, expenses, payouts
- Click Calculate venue net and verify the number looks right
- Add any notes about unusual circumstances
- Click Save settlement
- Verify Google Sheet received the settlement doc URL (column S)
- Get accounting sign-off
- Change status to Settled
Every event has an
Activity tab that records everything that happened to it — who changed what, when, and from what to what. This is your audit trail.
The activity log records:
- Status changes (with before/after values)
- Field edits (with old and new values shown inline)
- Contract status changes
- Tasks created or completed
- Assets uploaded or approved
- Guest list additions and check-ins
- Settlement saves
Each entry is written in plain English and tells you the full story on one line. A single-field change looks like this:
status changed from "hold" to "booked"
by Christopher Robison Jun 17, 2026
When a single save touches multiple fields — for example updating the deposit amount and the ticket price at the same time — the entry lists each changed field underneath it:
event updated
by Christopher Robison Jun 17, 2026
deposit_amount from "500" to "750"
ticket_price from "20" to "25"
Long values are clipped to keep the log readable. Hover over a clipped value (shown with a dotted underline) to see the full content in a tooltip.
💡 It's read-only on purpose
The activity log can't be edited or deleted. That's intentional. When there's a question about who changed something, when, or why — the answer is in the activity log. It's your protection against "I didn't change that" disputes.
For settlement disputes or accounting questions, the activity log on the event is the first place to check. You can see exactly when the settlement was filed, who filed it, and what the numbers were at the time.
In summary — the full event lifecycle
Inquiry arrives → Create event in Backstage → Hold (date blocked) → Fill in financial details → Intake Complete (contract drafting begins) → Contract signed → Booked (firm commitment) → Assets collected → Needs Assets / Published (tickets on sale, promo running) → Show happens → Archived (auto, morning after) → File settlement → Settled (books closed)
Every step is tracked, every change is logged, and the Google Sheet stays in sync throughout.
Part V
After the last guest leaves: the financial ledger, the checklist, and closing the books for real.
Chapter 5
The Closeout replaces the old Settlement form with a full financial ledger workflow — append-only line items, a seven-point checklist, and a finalize button that locks the books when everything checks out.
After the event ends and it's been archived, the
Closeout tab in the event workspace becomes the primary workspace. It replaces the old Settlement form with a structured financial ledger workflow.
The Closeout panel has two columns:
- Left column — the financial ledger: every revenue and cost line item for the event
- Right column — the P&L summary and the 7-point closeout checklist
The event cannot be marked Settled until the seven-point checklist is complete and the ledger is finalized.
Events Awaiting Closeout
The dashboard card Events Awaiting Closeout shows all completed (archived) events that don't yet have a finalized closeout. Check this regularly — events should be closed out within a few days of the show, not weeks later when memories have faded.
The closeout ledger is the authoritative financial record of the event. Every financial fact is a ledger entry — there are no free-text totals or settlement form fields to overwrite.
Append-only: no edits, no deletes
The ledger is append-only. Once a line item is saved, it cannot be changed. To correct a mistake: void the incorrect entry (it stays visible with strikethrough so the correction is traceable) and add a new corrected entry. This ensures a complete audit trail — every number that was ever entered is visible.
| Type | What it represents | Affects P&L? |
|---|---|---|
| Revenue | Money coming in to the venue | Yes — adds to Gross Revenue |
| Cost | Money going out | Yes — adds to Total Costs |
| Payment | Money movement tracked separately from P&L (deposits, balance payments, refunds) | No — tracked under Payments Received |
Tickets · Ticket Fees · Bar Sales · Rental Fee · Hosted Bar · Merch Share · Sponsorship · Equipment Rental · Overtime Charge · Other Revenue
Artist Guarantee · Promoter Settlement · Labor · Sound/Production · Security · Cleaning · Rentals · Catering · Vendor Cost · Processing Fees · Taxes · Refunds · Other Cost
Deposit Received · Balance Payment · Refund Issued · Credit Applied · Adjustment
The right panel shows the running totals, always calculated server-side:
| Line | Formula |
|---|---|
| + Gross Revenue | Sum of all Revenue line items |
| − Total Costs | Sum of all Cost line items |
| = Venue Net | Gross Revenue − Total Costs |
| Margin % | (Venue Net / Gross Revenue) × 100 |
| Payments Received | Sum of inbound Payment line items |
Venue Net is displayed in green when positive and red when negative — so the financial health of the event is unmissable.
Execution records auto-populate the ledger
Change orders, damage records, and overages entered in the Execution tab during the show automatically create corresponding ledger entries. Review these on the morning after — they may need a void-and-correct if the initial amounts were estimates.
Before the ledger can be finalized, seven items must be checked off. Each checkbox updates the server immediately when clicked — no save button needed.
7-Point Closeout Checklist
- Contract Signed — a fully executed contract is on file for this event
- Deposit Received — the deposit was received (or waived)
- Vendors Confirmed — all on-site vendors have confirmed day-of attendance
- Staffing Confirmed — all scheduled shifts are in Confirmed or Completed status
- Bar Closed — bar has been closed out and receipts collected
- Cash Reconciled — any cash sales or payments have been counted and reconciled
- All Invoices Collected — outstanding invoices from vendors have been received
The
Finalize button remains disabled until all seven items are checked. This is enforced server-side — checking boxes in the UI does not unlock finalization if the server-side state disagrees.
Checking items requires manage_ledger
Checking off closeout checklist items requires the manage_ledger capability. Venue admins have this by default. If a staff member is helping with closeout and cannot check items, their account needs this capability added.
Once all seven checklist items are checked, click
Finalize. Finalizing:
- Locks the ledger — no new entries can be added and no existing entries can be voided
- Sets the event status to
settled - Records the finalizer's name, timestamp, and the final P&L snapshot
- Removes the event from the "Events Awaiting Closeout" dashboard card
Finalizing requires the finalize_closeout capability (venue admin by default).
Finalization locks the books
Once finalized, the ledger is read-only. Reopening is possible but audited and requires a mandatory reason. Don't finalize until the numbers are right — verify the P&L summary against your night-of records before clicking Finalize.
If something was missed after finalization — a vendor invoice arrived late, a damage charge needs to be added — click
Reopen. Reopening requires:
- The
finalize_closeoutcapability (venue admin) - A mandatory reason — it cannot be left blank
The reason and timestamp are permanently recorded in the audit trail. After reopening, the ledger is editable again and the event falls back onto the "Events Awaiting Closeout" dashboard. When corrections are complete, finalize again.
Reopen is audited forever
Every reopen — who did it, when, and why — is permanently stored. This prevents "just fix the numbers quietly" situations and gives your accounting team a clear record of any post-finalization adjustments.
Part VI
Turn a confirmed booking into a coordinated promotion across 20 channels — social, listings, email, and press — all from one screen.
Chapter 6
Promotion isn't just posting to Instagram. It's a coordinated campaign across social media, event listing sites, email, and press — all timed and tracked. Panic Promote makes sure nothing falls through the cracks.
Panic Promote lives in its own section of the sidebar, separate from the event workspace. Navigate to Promote in the left nav and you'll see a card for every upcoming event. Each card shows how many posts have been created, how many days until the event, and the campaign's overall status.
Click
Open on any card to enter that event's promotion command center. You can also jump straight there from inside an event workspace by clicking the
Promote button in the event header.
📌 Only public shows have a campaign
Private events (venue rentals) do not appear in Panic Promote. The Promote button is hidden for private events. This is intentional — private events are never publicly advertised.
Each campaign overview is split into two columns:
- Hero card — event details, key metrics (days out, post count, goal), and campaign status
- Posts — all your posts, with thumbnails, status badges, and action buttons
- Promotion Health — a 20-item checklist with a score
- Assets — approved flyers and band photos
- Analytics — broadcast metrics (opens, clicks, reach)
A post is the central unit of work in Panic Promote. Think of it as one piece of content — an announcement, a reminder, a "last tickets" alert — that gets adapted into different versions for different channels. One post, 20 channel variants.
Click
+ New Post in the campaign header or the Posts section. You'll fill in:
Post Fields
| Field | Description |
|---|---|
| Title | Internal name for this post. e.g. "Announcement" or "Week-before reminder." Never shown publicly. |
| Master Text | The core message in plain language. This is the source material the system adapts into channel-specific variants. Write it like you'd write a social post — it doesn't need to be polished yet, just capture the facts. |
| Target URL | The link you want people to click — usually the ticket page or the event's public page. |
| Asset | The image to attach — a flyer or band photo from the Assets tab. Set this before generating variants so each channel variant includes the right image reference. |
| Status | Draft → Approved → Scheduled → Sent → Archived. Approve a post to indicate it's ready to broadcast. |
After creating a post, open it and switch to the
Channel Variants tab. You'll see a tab for each supported channel. Click
Generate variants to let the system create a version for every channel at once, adapted to each platform's tone, character limit, and format.
The 20 channels are organized into four groups:
| Group | Channels | How they work |
|---|---|---|
| Direct Posts | Instagram, Facebook, TikTok, Twitter/X, Threads, Bluesky | Connected via API credentials. Click Broadcast to post automatically. |
| Event Platforms | Eventbrite, Luma, Dice.fm, Resident Advisor | Creates a listing on the platform. Some (Eventbrite, Luma) can be API-connected; others require manual submission with the generated copy. |
| Editorial Submissions | Funcheap, Foopee, SF Chronicle, SF Station, DoTheBay, SongKick, JamBase, Press | Editorial listings and press pitches. Always manual — copy the generated text and submit to the site. |
| Email List, Ad-hoc Email | Email List sends to your Mailchimp/SendGrid connected list. Ad-hoc sends targeted one-off emails to press, VIPs, or specific contacts. |
Each variant has its own character count (so you don't accidentally send a 500-word tweet), its own status (draft / ready / needs_review / approved), and a save button. Edit each variant independently — the system's generated text is a starting point, not the final word.
✍️ Character limits are enforced
Each channel shows a live character count as you type, and turns red if you exceed the limit. Twitter/X is 280 characters. Bluesky is 300. Threads is 500. Instagram captions can be 2,200 characters but shorter performs better. The system knows all of these — don't worry about memorizing them.
Once posts and variants are approved, you broadcast them. Click the
Broadcast button on any post card, or click the main
Broadcast button in the header to open the broadcast modal without a pre-selected post.
The broadcast modal shows all your connected destinations grouped by type, with a readiness indicator for each. You choose:
- Which destinations to send to (check the ones you want)
- When to send — Now or Scheduled (pick a date and time)
- Which post to attach (if you opened the modal from the campaign header)
Destinations show one of three readiness states:
✓ Connected
API credentials are set up. One click to post.
⚠ Needs auth
Credentials haven't been set up yet. Go to Settings → Promote to connect this platform.
ⓘ Manual submission
No API connection exists for this channel. The system generates the copy; you paste it into the site manually.
📋 Manual destinations still count
When you submit a manual destination (like Funcheap or SF Chronicle), Backstage still records that you did it. This is what marks those items as "done" in the Promotion Health checklist. Even though there's no API, the tracking is real.
The Promotion Health card on the right side of the campaign overview is a 20-item automated checklist. It gives you a single score (0–100%) showing how complete your promotion is. It's the answer to "what haven't we done yet?"
The checklist checks these 20 items, in priority order:
| # | Item | Detail |
|---|---|---|
| 1 | Panic event page published | The public event page is live. This is always the first step. |
| 2 | Approved flyer exists | At least one asset of type "flyer" with status "approved" is in the Assets tab. |
| 3 | Instagram announcement post approved | A post has an approved Instagram variant. |
| 4 | Facebook event/promo post approved | A post has an approved Facebook variant. |
| 5 | Eventbrite listing prepared | A broadcast to Eventbrite has been created. |
| 6 | Luma listing prepared | A broadcast to Luma has been created. |
| 7 | Funcheap submitted | Manually submitted to Funcheap (recorded in Backstage). |
| 8 | Foopee submitted | Manually submitted to Foopee. |
| 9 | Press email prepared | A post has an approved "Press" channel variant. |
| 10 | Email blast scheduled | A broadcast to the email list has been created. |
| 11 | At least one marketing post created | The campaign has at least one post (any status). |
| 12 | Ticket goal set | A numeric ticket target has been entered in the campaign settings. |
| 13 | SF Chronicle pitch sent | Manually pitched to the SF Chronicle events section. |
| 14 | SF Station listing submitted | Submitted to SFStation.com. |
| 15 | DoTheBay listing submitted | Submitted to DoTheBay.com. |
| 16 | SongKick listing submitted | Listed on SongKick. |
| 17 | JamBase listing submitted | Listed on JamBase. |
| 18 | Ad-hoc press / VIP emails sent | Targeted emails sent to press, VIPs, or specific contacts. |
| 19 | Day-before reminder scheduled | A broadcast is scheduled within 36 hours before the show date. |
| 20 | Band assets collected | At least one approved band photo or logo is in the Assets tab. |
The checklist shows the first 5 items by default. Click
View full checklist to see all 20. Items are color-coded: ✅ done (green),
Promotion Campaign Checklist
- Confirm event is at Needs Assets status or beyond
- Upload flyer to the event's Assets tab — approve it
- Upload band photos and logo — approve them
- Go to Promote → open this event's campaign
- Set a ticket goal (the target number to sell)
- Create an Announcement post — write the master text, attach the flyer
- Open the post → Channel Variants → click Generate variants
- Review each variant — edit as needed, especially Twitter (280 chars)
- Mark each variant as Approved when it's ready
- Click Broadcast → select Direct Posts (Instagram, Facebook) → Send now
- Create Eventbrite and Luma listings via Broadcast → Event Platforms
- Manually submit to Funcheap, Foopee, DoTheBay, SFStation, SF Chronicle
- Create a second post for the email blast — write email-specific copy
- Schedule the email broadcast
- Create a "Day-before reminder" post — schedule it for 24 hours before show time
- Check Promotion Health — aim for 80%+ before the week of the show
💡 Timing your posts
A good promotion cadence for a ticketed show: 4–6 weeks out — announce on social + Eventbrite/Luma; 2 weeks out — email blast to list; 1 week out — push editorial submissions (Funcheap, DoTheBay, etc.); 24 hours out — day-before reminder on all channels; day of — "Doors tonight" post on Instagram/Facebook.
To enable direct posting, a venue admin needs to connect credentials for each platform. Go to Settings → Promote in the sidebar. Each platform shows its connection status and the fields needed to connect it.
| Platform | What you need | Notes |
|---|---|---|
| Facebook Page token (Instagram is managed via Facebook's API) | Requires a Facebook Business account connected to the Instagram page | |
| Facebook Page access token + Page ID | Token must have pages_manage_posts permission |
|
| TikTok | TikTok Content API credentials | Requires TikTok for Business account |
| Eventbrite | Eventbrite API key + Organization ID | Creates the listing automatically on broadcast |
| Luma | Luma API key | Creates the Luma event automatically on broadcast |
| Email (Mailchimp) | Mailchimp API key + Audience ID | Sends to your subscribed list |
| Email (SendGrid) | SendGrid API key + list ID | Alternative to Mailchimp |
🔑 Credentials are venue-level
Promote credentials are set once per venue and apply to all events. They are stored securely and never displayed in the UI after they're saved (only a "connected" or "not connected" indicator is shown). If a token expires, broadcasting to that platform will fail — the health checklist will show warnings for any destinations that couldn't be reached.
Part VII
Sell tickets directly through Backstage, scan QR codes at the door, issue comps, and track every transaction — no third-party platform required.
Chapter 7
The venue owns the ticket, the token, and the audit trail. Buyers pay through Stripe or Square's hosted page — card data never touches Backstage. Everything else — inventory, QR codes, door scanning, comps, and refunds — lives here.
Every event starts in External ticketing mode — meaning if someone clicks "Buy Tickets" on the public event page, they're sent to whatever URL you specify (TIXR, Eventbrite, a direct Stripe link, etc.).
When you switch to In-house mode, the system takes over: it shows a live ticket purchase form directly on the event page, handles payment, sends QR-code tickets by email, and enables the door scanner.
To switch modes, open the event workspace →
Ticketing tab → choose the mode and click
Save ticketing mode.
Enter a ticket page URL and the platform name. That's it. The public page shows a "Buy Tickets" button pointing to that URL. All sales, refunds, and reporting are handled by the external platform.
Full Backstage ticketing. You control the inventory, pricing, comps, scanner links, and reporting. Requires Stripe or Square to be configured in Admin → Payments.
🚀 First time switching to in-house
The first time you switch an event to in-house mode, the system automatically seeds a default ticket type (General Admission), a small comp allocation, and a Door scanner link — so you're not starting from zero. Edit or delete these defaults as needed.
Ticket types are your sellable tiers — General Admission, VIP, Early Bird, etc. Each has its own price, inventory count, sales window, and status. You can have as many tiers as you need.
Click the
+ button next to Ticket types to add one:
Ticket Type Fields
| Field | Description |
|---|---|
| Name | What buyers see on the purchase form. e.g. "General Admission", "VIP", "Early Bird". |
| Price (USD) | The purchase price in dollars. Enter 0 for free tickets. This gets stored as cents internally to avoid float rounding. |
| Quantity | Total inventory for this tier. The system tracks sold + active holds and prevents overselling. |
| Status | Draft → On Sale → Paused → Sold Out → Closed. Set to On Sale when ready to open sales. |
| Sales start | Optional. When ticket sales open for this tier. Leave blank to make it available immediately once status is On Sale. |
| Sales end | Optional. When sales close. Use to create advance-only pricing (e.g. "Advance closes night of show at 6pm"). |
| Description | Optional. Shown to buyers. Use for VIP perks, early entry details, etc. |
| Status | What it means | Visible to buyers? |
|---|---|---|
| Draft | Being set up — not yet for sale | No |
| On Sale | Available for purchase | Yes, with live availability count |
| Paused | Temporarily suspended | No (hidden from purchase form) |
| Sold Out | All inventory sold (can be system-set or manual) | Yes, shown as sold out |
| Closed | Sales window ended | No |
At the top of the Ticketing tab, four summary stats update in real time:
—
Sold
Paid tickets issued
—
Available
Remaining inventory
—
Redeemed
Scanned at door / issued
—
Gross Sales
Revenue before fees
Below the stats, the tier table shows the same breakdown per ticket type: sold, comped, available, and revenue. Use this to spot which tiers are moving and which aren't — if VIP is sitting at 0 sold a week out, it might be time to lower the price or fold it into GA.
Understanding what happens when a buyer purchases a ticket helps you troubleshoot issues and answer customer questions:
- Buyer opens the public event page and sees the in-house purchase form with available tiers and live inventory.
- Buyer clicks "Buy" — Backstage creates a pending order with a 15-minute hold on the inventory. This prevents two buyers from buying the last ticket simultaneously.
- Buyer is redirected to the payment provider's hosted page (Stripe Checkout or Square) to enter card details. Card data never touches Backstage.
- After payment, the provider sends a webhook to Backstage. Backstage verifies the signature, then issues the tickets and sends each holder a QR code email.
- The 15-minute hold on inventory is released and replaced by the actual sold quantity.
⏱️ The 15-minute hold window
If a buyer starts checkout but doesn't complete payment, their hold on the inventory expires after 15 minutes and the tickets become available again. They'll need to start over if they return after the window. This means your "Available" count might temporarily look lower than it actually is during busy sale periods.
Comps are free tickets issued directly — no payment provider involved. You issue them from the Comp tickets section of the Ticketing tab.
To issue comps:
- Click the + next to Comp tickets
- Choose the ticket type (tier), quantity, and optionally a holder name and email
- Click Issue comps
If you enter an email address, the QR ticket is immediately sent to that address. If no email is entered, the ticket codes appear on screen so you can share them manually.
💡 Comps from the Guest List
You can also issue comps directly from the Guest List tab. Any guest with an email address has an
Issue comp button next to their entry. This is the fastest way to handle "the band put John on the list" situations — one click issues and emails a QR ticket.
The Issued tickets section shows every ticket that has been issued — paid or comp. Each row shows the ticket code, holder name and email, tier, and current status.
| Status | What it means | Actions available |
|---|---|---|
| Valid | Issued and not yet scanned | View QR page · Resend email · Void |
| Scanned in | Successfully scanned at the door — holder is inside | View QR page (for reference) |
| Void | Invalidated — will not admit at door | View only |
Resend — sends the ticket email again to the holder's email address. Use this when someone says "I never got my ticket." Only available if a holder email is set and the ticket is not voided.
Void — invalidates the ticket immediately. Use for fraudulent tickets, duplicate issuances, or when someone's refund is processed but the webhook didn't clean it up automatically. Voided tickets show as "Void" at the door scanner — not "Redeemed."
At the bottom of the Ticketing tab, in the Cancel & refund section, there's a
Refund all orders button. This is the cancel-event path — it:
- Issues refunds to every paid order through the original payment provider
- Voids all issued tickets for the event
- Marks all orders as refunded
⛔ This cannot be undone
"Refund all orders" is the nuclear option — it refunds every purchase for the show in one go. Only use it when the event is definitively cancelled and all ticket buyers need to be refunded. Partial refunds (for individual tickets or orders) are not yet supported through the interface — contact the technical team if you need selective refunds.
Scanner links are how door staff access the QR scanner without needing a Backstage login. Each link is a secret URL — anyone with the URL can scan tickets for that event.
| Action | When to use it |
|---|---|
| Create link | Before every show that uses in-house ticketing. Label it with the entrance (e.g. "Main Door", "Side Entrance", "VIP Entry"). |
| Show link | If you need to share the link URL with a different door person or open it on another device. |
| Generate link | Creates a fresh secret for an existing link (without creating a new row). Use if you think the previous secret was shared with the wrong person. |
| Revoke | Permanently disables this link. Anyone using it will immediately lose scanner access. Use if a door person leaves mid-event or a device is compromised. |
📌 PIN protection
When creating a scanner link, you can optionally set a PIN. Door staff will need to enter the PIN when they open the scanner URL. This adds a layer of protection if the URL is accidentally shared — knowing the URL alone isn't enough.
Before in-house ticketing can accept real payments, a venue admin must configure the payment provider in Admin → Payments. Two providers are supported:
| Provider | Requires | Notes |
|---|---|---|
| Stripe |
STRIPE_SECRET_KEY + STRIPE_WEBHOOK_SECRET
|
Uses Stripe Checkout hosted page. Webhooks must be registered in the Stripe dashboard pointing to /api/webhooks/stripe. |
| Square |
SQUARE_ACCESS_TOKEN + SQUARE_LOCATION_ID + SQUARE_WEBHOOK_SIGNATURE_KEY
|
Uses Square hosted checkout. Webhook URL must be registered in the Square developer dashboard. |
Secret keys are stored in the server's .env file — they are never stored in the database and never shown in the UI. The Admin → Payments screen shows only whether each provider's keys are present (✅ or ❌), not the values themselves.
💡 Which provider should we use?
Both Stripe and Square work reliably. Stripe tends to have better documentation and developer tooling. Square is better if you're already using Square for your bar POS. Only one provider is active at a time — switching mid-event isn't recommended, as in-flight orders use whichever provider was active when they were created.
In-House Ticketing Setup Checklist
- Admin → Payments: confirm active provider + keys are set (both show ✅)
- Register the webhook URL with your payment provider
- Event → Ticketing tab: switch mode to "Sell tickets here"
- Create ticket types (General Admission, VIP, etc.) with prices and quantities
- Set each ticket type to "On Sale"
- Publish the event page so the purchase form appears publicly
- Test with a $0 or $1 ticket before opening sales for real
- Before doors: create a scanner link (copy the URL immediately)
- Open the scanner URL on the door device and confirm it loads
- Issue any comps before doors open
Part VIII
Managing who has access to Backstage, what they can do, and how to keep the system organized behind the scenes.
Chapter 8
Backstage's Admin section is for venue managers and owners. It's where you set up login accounts, manage the staff roster, build event templates, maintain the contract library, and configure payments.
Navigate to Admin in the left sidebar. You'll see six tabs:
| Tab | What you manage here |
|---|---|
| Users | Login accounts — the people who sign into Backstage |
| Duplicates | Detect and merge duplicate user accounts or contacts |
| Staff | The employee roster — the people who work your shows (separate from login accounts) |
| Templates | Event templates with pre-built task checklists and run sheet schedules |
| Contracts | The contract clause library and template manager |
| Payments | Payment provider configuration (Stripe or Square) |
🔐 Admin-only area
The Admin section is only visible to users with the venue_admin role. If you don't see it in the sidebar, your account doesn't have admin access. Ask a venue admin to grant it.
The Users tab shows everyone who has a Backstage account. There are two ways to create an account: a venue admin creates it directly, or someone requests access and an admin approves it.
Fill in the Create User form at the bottom of the Users tab:
Create User Fields
| Field | Description |
|---|---|
| Name | The person's full name. This appears throughout the app wherever events are assigned to them. |
| Used for login and for automated notifications. Must be unique. | |
| Role | The user's system-level role. Determines what they can see and do. See the Roles quick reference below. |
| Password | Optional. If left blank, the user can sign in via a magic email link or a passkey. They can set a password later from their Account settings. |
Backstage supports three authentication methods — users can use any or all of them:
| Method | How it works | Best for |
|---|---|---|
| Password | Standard username + password. Set by the admin on account creation, or changed in Account settings. | Users who prefer traditional login |
| Passkey | Biometric authentication (Face ID, Touch ID, Windows Hello) stored on the device. No password needed. | Any modern device — most secure option |
| Email link | A one-time magic link sent to the user's email. They click it to sign in — no password required. | Occasional users who don't want to remember a password |
🔑 Passkeys are the best experience
Passkeys use your phone's or laptop's built-in biometrics and are more secure than passwords. When a new user logs in for the first time, Backstage prompts them to set up a passkey if they don't have one. Encourage staff to do this — it makes future logins a single tap.
Click
Edit next to any user to open their edit modal. You can change their name, email, role, and password, and you can see how many passkeys they have registered. You can also manage their email addresses (useful if someone has multiple addresses).
If someone clicks "Request Access" on the login page, their request appears at the top of the Users tab as a Pending access request. The request shows their name, email, phone, and a "situation" note explaining why they want access.
To approve: choose a role from the dropdown next to their name, then click
Approve & send link. The system creates their account and emails them a one-time login link. To dismiss (decline): click
Dismiss — this deletes the request.
The staff roster (Admin → Staff) is different from login accounts. It's the list of employees — bartenders, security, sound techs, door staff, etc. — who get assigned to shifts on events.
A staff roster entry doesn't need a Backstage login. A bartender who works shows doesn't need to log into Backstage — they just show up for their shift. But if they do have a login (e.g., a sound tech who also manages their own scheduling), you can link their roster entry to their login account.
Staff Member Fields
| Field | Description |
|---|---|
| Name | Full name. Appears in shift assignments throughout the event workspace. |
| Pronoun | e.g. "they/them", "she/her". Shown as a small label next to the name. |
| Default role | Their primary role (bartender, security, sound, etc.). Pre-fills when you add them to an event shift. |
| Position | Freeform title. e.g. "Head of Security", "Lead Bartender". Shown in the roster table. |
| Email / Phone | Contact info. Shown in the staffing table so managers can reach them night-of. |
| Hourly rate | Their default pay rate. Pre-fills the rate field when they're added to a shift. Used for shift cost estimation. |
| Hire date | Optional. For HR reference and the Google Sheet sync (Staff Contact tab). |
| Link to login | Associates this roster entry with a Backstage login account. Lets them see their assigned shifts in the app. |
| Notes | Availability constraints, certifications (e.g. "TIPS certified"), allergies, or anything else scheduling managers need to know. |
| Active | Inactive staff don't appear in the shift assignment dropdown — but their past shift history is preserved. |
📊 Google Sheet sync
The staff roster syncs two-way with the Staff Contact tab in the connected tracking spreadsheet. Changes in either direction reconcile automatically on a 5-minute cron. This means you can manage staff in the sheet or in Backstage — whichever is more convenient.
Event templates let you pre-build task checklists and run sheet schedules for common show types, so every new booking of that type starts fully organized instead of blank.
A template belongs to a specific event type and venue. When you create a new event that matches, you can apply the template to instantly populate its task list and schedule.
Fill in the Create Template form. The two key fields are:
Checklist — one task per line. These become tasks in the event's Tasks tab. Example:
Confirm headliner booking
Get contract signed
Approve flyer
Publish event page
Confirm door staff
Print run-of-show packet
Schedule — one item per line in the format HH:MM | type | title. These become items in the event's Schedule (Run Sheet) tab. Example:
17:00 | load_in | Load-in opens
18:00 | soundcheck | Opener soundcheck
19:30 | soundcheck | Headliner soundcheck
20:00 | doors | Doors open
20:30 | set | Opener set
21:00 | changeover | Stage changeover
21:30 | set | Headliner set
23:00 | curfew | Hard curfew
💡 Use templates liberally
Create a template for every common show format: three-band local show, DJ night, comedy, open mic, etc. The first time you build a template for each format, you save yourself and every future booker from rebuilding the same checklist and run sheet from scratch every time.
Venue Policy (Admin → Venue Policy) is the authoritative record of house rules, room configurations, and default booking terms. It's the first place to check when staff have questions about what the venue's default position is on any booking detail.
Each room has a name, capacity, and age rule:
| Room | Capacity | Default age rule |
|---|---|---|
| Upstairs Mabuhay Gardens | 450 | All ages |
| Downstairs Mabuhay Gardens | 350 | 21+ |
Venue Policy Fields
| Field | Description |
|---|---|
| Age rule | Default age policy for new events. Options: All Ages / 18+ / 21+ / Venue Discretion. Overridable per event. |
| Alcohol mode | None / Cash Bar / Hosted Bar / Bar Minimum / Venue Discretion. Sets the default bar arrangement for new bookings. |
| Deposit policy | Whether deposits are required, and how they're calculated: a percentage of the rental fee, or a flat dollar amount. Also sets how many days before the event the deposit is due. |
| Staffing rates | Default hourly rates for each staff role: Security, Bartender, Door Staff, Sound Tech, Manager. These pre-fill shift cost estimates when staff are added to events. |
| COI required | Whether vendors must have a Certificate of Insurance on file before working on-site. Yes/No. This feeds into the vendor COI tracking in the event workspace. |
| Contract required | Whether all events must have a signed contract before advancing to Booked status. Yes/No. |
| is_verified | Mark a policy as verified once all fields have been confirmed correct. Unverified values are labeled in the UI with a warning indicator. |
Venue Policy is versioned. When you create a new policy record, the old one is deactivated and stamped with an effective date. Old policy data is never deleted — you can always see what the rules were at any point in the past.
Events snapshot the policy at booking time
When an event is booked, it takes a snapshot of the current venue policy and stores it on the event record. A later change to the venue policy — a new deposit percentage, a changed age rule — does not retroactively affect already-booked events. Each event always reflects the rules that were in effect when it was locked in.
Keep the policy verified
After any changes to rates, room capacities, or house rules, update the Venue Policy and mark it as is_verified. Unverified policy values show a warning label in the booking workflow — this is intentional, to prompt staff to confirm the numbers rather than assume they're current.
Admin → DB Browser is a read-only inspector for every table in this venue's database — for the questions the rest of the app doesn't have a screen for: "what's actually stored in this row?" Restricted to venue admins.
Pick a table on the left. The rows pane supports per-column filtering (the search row under the column headers) and sorting (click a header). Click any row to open a full field-by-field detail card underneath. A Download button exports the current filtered/sorted view as CSV, Excel, or a .sql file of ready-to-run INSERT statements (capped at 20,000 rows).
Read-only, by design
The Database Browser has no way to edit or delete a row — it's purely for looking. To actually correct bad data, and to see exactly who or what changed it, use Database history & undo below.
Admin → DB History is an audit trail of every insert, update, and delete made to this venue's database, with a one-click undo for any individual entry. It exists to answer a question the rest of the app can't: something changed and I don't know why — what happened, and can I get it back?
Most edits made through the app show up in an event's own activity log. But that log only covers writes made through the app's own code paths. A background sync job, a one-off data-repair script, or someone connecting to the database directly all bypass it completely — which means the edit that actually caused a problem can be the one piece of history nowhere else records. Database history is implemented at the database level (triggers on every table, not application code), so it catches every write regardless of where it came from.
Where this came from
This feature exists because of a real incident: a scheduled sync job silently overwrote event data from a spreadsheet with a broken row-linking column, and there was no record anywhere in the app of what had changed or when. Tracing it took hours of cross-referencing spreadsheet backups and git history. Database history turns that into a five-minute lookup.
Each row in the list is one write to one table: when it happened, which table and row id, whether it was an insert, update, or delete, who or what did it, and — for updates — a short summary of which fields actually changed. Filter the list by table, row id, actor, action type, or whether an entry has already been undone.
List & Detail Fields
| Field | Description |
|---|---|
| Actor |
user #12 for a change made by a logged-in person; a script name (e.g. sync-mabevents.py) for an automated job; unattributed for a write made directly against the database with no app session to tag it (for example, from a mysql command line). |
| Changed fields | For updates only: every column whose value actually differs between the before and after row. Shown as a Before → After table in the detail panel. |
| Undo SQL | The exact SQL statement that reverses this entry — a DELETE undoing an insert, an INSERT undoing a delete, or an UPDATE restoring the prior field values. Generated automatically from the row's own before/after data; viewable (collapsed by default) in the detail panel for anyone who wants to see precisely what Undo will run. |
Open any entry's detail panel and click Undo to run its stored reverse SQL immediately. There's a confirmation prompt first, since it takes effect right away — there's no draft or preview step.
There is deliberately no separate "redo" feature. Undoing a change is itself a real write to the database, so it fires the same triggers and creates its own new history entry — the exact reverse of the one just undone. To redo something you undid by mistake, open that new entry and click Undo on it. The detail panel always shows the link between a paired entry either direction ("this undid entry #123" / "undone → see entry #456"), so the chain is easy to follow.
Undo runs immediately
Undo is not a request or a suggestion — clicking it executes the reverse SQL statement against the live database right away. An entry can only be undone once (the button is replaced with a confirmation afterward), but there's no limit on how many times you can undo-the-undo back and forth. Think of it the same way you'd think about running a raw SQL statement yourself, because that's exactly what it is.
Database history only covers the database itself. Writes to disk — uploaded files, generated PDFs, sent email — aren't touched by an undo, so reverting a database change doesn't un-send an email or restore a deleted file. History entries older than 30 days are pruned automatically by a nightly job to keep the table from growing without bound. For recovery beyond that window, or a whole-database point-in-time restore rather than a single row, ask whoever runs the server about the separate 5-minute database snapshot backups kept outside the app.
Part IX
Marketing email, built in: draft and send one-off campaigns, and build reusable audiences to send them to.
Chapter 9
Backstage can draft, edit, and send marketing email directly — no separate email-marketing tool required — and target it using reusable mailing lists layered on top of Contacts. Find both under Messages in the sidebar.
🔐 Venue-admin only
Campaigns and Lists are gated by the manage_campaigns capability — the same grant as the Contacts CRM tools. If you don't see Messages → Campaigns or Messages → Lists in the sidebar, your account doesn't have it.
💡 Not the same thing as Panic Promote
A Panic Promote campaign coordinates one event's social media, listing sites, and press. An email Campaign here is just the email channel — a newsletter or event blast — and it's independent of whatever's happening in Promote for that event.
Open Messages → Campaigns to see every campaign that's been drafted or sent, with its recipient and failure counts. Two ways to start a new one:
✉️ New Blank Email
Name it and start writing. Both the HTML and plain-text bodies start from a blank starter template — you fill in the content yourself.
📅 Generate from Event(s)
Pick one or more upcoming events from a filterable list and Backstage builds a ready-to-send lineup email — the same event-card rendering as the weekly "shows this week" digest.
Only events that are public and already Published or Advanced can be picked for a generated campaign — anything earlier in the pipeline (or a private rental) is left off the picker entirely, and if you had somehow targeted an ineligible one it's dropped with a count shown so nothing silently disappears.
A campaign is only editable while its status is draft. Toggle between the
HTML and
Plain text views to edit each body — they're saved independently and both go out together, so keep them consistent yourself. The name and subject line are editable right in the detail header.
Click
Recipients to open the picker: check any mailing lists to include, and search for individual opted-in contacts to add one at a time. The panel recalculates and shows a live recipient count as you adjust the selection.
You can select a list or contact that isn't opted in — Backstage simply excludes those rows from the actual send (recorded as skipped, opted out) rather than blocking you or silently including them. Only contacts with marketing email turned on are ever counted or emailed.
| Action | What it does |
|---|---|
| Send Test… | Emails the current draft to one address you type in (yourself, a coworker) so you can proof it. Doesn't lock the draft or touch recipient counts. |
| Send Campaign | Sends to every resolved, opted-in recipient and moves the campaign out of draft for good — it can no longer be edited or deleted. Each recipient's outcome (sent/failed/skipped) is tracked individually, so one failed delivery never stops the rest of the send. |
A mailing list is a reusable, named audience built on top of the Contacts CRM — build a VIP list, a genre list, or "opted-in regulars" once and reuse it across every future campaign instead of re-picking recipients by hand each time. Manage lists under Messages → Lists, or from a contact's own record (its Mailing Lists section shows every list that contact belongs to and lets you toggle membership without leaving the page).
Every list is created as one of two types, and the type can never be changed afterward — create a new list instead of trying to convert one, since there's no sensible rule for what should happen to existing members on a type switch:
- Static — you choose members by hand. Membership only ever changes when you change it.
- Smart (segment) — membership is computed from saved rules and only re-synced when you click Refresh now. See below.
- Search & check — search contacts by name or email, optionally filter to Opted in only, check the ones you want, and click Add selected.
- Add all matching — adds every contact matching the current search/filter in one action, not just the ones visible on screen. Capped at 2,000 contacts per action to keep any single write bounded.
-
Import CSV — upload a CSV with an
emailcolumn (required) plus optionalfirst_name,last_name,phone, andopted_incolumns (max 5,000 rows / 5 MB per upload). Rows are matched to existing contacts by email, or create new contacts. A bad row (missing or invalid email) is reported individually rather than failing the whole upload.
📋 A CSV import is not consent
Uploading a list of names and emails never changes anyone's opt-in status by itself — the opted_in column is only applied when it's explicitly present in the file. Someone appearing in an imported CSV is not automatically opted in to marketing email.
A smart list's membership is computed, not hand-picked. Its rules panel combines opted-in status with minimum spend, minimum events attended, and minimum tickets purchased — the same filters used elsewhere on the Contacts page. Click Refresh now at any time to re-run those rules and sync membership; there's no background job doing this automatically, so a smart list can go stale until someone refreshes it.
💡 A refresh only touches what it added
Refreshing a segment list only adds or removes contacts that the segment rules themselves previously added — a member you (or a CSV import) added to that same list by hand is never evicted by a refresh, and vice versa. This is also why list type can't change after creation: a list is either fully computed or fully manual, never an ambiguous mix.
Quick Reference
Every user has a role that controls what they can see and do. Here's the complete map.
Quick Reference
Access in Backstage works on two levels: a global role (your account-level access) and per-event roles (what you can do on a specific event you've been invited to). Both combine to determine what you see and what you can change.
Every user account has one global role. This is set by a venue admin when the account is created (or when an access request is approved).
Venue Admin venue_admin
Full access
The top-level role. Venue admins can do everything: manage all events, handle all money fields, approve contracts, manage users and staff, edit templates, configure payments.
✅ View and edit all events (all venues)
✅ Admin section (all tabs)
✅ Create, publish, and delete events
✅ Manage all login accounts
✅ Settlement — view and edit
✅ Manage staff roster
✅ Contracts — view, manage, approve
✅ Edit event templates
✅ In-house ticketing management
✅ Contract clause library
✅ Invite collaborators to events
✅ Manage contacts (CRM)
Typical holders: venue manager, management, ownership
Global Viewer global_viewer
Read-only, all events
Read-only access to every event across all venues. Can see the full picture — including settlement and contracts — but cannot change anything. Ideal for silent partners, accountants, or ownership who want visibility without edit access.
✅ View all events (read-only)
✅ View settlement data
✅ View contracts
✅ View public event pages
❌ Cannot edit anything
❌ No Admin section access
Typical holders: Accountants, silent investors, ownership with read-only access
Viewer viewer
Read-only, invited events only
The default role for new accounts. Can only read events they've been specifically invited to. No global visibility, no editing. Essentially a placeholder account until a venue admin grants additional access.
✅ Read events they're invited to
❌ Cannot see any other events
❌ Cannot edit anything
❌ No Admin section access
Typical holders: New accounts pending role assignment
When a venue admin or event owner invites someone to a specific event (via the
Invites tab), they assign them an event-level role. This is separate from and independent of their global role.
A viewer global account can be invited as a promoter on one event and have full promoter access to that specific event — while still seeing nothing else in the system. This is the permission model for external producers and bands.
| Event Role | Read event | Edit event | Lineup / Schedule | Tasks / Open items | Guest list | Assets | Contracts | Settlement | Ticketing |
|---|---|---|---|---|---|---|---|---|---|
Event Ownerevent_owner
|
✅ | ✅ | ✅ | ✅ | ✅ | ✅ manage | ✅ manage + approve | ✅ view + edit | ✅ manage |
Promoterpromoter
|
✅ | ❌ | ✅ | ✅ | ✅ | ❌ | ✅ view only | ❌ | ❌ |
Band / Artistband / artist
|
✅ | ❌ | ❌ | ✅ assigned tasks only | ❌ | ✅ upload only | ❌ | ❌ | ❌ |
Designerdesigner
|
✅ | ❌ | ❌ | ❌ | ❌ | ✅ upload + manage | ❌ | ❌ | ❌ |
Staffstaff
|
✅ | ❌ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
Viewerviewer
|
✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
📌 venue_admin always has full event access
A user with the venue_admin global role automatically has full access to every event — the same as event_owner — without needing an invite. This means venue admins can manage any event regardless of who created it.
Create a viewer account for them, then invite them to their event as promoter. They can manage the lineup, guest list, tasks, and schedule for their show — and view the contract — but they can't edit the event's financial details, access settlement, or see any other events on the system.
Invite the band's manager (or a band member) to the event as band. They can upload flyers, press photos, and social images to the Assets tab, and they can see tasks assigned to them. They can't see the money, the guest list, or the contract.
Invite them as designer. They can upload and manage assets — upload a draft, mark it ready, replace it with the final version. They see nothing else.
Invite them as staff. They can check the run sheet, manage the guest list, and update tasks. They can't change the event details, access contracts, or view settlement. This is the right role for a door manager or production coordinator who needs operational access without financial access.
Assign them the global_viewer global role. They can see every event's settlement and contracts across all venues — read-only. They don't need to be invited to each event individually.
Quick Reference — Assigning the right role
| Role | Who it's for |
|---|---|
venue_admin |
Full-time management staff who need to do everything — venue managers, ownership |
global_viewer |
Read-only observers across all events — accountants, silent investors, absentee owners |
event_owner |
The person responsible for a specific show — same power as venue_admin for their own event |
promoter |
External promoters running a show — can manage lineup, schedule, guest list; can't touch money or contracts |
band / artist |
Performers or their managers — upload promo assets and see their assigned tasks only |
designer |
Graphic designers — upload and manage assets only; no access to operational details |
staff |
Floor managers, production coordinators — run sheet + guest list + tasks; no financial access |
viewer |
Read-only on events they're specifically invited to — the default for new accounts with limited access |