Author a rider so a host can ask for it
Turn a host's 'we do something you don't list' into an approved clause — and a checkbox that did not exist before.
Owned by Venue Manager · 22 steps · about 22 minutes
Why this exists
The application form is now governed by the contract library. Every feature a host can tick — live music, alcohol, late night, certified security staffing, aerial performance, a resale royalty — is a checkbox only because an approved rider stands behind it. Untick that relationship and the box does not exist. There is no list of features maintained anywhere else.
The reason is a single sentence: the form may only say things the venue has already agreed, in writing, to say. A checkbox is a promise. If a host can tick something the venue has no clause for, the venue has agreed to something nobody drafted, and it finds out at signature time.
So what happens when a host needs something new?
They write free text. That is the whole point of the free-text box, and it is deliberately a message, not a request for a checkbox. Free text can never become contract language by itself, however carefully it is worded, because the person who writes the clause must be the venue. What the host's words do is start a conversation and land a row in a queue.
A manager reads the message and authors a rider from it. The host's text sits beside the editor, read-only, and is never pre-filled into the body — if it were, the host would have authored contract language after all, just through a longer pipeline. The note is context. The manager writes the clause.
Two scopes, and why one-off is the default
A rider is either library — part of the standing catalogue every host sees — or one-off: written for one application, at one venue, and shown to nobody else. Answering a host in a hurry should never quietly extend what the whole world can ask for, so the answer-a-host path creates a one-off. A one-off that turns out to be generally useful can be promoted to the library later, as a separate, deliberate decision.
Nothing is selectable until a version is approved
Creating a rider creates its catalogue row and its first draft version. It is not selectable. The text goes draft → in review → approved, and only then can the catalogue row be made selectable — attempting it earlier is refused because there is no approved version to select.
Self-approval succeeds by default on this install. That is a deliberate trade-off, not an oversight: a two-person rule on a small team means riders never ship. The preventive control was replaced by three detective ones — a self-approved flag stored on the version and rendered as a chip wherever riders are listed, an append-only trail row pinning the exact bytes that were approved, and a notice to the chat the team already watches. One setting turns the two-person rule back on.
When a version is approved, every request linked to it flips to approved and the host who asked is emailed a working link back into their application. Without that last step the host never learns the thing they asked for now exists, and the whole loop is theatre.
Before you start
- A venue_manager or admin session. Rider authoring and approval are staff surfaces.
- An application carrying a host's free-text note, or an open rider request. The debug seed can make some.
- The seeded catalogue: live music, alcohol, late night, certified security staffing, aerial performance, and a resale royalty with a basis-points parameter.
Practise with
| Persona | Password | Note | |
|---|---|---|---|
| venue_manager | manager@club.test | manager123 | authors riders, approves versions and triages the request queue |
| host_promoter | host@club.test | host123 | owns the seeded applications; the person on the other end of the request |
Steps 1–6 — Host / Promoter
their manual →Ticks what the library already covers, and writes the free text that starts a new rider.
-
1Open the application form and find the features section. Each checkbox has a label and a line of help text — read the help, because it is what the clause commits you to, written for a host rather than for a lawyer.Expected result Grouped checkboxes: Production & licensing, Commercial terms.Watch out for Ticking a box is not a preference. It attaches a clause to the contract you will be asked to e-sign. A careless tick is a wrong clause in a binding document.
-
2Understand where those boxes come from: the form draws exactly what this endpoint returns for your application and its venue.Expected result Groups of riders with their host-facing labels, help text, parameters and relationships.Watch out for Called without an application id it returns library riders only. That narrowness is on purpose — nobody can discover another host's one-off clause by probing this endpoint.
-
3Tick Aerial performance and watch Certified security staffing tick itself, with a line explaining which choice pulled it in.Expected result The implied box selected and annotated, not silently checked.Watch out for Some riders imply others and some exclude each other. Implication is enforced on the server too — the client is a convenience, and a payload that ticks a rider you may not select is refused as not selectable.
-
4A rider that needs a number asks for one. The resale royalty carries a basis-points parameter with a range, and it is required if you tick the box.Expected result A parameter row appearing under the checkbox you ticked.Watch out for Basis points, not percent: 250 is 2.5%. The bound is checked server-side, so a number outside the range comes back as a validation failure naming that rider.
-
5For something the list does not cover, open My event needs something that isn't listed and answer three questions: what is it called, what happens at your event that is not covered, and what would the venue need to agree to. Optionally name the closest existing rider.Expected result A 201 and a card in the venue's staff channel with your request on it.Watch out for This is a message, not a checkbox request that gets granted. Nobody converts your words into contract language — a manager reads them and writes the clause. Requests are rate limited per email per day.
-
6Submit the application with whatever you could legitimately tick. Your request rides along with it.Expected result A 201, and the application flagged as having an open rider request.Watch out for Do not wait for the rider before applying. The application is the thing that gets a date held; the clause can arrive afterwards and you will be emailed a link to add it.
Steps 7–17 — Venue Manager
their manual →-
7Open the rider-request queue. Each row carries the host, the application it came from, what they say happens, what they think the venue would need to agree to, and how long it has been sitting there.Expected result Requests in new, triaged, authoring, approved or declined.Watch out for The age column is measured against a service-level setting, defaulting to 72 hours. A request that ages out is a host who has already booked somewhere else.
-
8Claim a request. Triaging marks it as picked up and optionally assigns it to somebody by name.Expected result Status triaged, with an event appended to the request's own history.Watch out for Triage is also available from the staff channel without opening the app. Either way the transition is recorded with its source, so 'who picked this up' always has an answer.
-
9Open the composer from the request. The host's words render in a read-only panel beside the editor, together with the application, the event name, the date and the venue.Expected result A blank clause editor next to the host's context.Watch out for The body starts empty and stays empty until you type. That is the control: the host's text is reference material, never a draft. Copying it in by hand defeats the entire design.
-
10Write the clause for a host's free-text note on the application — the 'anything else we should know' answer. You supply three things: the host label for the checkbox, the help text a host reads before ticking it, and the legal body.Expected result A one-off rider scoped to that application and its venue, plus a note on the application recording that you authored it.Watch out for All three fields are required and the refusals say why — help text in particular, because a checkbox with no explanation is how a host agrees to something they did not read. The call is idempotent per application and label, so a double click does not mint two clauses.
-
11From the queue instead, author against the request itself. This creates the rider (or links an existing one) and moves the request to authoring, joining the two objects — the request page then shows live rider state and the rider page shows who asked for it and why.Expected result Status authoring, with the rider key attached to the request.Watch out for If the request came from an application, the rider is created as a one-off scoped to that application and venue. Choose deliberately: a library rider written in a hurry is a clause every future host can tick.
-
12Open the rider. You get its versions, a word-level diff between them, its append-only trail, and where it is currently in use.Expected result Version 1 in draft, not selectable, not on any contract.Watch out for Only a draft is editable. Once a version is in review or approved its text is frozen — corrections are a new version, never a quiet rewrite of the bytes somebody already approved.
-
13Submit the draft for review when the wording is right.Expected result Status in review, and a trail row recording who submitted it.Watch out for Submitting freezes the text. If you spot a typo now, reject it and fork a fresh draft rather than looking for an edit button that is deliberately not there.
-
14Approve the version. This retires whatever version was previously live, makes this the active text, and closes every request linked to the rider — emailing each requester a link back into their application.Expected result Status approved, is-active set, linked requests flipped to approved.Watch out for Approving your own draft succeeds on this install and is permanently marked as self-approved: a chip in every listing, a reason on the trail row, and a notice in the staff channel. If your install turns the two-person rule on instead, the same call is refused and says so.
-
15Reject a version whose wording is wrong, with a reason. The reason is required.Expected result Status rejected, the reason on the trail.Watch out for Rejecting is not deleting. The rejected text stays readable in the version history, which is what makes 'why did we not go with that wording' answerable a year later.
-
16Make the rider selectable, and set how it presents: group, label, help text, sort order.Expected result The rider appears in the form for whoever its scope covers.Watch out for Selectable without an approved version is refused. That ordering is the product decision this whole workflow is built on — the checkbox cannot exist before the clause does.
-
17Decline a request the venue will never say yes to — boxing, pyrotechnics, whatever your licence does not cover — with a reason. The host is emailed.Expected result Status declined and an email carrying your reason.Watch out for Declining is a legitimate answer and it is deliberately as easy as approving. A queue where 'no' is harder than 'yes' becomes a queue where requests rot instead.
Steps 18 — Host / Promoter
their manual →Ticks what the library already covers, and writes the free text that starts a new rider.
-
18Open the link from the 'your request is now available' email. Your application reopens with the new checkbox present.Expected result The clause you asked for, now tickable, with the venue's help text.Watch out for Read the help text before you tick it. The venue wrote the clause, not you — what it commits you to may be narrower, or broader, than what you described.
Steps 19–22 — Venue Manager
their manual →-
19When the same one-off has been written three times, promote it to the library so every host can tick it.Expected result The rider leaves the written-for-you group and joins the standing catalogue.Watch out for Promotion is the deliberate widening this design keeps separate from answering one host. Do it on purpose, not as a shortcut while you are already in a hurry.
-
20Read the library periodically: live riders, retired ones, and which are one-offs. Filter by scope.Expected result The catalogue with self-approved and one-off badges visible in the list.Watch out for Those badges are the control. If a reviewer has to open each rider to find out whether anybody else read it, the control does not exist — which is exactly why they are rendered wherever riders are listed.
-
21Check recent rider activity — approvals inside the review window, with the self-approved ones surfaced.Expected result A short list you can actually read at a Monday meeting.Watch out for Watch the self-approved rate rather than individual rows. A single self-approval is a small team working; every rider self-approved means the second pair of eyes has quietly stopped existing.
-
22Back on the application, read the accepted riders block: what the host actually ticked, with one-off and self-approved flagged inline.Expected result The riders that will be injected into this booking's contract.Watch out for This is the last screen before approval where a wrong clause is cheap to remove. After approval the contract is drafted and only an admin can change it.