A technical rider is the document that tells a venue what your band needs to play: the PA, the monitors, the backline, the power and the people. Written well, it prevents the arguments and surprises that eat a soundcheck. Written badly, or not at all, it leaves every decision to whoever happens to be at the desk. This guide covers what belongs in a technical rider, how to phrase it so a venue can actually meet it, and how to keep it from turning into a wish list nobody reads.
What a technical rider is for
A rider is not a demand letter. It is a shared checklist between the band and the venue, so both sides arrive knowing what is provided and what the band brings. The goal is a show that is set up correctly before you touch an instrument.
Keep it separate from the hospitality rider (food, drinks, dressing room). Mixing the two buries the technical detail an engineer needs under things that belong to the promoter. One document for the desk, one for the green room.
- A shared checklist, not a list of demands
- States what the venue provides and what you bring
- Kept separate from the hospitality rider
- Written for the engineer, not the promoter
Cover the essentials in order
Work top to bottom, the way an engineer thinks: PA and coverage for the room, front-of-house console, monitoring, then backline and stage power. A rider that follows the signal path is faster to read than one that jumps around.
Be specific about quantities and generic about brands. "Four monitor mixes on four wedges" is useful; insisting on one exact model the venue may not own only starts an argument. State the function and the count, and let the venue meet it with what they have.
- PA and coverage appropriate to the room
- Front-of-house console with enough channels
- Monitor mixes: how many and where
- Backline and stage power by position
Say what you bring and what you need
Every line should make clear who supplies it. If you bring your own in-ear system and only need a stereo feed and power, say so, and the venue plans for less, not more. If you need a drum riser or a specific number of DI boxes, list it as a venue-supplied item.
This split is where most rider friction disappears. A venue that knows the band arrives with its own monitoring, its own playback rig and its own DIs can prepare in minutes instead of guessing.
- Mark each item: band-supplied or venue-supplied
- State the feeds you need (stereo music, click separate)
- List venue items: risers, DIs, stands, power
- The less the venue has to guess, the smoother the day
Include the input list and the stage plot
A technical rider without an input list is incomplete. Attach a numbered channel list (kick, snare, down through vocals and playback) and the stage plot that matches it. Together they let the engineer patch and place monitors before you arrive.
If you run backing tracks, spell out the playback feed in the rider: how many channels, in what format, and that the click stays in the band’s monitoring and never reaches the house.
- A numbered input list with the rider
- The stage plot, matching the input numbers
- The playback feed described: channels and format
- The click kept in the band’s ears, not the house
Write it so a venue can actually meet it
A rider that asks for more than the show needs gets ignored, and then the parts that mattered get ignored too. Ask for what the gig genuinely requires. A realistic rider that a small venue can meet in full is worth more than an ambitious one they quietly skip.
Keep the language plain and the layout scannable: short sections, clear headings, quantities in numbers. Put a contact on it who can answer questions, and a date, so the venue knows the document is current.
- Ask for what the show needs, not the maximum
- Plain language, short sections, clear counts
- A technical contact for questions
- A date, so the venue trusts it is current
Advance it and keep it updated
Send the rider ahead with the booking, not on the day. The point of a rider is preparation, and preparation needs time. Pair it with the stage plot and confirm the venue has received both.
Then treat it as a living document. Update it when the line-up, the backline or the monitoring changes, and keep a default version you adapt per venue rather than rewriting from scratch each time.
- Send it with the advance, well before the show
- Pair it with the stage plot
- Update it when the setup changes
- Keep a default you adapt per venue