Start with program functions and acceptance conditions
Describe the activity before requesting the hardware. State whether a presenter must advance slides from the stage, hear a remote participant or move between a lectern and a seated discussion. Explain what the audience must see and hear. These functional statements allow the production team to evaluate suitable options.
Define how each essential function will be checked. For example, a hypothetical hybrid panel might require an onsite moderator and remote panelist to converse while presentation content remains visible to both audiences. The rider should call for a rehearsal of that interaction, not merely mention a video meeting connection.
Describe the boundaries between systems
An interface is any point where one party’s equipment, content or service must work with another’s. Identify who supplies presentation files, who operates playback and who controls slide advancement. For remote participation, identify the meeting-platform owner and who coordinates venue network requirements with production.
Record known file formats, playback needs and connection information, but label anything unconfirmed. Ask the production provider to resolve technical compatibility rather than assuming that a connector name establishes a working signal path. If audio accompanies a presentation, explicitly include that requirement so it is tested with the actual content.
Assign supply, operation and approval separately
The party supplying an item is not always the party operating or approving it. A speaker may supply a presentation while the event team approves the content and production handles playback. Make those responsibilities separate entries so a late revision has a clear route.
Name decision-making roles, not just organizations. Identify who can approve a substitute, accept a changed stage layout or resolve conflicting presenter requests. Route structural loads, electrical work and rigging questions to qualified professionals and the venue. A rider records the need for those approvals; it does not grant them.
Keep requested and approved requirements visibly different
Give the document a version identifier and an owner. Use clear statuses such as requested, under review and approved. Include open questions beside the affected requirement rather than burying them in an email chain. A copied rider from an earlier event should be treated as a starting reference, not evidence that the new room supports the same arrangement.
Separate essential outcomes from preferred approaches. If a presenter prefers a particular method of seeing notes, explain the underlying need and ask for a proposed solution. Exact configurations require a quote, and changes to the approved scope should be reviewed before they are represented as settled.
Issue a rider that people can act on
Organize the final document around program segments and their shared requirements. Remove conflicting duplicates, link each open item to an owner and identify the planned review point. Attach the relevant agenda and layout version so reviewers know which event plan the rider describes.
Ask recipients to acknowledge their responsibilities and flag exceptions. Silence is not useful confirmation. For Xperience Entertainment’s corporate AV planning, a rider is most useful when it supports a focused scope discussion rather than prescribes an unreviewed equipment package.
- State the required audience and speaker functions.
- Identify every cross-team interface.
- Separate supply, operation and approval owners.
- Mark unresolved requirements and document versions.
Put the plan into practice
A strong technical rider makes intent, interfaces and authority clear. Write it as a shared decision document, then use professional review and the quote process to establish the exact production configuration.
Corporate AV and event production in Arizona
