How to Write a Technical Rider for Live Events (With Examples)

A technical rider is the document that tells the venue and the AV supplier exactly what an act, a speaker, or a client needs to perform or present. Written well, it prevents the most common disasters: power that does not match the spec, stages that cannot take the rigging load, talent that cannot hear themselves because the monitoring was not booked.

Here is how to write one that actually gets read.

What a technical rider is for

A rider is not a wish list. It is a working document that the venue, the AV supplier, and the production company all use to plan the day. Three audiences will read it:

• The venue (to confirm power, access, rigging, and time slots)
• The AV supplier (to confirm kit, crew, and call times)
• The production company or event manager (to coordinate everything else around it)

If your rider does not give all three what they need, you will get phone calls.

The sections every technical rider needs

A working rider has six sections, in this order.

1. Contact and event details

Who is performing, who is producing, who owns the show. Include direct mobile numbers for the production manager and the lead engineer. Do not bury the contact list in a footer.

Example:

• Event: Northern Lights Conference, Day 1 Keynote
• Date: 14 November 2026
• Venue: Manchester Central
• Production: pro-posal.io Productions Ltd
• Production manager: Sam Lee, 07700 900111
• Lead audio engineer: Priya Shah, 07700 900222

2. Stage and layout

Stage size, height, finish, and load-bearing capacity. Position of monitor wedges, side fills, drum riser. Backline placement. A simple stage plot diagram is worth more than three paragraphs of description.

Example: "Stage 8m wide by 4m deep, minimum 600mm high, black skirt to the floor. Three monitor wedges across the front edge. Drum riser 2.5m by 2m, stage right."

3. Power and rigging

The two things venues get wrong most often.

For power: total amperage, phase configuration, location of distro points, isolation requirements.

For rigging: total weight, point loadings, bridle requirements, ceiling height to lowest point, rigging access window.

Example: "Lighting truss: 4 motors, 250kg per point, 5m trim height, rigged from existing house steel between 06:00 and 09:00."

4. Audio

This is where most riders go wrong by under-specifying. Be specific about the FOH desk model, the monitor desk model, the number of channels, the input list, and any wireless requirements.

Example FOH spec:

• Desk: Digico SD12 or equivalent (Yamaha CL5 acceptable as alternative)
• Channel count: 56 channels
• Front of house position: centre, behind audience, on a rostrum no less than 600mm high
• Snake: minimum 48 send, 8 return
• Comms: Tecpro 4-channel intercom from FOH to stage, monitor world, lighting, and video

Include the input list as a numbered table, not free text. Every channel number should have an input, a source, a mic or DI choice, and any insert requirements.

5. Monitoring and IEM

Be specific about wedges versus in-ear, and which performers use which.

Example: "Lead vocal: Shure PSM1000 IEM, single mix. Drums: Shure PSM900 IEM, dedicated mix. Bass and guitar: shared stage left wedge."

6. Video, lighting, and stage management

Same approach: be specific. Resolution and format for the projector or LED wall, number of inputs needed, redundancy requirements. Lighting cue points, follow spots, blackout cues. Stage management call times and contact.

7. Schedule

Load-in, set-up, line check, sound check, doors, show, de-rig. Include time windows, not just single times. Example: "Load-in 06:00-09:00. Set-up 09:00-12:00. Line check 12:00-13:00. Sound check 14:00-15:30. Doors 18:30. Show 19:00. De-rig 22:00-00:30."

8. Terms and what is excluded

What the rider includes, and what the supplier or venue is responsible for separately. Catering, accommodation, dressing rooms, comms with talent, parking, security: all of these get assumed away if not stated.

The five things that go wrong most often

• Power gets booked at the wrong amperage. State total amps and phase. Do not assume the venue knows what 16A single phase means for your distro.
• Rigging gets refused on the day. Confirm load points with the venue rigger in writing before the show.
• The input list is approximate. "Around 30 channels" turns into a sound check delay. Specify.
• Comms are forgotten. If you need intercom between FOH, monitors, stage, lighting, and video, list every position.
• Crew calls are vague. "Crew arrive in the morning" leaves the venue with no security or building access plan.

How to format a rider so it gets read

Use a clean PDF with sectioned headings, a stage plot diagram, and the input list as a table. Send it with the proposal, not after the contract is signed. Update the version number every time you change it ("Rider v3, 14 November 2026") so everyone knows they are reading the latest.

If your proposal tool lets you attach a separate technical specification section, you can keep the rider in the same document as the rest of the brief. That way the client has the full picture in one place.

pro-posal.io includes a technical specification section type designed exactly for this: rich-text formatted, downloadable as part of the proposal PDF, with version history if anything changes. Try it free: pro-posal.io.