Tech rider

The rider translates a performance into requirements that another team can evaluate. It may describe audio inputs, monitoring, backline, playback connections, stage space, power needs and technical staffing. Its value comes from making these requirements explicit before equipment and schedules are finalized, not from making the document as long as possible.

The receiving team reviews the request against the event's resources and constraints. Questions, substitutions and limitations are then resolved through technical advancing. The final agreement may differ from the original request, so clear revision dates and a named technical contact help prevent an outdated version from becoming the working plan.

Unstated assumptions become expensive in time even when no additional equipment is needed. A keyboard player expecting two direct inputs may arrive to find only one allocated channel. A singer relying on a personal in-ear system may discover that the required mix output was never discussed. A useful rider exposes these dependencies early.

The document also helps distinguish essential requirements from preferences. An exact item may be necessary for compatibility, while a functionally suitable alternative may work elsewhere. Stating the reason behind a requirement makes review more constructive and reduces the risk that a supplier substitutes something that looks similar but cannot perform the required task.

A stage plot complements the rider by showing where people and equipment belong. It does not replace connection details, and an input list does not replace the spatial information needed to plan stands, cable routes and performer access.

Clear language separates what the act brings from what the production must provide. It also identifies interface details such as connector type, output level and whether a feed is mono or stereo. Equipment names without these relationships can leave both sides believing the other has supplied a crucial cable or adapter.

• Identify essential functions and explain compatibility-sensitive requirements.
• Mark acceptable substitutions rather than treating every preference as mandatory.
• State who supplies instruments, stands, direct boxes, playback devices and personal monitoring equipment.
• Provide a reachable technical contact who can approve practical changes.

A rider may form part of a contract, but its legal effect depends on the actual agreement and applicable circumstances. Do not assume that sending a document proves every request was accepted. Keep written confirmation of material changes, particularly where they affect safety, staffing, technical feasibility or performance delivery.

Power, rigging and structural requests require review by competent personnel. A performer's specification does not establish that a proposed arrangement is safe. Requirements should be coordinated with site rules and responsible specialists rather than presented as permission to bypass them.

An act preparing for a Dubai event sends a rider describing two vocal microphones, stereo keyboard outputs and a playback system. The stage plot places the keyboard station at one side, but the input list labels only a single keyboard channel. The production engineer flags the inconsistency before the equipment allocation is finalized.

1. Ask whether the keyboard requires stereo operation or can provide an approved mono output.
2. Confirm whether playback includes separate programme and click feeds.
3. Identify which outputs belong in the audience mix and which are performer-only.
4. Agree the available monitor arrangement and document any substitutions.
5. Issue a revised input list and plot with matching labels and a clear revision date.

The clarification prevents a private click track from being treated as ordinary programme audio. It also makes the onsite patch simpler because the crew works from one agreed version. During soundcheck, the team verifies that the actual equipment follows those agreed signal relationships.

• Sending an old rider containing instruments or performers that are no longer part of the show.
• Using channel names that differ between the input list, console file and stage plot.
• Requesting a brand without describing the function or explaining whether alternatives are acceptable.
• Omitting who supplies personal devices, adapters, batteries or necessary interface equipment.
• Treating a rider as a one-way demand rather than a document requiring review and confirmation.

Ambiguous orientation is another frequent problem. Stage left and stage right should follow the performer's perspective when facing the audience, and plots should make their viewpoint clear. A simple orientation label prevents mirror-image setups and avoids unnecessary movement once cables and stands are already installed.

Avoid hiding show-critical notes in unrelated material. Hospitality requests and promotional information can be managed separately so the working technical document stays easy to scan. Important warnings about playback routing, unusual equipment or access requirements should be visible to the people responsible for those tasks.

Treat the rider as controlled production information. Give it a clear act name, revision date and technical contact, then retire superseded copies. When the lineup or playback arrangement changes, update the input list and plot together rather than adding an informal message that may not reach the stage crew.

The separate tech rider and stage plot guide explores document preparation in greater detail. In glossary terms, the central distinction is simple: the rider communicates technical needs, while the advancing conversation establishes the deliverable arrangement. Both are necessary for a shared understanding of the performance setup.