How to Draft a Conference Technical Rider in 2026

A practical structure for a conference technical rider: from input data and a requirements table to change management, acceptance and stop factors.

A conference technical rider is often started with a list of equipment. As a result, the document contains models of microphones, screens and mixing consoles, but does not answer the main questions: what programme must the system support, who confirms the parameters, when do changes close, and what does the team do if the primary solution fails.

At Aventura, we build the rider from the scenario to the technology. First we fix the format of the presentations, transitions, content, streaming and venue constraints. Then we translate them into verifiable requirements. Every critical line gets a confirmation, a deadline, a person responsible and a backup.

Such a document helps the client compare proposals on a single basis. The technical team understands the scope of work. The venue sees the requests to its systems and access. The production team gets a clear conference management scheme.

How does a technical rider differ from a scope of work, an audit and a rehearsal?

A conference technical rider describes the requirements for the entire assembled technical system and the conditions under which it operates. A scope of work defines the contractor's volume of work and the expected result, while an audit verifies the venue's capabilities. A rehearsal tests the already assembled system against the event scenario. These documents and stages are related but do not replace one another.

The rider becomes an appendix to the scope of work or its technical part. It sets out signals, connections and system readiness criteria in greater detail.

A technical venue audit is carried out before the working version of the rider is prepared or in parallel with it. During the inspection, the team checks geometry, connection points, load-in routes, network access, installation restrictions and the venue's rules. If the audit reveals a ban on rigging or that a required area is unavailable, the rider is changed before equipment is ordered.

A technical event rehearsal takes place after installation and setup. It checks microphones, lighting states, video, captions, remote feeds, director's cues and transitions between speakers. The rider states what must be prepared and how. The rehearsal shows whether this works in the real sequence.

We use a simple boundary:

Errors arise when one stage is used in place of another. A detailed rider does not confirm the building's capabilities. A successful audit does not check the final files. A rehearsal should not be the first time a missing connection is discovered.

What input data is needed before drafting a rider?

A rider starts with the programme, the venue and the show and broadcast scenario. Without them, the technical team has to guess the number of work zones, how speakers enter and exit, the signal set and the level of redundancy. The first version can be preliminary, but it must clearly show the unknown parameters and the deadlines for confirming them.

We request the following from the client and the programme team:

1. Conference format: in-person, online or hybrid.
2. A draft programme with halls, sessions, breaks and parallel tracks.
3. Types of sessions: presentation, panel, interview, product demo, remote link-up.
4. The proposed layout of the stage and auditorium.
5. Requirements for recording, broadcasting, interpretation, captions and accessibility.
6. Rules for handling presentations, video and partner materials.
7. Brand restrictions on stage design, colour, graphics and logo placement.
8. Venue data on power, network, rigging, access and installation.
9. Contacts of the decision-makers on the client, venue and contractor sides.

Speakers need a separate data stream. We establish whether the person is speaking from a lectern or while moving, whether they are taking part in a panel, whether they are showing a demo from their own device, and whether they are joining remotely. This information is best collected through the conference speaker office, so that biographies, files, technical requests and the schedule do not live in different chats.

Every unknown parameter gets a status. You can use labels such as "confirmed", "awaiting response", "test needed", "depends on a programme decision". An empty cell is more dangerous than an honest status: it is easily mistaken for an agreed value.

Input data changes as preparations progress. That is why the rider should separate the original requirement from the technical solution adopted. The client may ask for a remote link-up. The specific communication channel, capture device and backup are chosen by the technical team after checking the venue and the platform.

Rider structure and a sample requirements table

A conference technical rider consists of a brief introduction, diagrams and tables for each technical block. At the start of the document we record the event, venue, version date, the person responsible for the file and the approval status. Then we provide the overall layout of the halls and connections. Details go into the sections on each system.

A rider may have several appendices: a floor plan, a wiring diagram, a patch list (that is, a list of physical and network connections), a power plan, a content list, an installation schedule and an acceptance sheet. The appendices must reference a single version of the main document. Otherwise the team will end up with an up-to-date table and an outdated plan.

It is useful to keep the main register in the format "parameter - requirement - confirmation - deadline - backup":

In the "Confirmation" row we state a result that can be verified. A message saying "everything will be fine" does not confirm a system. Confirmation can be a diagram, written permission, a test file, a check connection, a signed sheet or a re-check of a flagged issue.

In the working version, it is best to identify the responsible person by role and name. For example, the venue network lead, the broadcast director or the presentation director. The generic wording "technical team" does not show who to go to for a decision.

If you need a single production framework, conference organisation connects the programme, venue, contractors, speakers and technical rider. We define requirements before the budget and manage them through to on-site acceptance.

How to describe sound without a list of random equipment?

The sound section starts with scenarios for speech, music, remote contributions and recording. The microphone model appears after the task, the room acoustics and the frequency planning. If a rider starts with a brand and a number of devices without describing the programme, contractors may offer a formally similar kit with a different result.

For each room we describe:

• who speaks and how they move around the stage;
• which microphone scenarios are needed for the presentation, the panel and questions from the floor;
• where the audio from the presentation, video and remote participant comes from;
• who needs a separate monitor signal or intercom;
• what goes to the room, the recording, the broadcast, the interpretation and the press area;
• which channels are considered critical and how they are backed up;
• where the mixing console, radio system, patch points and operator workstation are located.

In the conference technical rider we trace the entire signal path: from the microphone to the sound system, the broadcast and the recording. This logic is confirmed by Shure's guidance, which presents the sound system as a chain of capture, processing, amplification, transmission and recording.

Radio microphones require a separate plan. The technical team checks the available frequency resource, channel compatibility, the antenna system, receiver placement and the handover procedure before going on stage. Specific values are determined after a site survey and equipment coordination, rather than copied from a previous project.

A backup microphone must be built into the working scenario. It is not enough to leave a device backstage. The stage manager must know where it is, the operator must know which channel it is routed to, and the director must know how the programme will continue during the swap.

We also separately document the speakers' sound check. During it, the team selects the mounting method, checks clothing, voice level, pronunciation of names and media playback. This check complements the general technical rehearsal and reduces the number of decisions made immediately before going on stage.

Stage, lighting and screens work as one system

Stage, lighting and video cannot be described in isolation: the size and position of the screen affect the layout, sightlines, cameras and lighting. Stage design changes the placement of acoustics and cables. A lighting fixture can interfere with the screen or end up in shot. The rider should show these relationships on a single diagram.

In the stage section we specify the geometry and purpose of the zones: performance, panel, demonstration, waiting, interpreter, entrance and exit. For the podium, furniture, decor and temporary structures we record locations, installation method, venue requirements and those responsible for approval. Load calculations and structural approval are carried out by specialist engineers.

We describe lighting through the programme's states. Working light is needed for the presentation, panel, moderator's entrance, video screening, break and filming. For each state we define the purpose, stage zones, camera restrictions and switching procedure. Colour and brightness are checked against the actual stage design and screens.

For screens we record:

1. The purpose of each screen or surface.
2. The signal source and the control position.
3. The format and orientation of the content.
4. The placement of confidence monitors for speakers and the director.
5. The signal route to recording and broadcast.
6. The backup source and switching procedure.
7. The test conditions with the actual presentations and video.

We check sightlines from the extreme and problem seats, as well as from the camera positions. A screen may be visible to the central section but blocked by decor for a side row. A confidence monitor may help the speaker but end up in the wide shot. Such conflicts are best resolved on the plan, then confirmed during the build.

How do you bring presentations and video under technical control?

Content becomes part of the technical system once the team defines formats, delivery channels, the master version, verification and playback backup. A file sent via a messenger is not yet ready for showing. It must be received, tested on the playback system and linked to a specific agenda item. Verification is completed before the agreed freeze deadline.

At Aventura, we assign a single channel for submitting materials and a single person responsible for the materials package. The detailed procedure is set out in the article on freezing presentations before a conference. The technical rider retains the technical rules: permitted formats, naming template, storage location, verification status and the late-replacement procedure.

For presentations, we check fonts, animation, embedded media, links, speaker notes and display on the actual screen. If the speaker uses their own device, the rider describes the connection, adapters, corporate security permissions and a backup file on the playback system.

For video, we need details of the container, codec, resolution, frame rate, audio and how it is launched. The technical team approves these parameters for the specific playback system. A generic line saying "we accept any file" creates a risk of on-site conversion.

A separate sheet links content to the run of show:

If the conference uses live captions, the rider specifies the clean audio source, the method of text delivery, the display location and the person responsible for monitoring. W3C describes captions as a synchronised text version of speech and significant non-speech information. Automatic recognition should be checked and corrected rather than assumed to be accurate by default.

Internet and broadcast are designed separately from guest Wi-Fi

The conference production network must be separated by purpose from guest access. Broadcast, remote contributions, media servers, control, registration and operational communications create different streams. Each needs a responsible specialist, a connection diagram, access rules and a tested backup. This is how the team separates managed infrastructure from user access.

We start with the connection and data exchange diagram. It shows which devices exchange data, where the internet connects, which addresses and protocols need to be agreed, where the connection points are located and who manages the network equipment. The corporate information security service may restrict ports, applications, external devices and wireless networks. These restrictions are collected before testing.

We build the network section of the rider based on actual streams, the platform, the number of devices and the video format. The checklist includes bandwidth, routing, firewalls, media traffic priority and wireless network conditions. Microsoft highlights these same blocks in its network preparation documentation for Teams; we do not carry over the generic figures from it.

The broadcast rider includes:

• the set of cameras and sources;
• the video mixing and graphics diagram;
• separate audio channels for the broadcast and for feedback;
• the platform and access parameters;
• the communication channel with remote speakers;
• recording of the programme and individual sources;
• output monitoring for the technical team;
• the primary and backup transmission path;
• the procedure for switching to backup and communicating with viewers.

For a hybrid event, the venue and the stream need to be synchronised. The online viewer must understand pauses, questions and transitions. The speaker in the venue must hear the remote participant without an acoustic loop. The director must see the connection status before announcing the link-up.

We describe critical control, media streams and guest traffic separately. Access rights and backup cabling infrastructure also get their own lines. This approach aligns with Disguise's network configuration principles, although its product scheme is not mandatory for a conference.

Before the event, we run a test from the actual connection point and with working equipment. Checking with a browser on a manager's laptop does not confirm that the broadcast system is ready. For online events and broadcasts, we separately test the signal path, monitoring and switching to backup.

Power supply, cable routes, access and installation

This section links the engineering plan to actual on-site work. The team lists consumers, connection points, distribution, protection, cable routes, access times and the personnel permit procedure. Electrical safety decisions are confirmed by competent site and contractor specialists. This reduces the risk of conflicts between the design and the actual installation conditions.

We do not write a general request in the rider to "provide sufficient power." The technical lead compiles loads by system. The site representative confirms the available points and restrictions.

A qualified specialist issues or checks the connection diagram. After changes, the calculation and diagram are re-verified.

When working with temporary electrics, we separately record equipment selection, installation, maintenance and cable protection. The HSE event safety page also requires protecting equipment from adverse conditions and unauthorized access, and cables from mechanical damage. For a specific project, the country's regulations, the venue's rules and the project decisions apply. In the rider we state who designs, connects, inspects and grants permits.

The cable route is marked on the plan. We check crossings with guest flows, evacuation routes, doors, catering operations, cleaning and vehicle movement. The route must remain accessible for monitoring while being protected from accidental disconnection or damage.

The installation section includes:

1. Handover time of zones to the technical team.
2. Procedure for entry, unloading and removal of packaging.
3. Lists of people, vehicles and equipment for permits.
4. Available gates, lifts, corridors and storage areas.
5. Restrictions on noisy work, tools and fixing.
6. Assembly sequence for interdependent systems.
7. Checkpoints for setup, cleaning and handover of guest areas.
8. Dismantling time and the procedure for returning the venue.

The rider must match the installation schedule. If a screen is needed for video setup, it cannot be installed after the time allotted for content checks. If a service passage is closed off by decor, equipment is brought through before closure or the work order is changed.

Access is confirmed before the team departs. The document needs the site responsible person's contact, the communication method, the place to collect passes and the route for a disputed situation. The phrase "security has been notified" does not help if there are no lists on shift or the vehicle arrived at a different entrance.

Change log and freeze protect the agreed system

A change log shows what changed, who requested the edit, which blocks it affects and who approved it. A freeze point is the moment after which the team separately assesses the impact of each change and routes it through the agreed process. Both tools keep the conference technical rider manageable.

The rider must have one owner and one master version. A file name alone does not solve the problem. In the header we state the version number or date, the status and the list of current attachments. We keep old versions in an archive and remove them from the team's working folders.

A minimum change log contains:

We separate the content freeze from the technical freeze. First the programme team confirms the line-up of talks and materials. Then the technical team closes the configuration, schematics and schedule. A late edit is assessed for time, cost, safety, staff, equipment and the need for a repeat test.

The decision on a late change is made by the owner, who assesses the consequences for the whole project. A speaker may request a new video but must not replace the file in the playback system themselves. The venue may change the access window, but the team must recalculate the build-up and confirm that system testing is still possible.

After the freeze, any accepted change is issued as a new version. Verbal agreement in a chat does not count as a rider update. Technical posts receive a short notification of what has changed specifically for them.

How does acceptance testing work and what becomes a stop factor?

Acceptance testing confirms that the system is ready according to observable criteria. The team goes through the checklist block by block, records issues, assigns a responsible person and repeats the check after the fix. A stop factor is a condition under which a safe or controlled launch of the chosen scenario is impossible. The decision on approval is made by the specialist responsible for the relevant technical risk.

Acceptance is not the same as switching on the equipment. We check how the system works in its connections:

1. Sound travels in all required directions and the backup channel is ready to take over.
2. Lighting states match the stage, cameras and video.
3. Presentations, videos, captions and service monitors run according to the scenario.
4. Remote connections have passed a test connection with feedback.
5. Recording and streaming receive the agreed sources.
6. The production network is monitored, and the backup has been verified in an available way.
7. Power supply and cable routes have been accepted by the responsible specialists.
8. The team knows the launch commands, communication channels and the procedure for responding to a failure.
9. Rehearsal issues are closed by a repeat test or have an approved limitation.

Stop factors are defined before installation. These include:

• unconfirmed structural safety;
• lack of permission for electrical connection;
• inability to protect the cable route;
• failure of a critical channel without a working backup;
• a programme change that the team does not have time to verify.

The specific list depends on the project and the venue's requirements.

For each stop factor, a person responsible for the decision is appointed. The technical lead stops unsafe connections. The person responsible for the structure does not allow a stage element without confirmation.

The broadcast lead does not put an unverified remote channel on air. The producer and the client make the programme decision if the technical scenario needs to be simplified.

The acceptance checklist keeps the status of each check: accepted, issue, repeat test, limitation, stop. The wording of an issue must be specific. Instead of "bad sound", we write where and under which scenario the problem occurs, who fixes it and how the team will confirm the result.

After acceptance, the rider becomes the basis for work on the day of the conference. Operators have up-to-date diagrams and contacts. The directing team has verified commands. The client has a clear boundary between the agreed system and new requests.

Sources

• Shure: Audio Systems Guide for Meetings and Conferences
• Microsoft Learn: Prepare your organization's network for Microsoft Teams
• W3C Web Accessibility Initiative: Captions and Subtitles
• HSE: Electrical safety at events
• Disguise User Guide: Disguise System Network Configuration