Approve a host application
Review the queue, chase what is missing, and approve — which drafts the contract.
Owned by Venue Manager · 9 steps · about 15 minutes
Why this exists
The intake queue is where the venue decides what its calendar looks like, so the design goal is that a manager can make that decision from one screen without trusting anyone's memory.
Two ideas are doing the work. The first is the viability scorecard: every application is scored on the same axes so that comparing two nights is comparing like with like. The second is that asking for more information is a first-class state, not an email. Requesting info sends the promoter a tokenised edit link and moves the application into a state that says, on the queue, that the ball is in their court. Nothing gets silently stuck in someone's inbox.
Approval is a bigger action than it looks: in the same transaction it drafts the contract, with riders derived from the flags the promoter set and the headcount, price and date snapshotted from what they submitted. Approving is therefore a statement that the numbers on the application are the numbers you are willing to put in a contract.
Before you start
- A venue manager or admin session — the queue is gated to reviewers.
- At least one application in the queue (the seed ships a viable one).
Practise with
| Persona | Password | Note | |
|---|---|---|---|
| venue_manager | manager@club.test | manager123 | the reviewer persona for this workflow |
| host_promoter | host@club.test | host123 | the applicant; use them to answer a request for more information |
| admin | admin@club.test | admin123 | picks the drafted contract up from here |
Steps 1–3 — Venue Manager
their manual →-
1Open the intake queue and filter to what needs a decision.Expected result Applications with status and viability score.Watch out for This page is gated to venue manager and admin. Door staff get a 403 — the calendar is not a door decision.
-
2Open one application and read it properly: the date against your calendar, the headcount against the room, the rider flags, the attachments and the notes.Expected result The full scorecard, status history and the rider summary a contract would be built from.
-
3If something is missing, request more information rather than declining. Say exactly what you need.Expected result The application moves to info_requested and the promoter is emailed a tokenised edit link.Watch out for Do not chase this by personal email. The token is what lets them edit without an account, and the status is what keeps the queue honest.
Steps 4–5 — Host / Promoter
their manual →Answers a request for more information through their tokenised edit link.
-
4As the promoter, open the edit link you were sent and see your own application.Expected result Your application, editable, with no login required.Watch out for The token is the credential and it is scoped to this application. Treat it like a password.
-
5Answer the question and resubmit.Expected result The application returns to the queue with your update recorded in its history.
Steps 6–7 — Venue Manager
their manual →-
6Re-open the application and check the updated answer and the recomputed score.Expected result The new values, with the change visible in the status history.
-
7Approve.Expected result Status approved, and a draft contract created in the same transaction with the riders the flags implied.Watch out for You can approve, but you cannot lock or counter-sign the contract that approval just drafted. That is an admin's job, and it is the deliberate split between running the calendar and binding the venue.
Steps 8–9 — Admin
their manual →Takes the contract that approval drafted and turns it into a signed agreement.
-
8As an admin, pick the new draft up from the contracts list.Expected result The drafted contract against that application.
-
9Open it and continue into the contract workflow: fill the variables, lock, send for signature.Expected result The editable draft with its auto-injected riders.