Tech Rider Template: A Complete Copyable Outline
7 min read · Updated July 14, 2026 · bands, artists, tour managers, production managers
Use this practical tech rider template to organize contacts, sound, monitors, backline, power, stage plot, input list, lighting, and hospitality.
TL;DR — A complete tech rider template has nine working sections: document control, contacts and schedule, FOH and PA, monitors, backline, power, stage plot, input list, and any relevant lighting, video, or hospitality notes. State what is required, preferred, carried, and venue-provided. Keep the stage plot and input list consistent, date every revision, and confirm exceptions during the show advance.
Table of contents
- Copyable tech rider template
- How to fill each section
- Required versus preferred
- How to keep the template current
- Final review checklist
- FAQ
Copyable tech rider template
Use the outline below as a starting structure. Delete sections that genuinely do not apply; do not leave ambiguous blanks.
1. Document control
- Artist / production name:
- Rider version and last updated date:
- Primary production contact:
- Phone and email:
- Intended show format: headline / support / festival / fly date:
- Statement: “Please confirm all deviations with the production contact.”
2. Schedule and access
- Load-in time:
- Soundcheck time and duration:
- Doors and show time:
- Set length:
- Curfew:
- Vehicle, parking, loading dock, stairs, lift, or access notes:
3. FOH, PA, and control
- Minimum input count:
- Required versus preferred console:
- House engineer or touring engineer responsibility:
- PA coverage requirement:
- System processing / drive responsibility:
- Playback, talkback, recording, or communication needs:
4. Monitors and IEMs
- Number of mixes:
- Mix 1 — performer — wedge / wired IEM / wireless IEM — mono / stereo:
- Mix 2 — performer — destination and format:
- Touring or house monitor engineer:
- Artist-carried wireless systems and frequency coordination contact:
- Split, console, or stage rack responsibility:
5. Backline
| We carry | Venue provides | Acceptable substitute | Notes |
|---|---|---|---|
Include drum shell sizes and hardware, amplifier head/cabinet requirements, keyboard model constraints, stands, stools, risers, and any rolling or pre-rigged requirement.
6. Power
- Voltage / frequency compatibility:
- Number and location of stage drops:
- High-draw or isolated-circuit requirements:
- Touring distribution carried by artist:
- Qualified local electrical contact, where relevant:
7. Stage plot
Attach a top-down plot with audience direction, stage left/right, performers, backline, mics, DIs, monitors, power, risers, and dimensions that matter. Start with Stage Plot Examples if you need a layout pattern.
8. Input list
| Ch | Source | Mic / DI | Stand | 48V | Insert / note |
|---|---|---|---|---|---|
| 1 |
Keep the source names and channel numbers identical to the plot. For festivals, let the receiving production decide the final physical patch unless a touring split makes your patch fixed. Learn the distinction in Input List vs Patch Sheet.
9. Lighting, video, and hospitality
- Lighting looks, key light, haze, followspot, or blackout requirements:
- Video playback, screen, projector, camera, or timecode needs:
- Dressing room and towels:
- Water and reasonable meal requirements:
- Accessibility, allergy, or dietary information that must be acted on:
Keep hospitality requests separate from technical signal and stage information when the document becomes long. The production contact should still receive one clearly indexed package.
How to fill each section
Write for the person preparing the room
Each line should support a decision: what to rent, what to patch, where to place it, who supplies it, or who must approve a substitution. “Professional PA required” does not make a decision. “House PA must provide even coverage at the agreed audience capacity; venue supplies system engineer” does.
Separate the touring baseline from show facts
The band's lineup, core inputs, monitor ownership, and carried backline usually belong to the reusable Rider. Venue address, local schedule, parking, and one-off substitutions belong to the show advance. Mixing both into one copied document creates stale dates and venue names.
Make provider responsibility explicit
Use plain verbs:
- Artist carries the playback computer, audio interface, and redundant power supply.
- Venue provides two stable keyboard stands and four XLR lines.
- Promoter confirms the requested drum kit or an agreed substitute.
- Artist approves any console change before show day.
Avoid “TBC” without an owner. Write “Venue to confirm by [date] with [contact]” so the unresolved item has a path to closure.
Connect the map and the channel table
A mic labeled “Vox SR” on the plot must not become “BV 2” in the input list. Use stable names and channel references across the documents. If a stereo keyboard occupies channels 11–12, show one keyboard position with a clear L/R source association rather than two unexplained boxes.
Required versus preferred
Overusing required makes a rider difficult to fulfill and weakens the word when something truly is non-negotiable. Classify requests honestly:
| Label | Meaning | Example |
|---|---|---|
| Required | The show cannot be performed safely or as contracted without it | Safe, correctly rated power; required accessibility |
| Preferred | First choice, but an approved equivalent can work | Preferred console model or vocal microphone |
| Acceptable substitute | A named alternative already approved | Equivalent keyboard stand or amplifier cabinet |
| Artist carries | Travels with the act | IEM rack, playback interface, pedalboards |
| Venue provides | Must be sourced locally | PA, wedges, drum shells for a fly date |
Explain the functional reason for a narrow request. A console may be preferred because the show file and engineer workflow are prepared for it; that is more useful than brand prestige. Safety requirements should be direct and never framed as preferences.
How to keep the template current
A template helps once; a living rider helps on every show. Store the plot, channel list, mixes, power, and backline as one reusable source. When the lineup or equipment changes, update that source and export a new PDF rather than editing several copies.
Send both outputs when possible:
- a dated PDF for printing, offline access, and attachment-based workflows;
- a view-only live link for the latest approved information;
- a clear note identifying which version governs if the two ever differ.
Invite the engineer or tour manager to edit the same Rider when they own part of the information. Techrider.live collaboration is asynchronous: invited editors can open, edit, save, export, and inspect history. It is not simultaneous real-time editing. See Collaborating on a Rider for the workflow.
Final review checklist
- Artist name, version date, and production contact appear first.
- The schedule is show-specific and has been confirmed.
- Required and preferred requests are distinguished.
- Every backline item has a provider.
- Monitor mixes have owners, destinations, and mono/stereo format.
- Power needs are specific and safely described.
- Stage plot names match input list names.
- Input count and channel order are complete.
- Lighting, video, and hospitality sections include only relevant requests.
- Open questions have an owner and confirmation deadline.
- The final PDF is readable on screen and on paper.
- The revision sent to the venue is recorded.
FAQ
What should be included in a tech rider?
A tech rider should include document control, production contacts, schedule, FOH and PA, monitors, backline, power, stage plot, input list, and relevant lighting, video, and hospitality information. Small acts can combine sections; complex productions can expand them.
How long should a tech rider be?
There is no correct page count. Use enough space to make requirements unambiguous, then remove repetition. A readable plot and input list are more important than forcing the package onto one page.
What is the difference between a tech rider and a hospitality rider?
The tech rider covers production requirements such as sound, stage, power, backline, lighting, and video. The hospitality rider covers dressing rooms, food, drinks, transport, and related artist care. They may travel in one indexed package but serve different teams.
Can I use the same tech rider for every show?
Reuse the same core Rider, but advance each show separately. Venue, schedule, local equipment, access, and substitutions change. Preserve the touring baseline and attach confirmed show-specific notes rather than duplicating the entire document.
Is a stage plot enough by itself?
No. A stage plot explains physical placement, but it does not fully describe console, PA, channel, monitor, backline, power, schedule, or provider responsibilities. It is one section of the full technical rider.
Turn the outline into one reusable Rider
Build your tech rider in Techrider.live, then export a PDF and share the current view-only link from the same data. For a guided first pass, use How to Write Your First Tech Rider.
Last updated: 2026-07-14 · Reviewed by the Techrider.live team for clear venue handoff and repeatable show advancing.
Related guides
How to Make a Stage Plot for Your Band (5-Minute Guide)
A 5-step walkthrough to make a clean, engineer-readable stage plot for your band — set the stage, place performers, add gear and mics, then export a PDF and share link.
9 min readTutorialsFree Stage Plot Template (Download + How to Use)
A stage plot template is a pre-laid-out starting point for your band's stage map. Pick one of four shapes, customize performers and gear, and export a PDF.
9 min readTutorialsHow to Build an Input List / Patch Sheet (with Template)
A channel-by-channel table of every source on stage. Learn the input list columns, the drums-to-vocals ordering, 48V and DI rules, and how a patch sheet differs.
7 min read