A sponsor demo that needs a wired connection is not a last-minute request. It is a planning boundary that should have been written down, priced, and tested before load-in. The failure mode is rarely exotic: a demo that streams video, syncs a device, or calls a remote service works in the sponsor’s hotel room on hotel Wi-Fi, then stalls on a show floor where the general wireless network is carrying thousands of attendee devices and the nearest hardline drop is 40 meters away in an aisle the venue has already carpeted.
This article is a rider-writing workflow for the booth coordinator and the show-floor AV lead. It treats the sponsored-booth technical rider as a boundary-and-fallback document: it names who supplies each dependency, what the booth must do on the show floor, and what happens when the network, power, or display path fails. It does not assume the venue’s general Wi-Fi or a product link covers the demo.
What a sponsored-booth rider is for
A venue audiovisual rider records the technical conditions an event needs, including sound, lighting, staging, power, video, scheduling, and responsibilities. That definition comes from a venue template comparison published by Mississauga Convention Centre, and it is a useful starting point because it puts responsibilities in the same sentence as equipment. A rider is not an order form and not a wish list. It is the shared record of what must be true for the booth to open on time.
The same source is explicit that a rider does not mean every requested microphone, screen, cable, technician, network connection, or power arrangement is automatically included. Those details must be confirmed for the specific event. That sentence is the whole argument for writing a sponsored-booth rider separately from the general event rider. A sponsor’s demo has its own dependencies, its own operator, and its own failure modes. If those dependencies live only in an email thread with the sponsorship sales team, nobody on the show floor owns them.
Two conventions from the same template are worth adopting verbatim. First, mark every item as required, preferred, to confirm, or acceptable substitute. Second, end the document with an ownership table that names who supplies each item. A rider that lists a wired drop but does not say who orders it, who pays for it, and where it terminates is a document that will be renegotiated at 07:30 on load-in day.
Organize the rider around demos, not equipment categories
The usual rider is organized by category: power, network, display, audio. That structure is easy to write and hard to test, because a demo does not fail by category. It fails somewhere along an end-to-end path: power reaches the device, the device reaches the network, the network reaches the service, the service output reaches the display, and an operator is present to restart the sequence. The unit of planning should be the demo, and the rider should describe each demo’s full path.
For each demo, record the following as rows in a table:
- Demo name and booth number, plus the sponsor contact who can approve a substitution on site.
- Power: device count, approximate draw, connector type, and whether the circuit must be dedicated.
- Network: wired or wireless, upstream service, expected traffic pattern, and whether the demo fails closed or degrades gracefully when the link drops.
- Display and audio: source device, signal type, resolution and frame rate, and the conversion boundary if any.
- Control device and operator: who runs the demo, on what device, and whether that person is on the booth staff or remote.
- Status: required, preferred, to confirm, or acceptable substitute.
This is a recommendation, not a published standard. The value is that it forces the sponsor to describe the demo as a sequence rather than as a shopping list, and it gives the AV lead a checklist that maps to what will actually be tested.
Separate venue infrastructure from sponsor and AV-provider items
Most booth failures at the network layer are ownership failures. The venue supplies a service, the sponsor assumes a different service, and the AV provider supplies a switch that nobody asked for. The rider should have three columns for every dependency: venue-provided, sponsor-provided, and AV-provider-provided, with a named contact in each cell.
The Javits Center exhibitor guide is a useful example of how a venue frames this. It lists wired internet connectivity as a dedicated-bandwidth managed service with options up to 1 Gbps, and it lists high-density wireless as a building-wide service. It then states that for business-critical tasks such as product demos, wired internet is highly recommended to avoid signal interference. That is a venue-specific recommendation, not a universal rule, but it is exactly the kind of statement a rider should capture in writing rather than infer from a package name.
The same guide shows why written confirmation matters. It asks exhibitors to submit a booth diagram showing where electrical, internet, and plumbing services should be installed, and says submitting the diagram before arrival helps reduce labor costs and prevents installation delays. It also specifies what the diagram must contain: power drop wattage marked (for example, 500W, 1000W, 1500W), internet placement indicated with an “I”, and the event name, booth number, measurements, and booth orientation included. A revision should be labeled clearly with a revision date.
Treat that diagram as a test artifact, not paperwork. If the diagram cannot show where the wired drop lands relative to the demo table, the demo has not been planned. A drop that terminates behind a backwall or under a carpeted aisle is a drop that will be relocated on load-in day, and relocation is where labor costs and delays appear.
Write the network section around the demo’s actual traffic
The network section is where sponsored-booth riders are usually thinnest. “Wi-Fi required” is not a requirement; it is a hope. The rider should describe the demo’s traffic and its failure mode, then name the service that matches.
Ask the sponsor four questions and record the answers:
- What does the demo do when the link drops? Does it pause and resume, fail closed, or corrupt state? A demo that fails closed needs a fallback that is rehearsed, not a spare cable in a case.
- Is the traffic upstream, downstream, or symmetric? A demo that uploads telemetry has a different requirement from one that streams video to a display.
- Does the demo need a public address, a fixed IP, or DHCP? The Eventbrite RFID access-control rider is a useful example of how specific this can get: it requires one unrestricted hardline internet connection with DHCP at every scanning or check-in location, for every 10 portals if applicable, and sets a minimum speed of 4 Mbps up and down per hardline drop. That is an access-control rider, not a booth-demo standard, but it demonstrates the level of specificity a rider can carry.
- Who tests it, and when? A demo that works in the sponsor’s hotel room is not evidence that it works on the show floor. The rider should name a test window during load-in and a pass/fail record.
Where the demo depends on a venue service, require written confirmation of the specific service, the drop location, and the test window. Do not infer inclusion from a package name. The Javits guide’s POS Wi-Fi example makes the point: it states that a Javits technician must manually configure the device on site to ensure it is secure. A service that requires an on-site configuration step is a service that needs a scheduled appointment in the rider, not a line item assumed to be self-service.
Define the test-and-acceptance sequence
A rider without an acceptance test is a plan without a verification step. The sequence below is a recommendation; adapt the durations to the show’s load-in schedule and write the actual times into the rider.
- Power and physical: confirm the drop location matches the diagram, confirm the circuit is live, and confirm cable paths are secured. The Eventbrite rider’s cable-management language is a reasonable model: all cords, plugs, and potential tripping hazards connected to equipment must be safely secured, tied down, and tucked away from attendees and staff.
- Network link: confirm the demo device receives an address, reaches the named upstream service, and sustains the expected traffic pattern for a defined interval. Record the result as pass or fail with a timestamp.
- Display and audio path: confirm the source device reaches the display at the agreed resolution and frame rate. Connector names such as HDMI, SDI, or USB-C do not by themselves define resolution, frame rate, direction, conversion, or content, so the rider should record the agreed format rather than the connector alone.
- Operator rehearsal: the person who will run the demo performs the start, stop, and recovery sequence once, in the booth, on the show-floor device.
- Fallback rehearsal: the named decision owner switches to the fallback and confirms the demo degrades in the agreed way.
Keep presentation files and demo builds under version control, and provide a tested primary and backup playback path. That practice comes from corporate AV rider guidance, and it applies to booth demos as well: a demo that exists only on one laptop is a single point of failure with a sponsorship logo on it.
Include a fallback table with named decision owners
A spare cable without an authority to switch to it is not a recovery plan. The rider should include a fallback table with three columns: the failure, the immediate check, and the agreed fallback with a decision owner. The corporate AV rider guidance published by Techrider.live models this pattern for presentation and remote-guest failures; the same structure works for booth demos.
| Failure | Immediate check | Agreed fallback and decision owner |
|---|---|---|
| Wired drop does not pass traffic | Link light, address assignment, upstream service reachability | Switch to the pre-tested backup path (secondary drop or approved wireless service); decision owner: show-floor AV lead |
| Display shows no signal | Source output state, cable, switcher input, agreed resolution | Switch to backup playback device or alternate input; decision owner: booth coordinator |
| Demo device fails | Power, boot state, last known good build | Restore from versioned backup build; decision owner: sponsor technical contact |
| Power circuit trips | Load on circuit, device draw versus rated capacity | Move agreed non-critical devices to a second circuit; decision owner: venue electrician with AV lead |
The decision owner matters because the alternative is a conversation between three people who each believe someone else can authorize the change. Name one person per row, and give that person a phone number in the rider.
Attendee data and sponsor integrations
Sponsored booths often collect attendee data: badge scans, lead-capture forms, demo sign-ups. The rider should state what data the booth collects, where it is stored, and who is authorized to export it. This is a scope statement, not a compliance certification. A rider records the approved workflow; it does not create permission, and it does not certify that a sponsor’s integration meets any particular privacy regime. If the event has a data-handling policy, reference it by name and attach it.
The practical rider line is short: “Booth collects [field list] via [device or form]; export owner is [name]; retention period is [period]; attendee consent language is [reference].” If the sponsor cannot fill that line in before load-in, the integration is not ready to run on the show floor.
What the rider does not do
A stage plan documents intent; it does not certify rigging, electrical, accessibility, occupancy, or egress compliance. The same limit applies to a sponsored-booth rider. It is a planning and handoff document. It does not replace the venue’s electrical work rules, the fire marshal’s review, or the show’s safety plan. Write that sentence into the rider so nobody mistakes a signed rider for an inspection.
It is also worth being precise about standards. ESTA describes itself as a nonprofit trade association for the entertainment technology industries and points to its Technical Standards Program, but its public overview page does not establish a booth-network rider standard. AVIXA describes its standards as recommended practices created by subject-matter experts, and its standards overview page does not name exhibitor booth network riders. Neither source should be cited as governing a sponsored-booth network requirement. If a venue or insurer cites a specific standard, get the exact document number and edition and attach it to the rider.
Copyable artifact: sponsored-booth technical rider template
Copy this structure into a document or spreadsheet. Use the status field on every row: Required, Preferred, To confirm, or Acceptable substitute.
SPONSORED-BOOTH TECHNICAL RIDER
Event: [name] | Venue: [name] | Booth: [number] | Revision: [n, date]
Sponsor contact (can approve substitution on site): [name, phone]
Show-floor AV lead: [name, phone]
Booth coordinator: [name, phone]
1. DEMO INVENTORY
Demo name | Power | Network (wired/wireless, service, traffic) | Display/audio format | Operator | Status
2. DEPENDENCY OWNERSHIP
Item | Venue-provided | Sponsor-provided | AV-provider-provided | Confirmed by (name, date)
3. NETWORK
Service ordered: [name, bandwidth, drop location]
Addressing: [DHCP / fixed / public]
Failure behavior: [fails closed / degrades / pauses]
Test window: [date, time] | Pass/fail record owner: [name]
4. BOOTH DIAGRAM
Attached: [yes/no] | Power drop wattage marked: [yes/no]
Internet placement marked with "I": [yes/no]
Event name, booth number, measurements, orientation included: [yes/no]
Revision label and date: [yes/no]
5. TEST-AND-ACCEPTANCE SEQUENCE
Power/physical: [time, owner]
Network link: [time, owner, interval]
Display/audio: [time, owner, agreed format]
Operator rehearsal: [time, owner]
Fallback rehearsal: [time, owner]
6. FALLBACK TABLE
Failure | Immediate check | Agreed fallback | Decision owner | Phone
7. ATTENDEE DATA
Fields collected: [list] | Storage: [location] | Export owner: [name]
Retention: [period] | Consent reference: [document]
8. LIMITS
This rider documents intent and responsibility. It does not certify rigging,
electrical, accessibility, occupancy, or egress compliance.
Pre-load-in checklist for the booth coordinator
- Every demo has a row in the demo inventory, and every row has a status.
- Every dependency has a named owner in the venue, sponsor, or AV-provider column.
- The network section names the specific service, the drop location, and the test window — not a package name.
- The booth diagram shows the wired drop relative to the demo table, with power wattage and internet placement marked.
- The test-and-acceptance sequence has times and owners, and the pass/fail record has a named keeper.
- The fallback table has one decision owner and one phone number per row.
- The attendee-data line is filled in, or the integration is marked not ready.
- The limits paragraph is present, so nobody mistakes the rider for a compliance certificate.
If the room-to-chat handoff is part of the same event, the failure patterns overlap: a demo that depends on a live service and a hybrid session that depends on a chat bridge both fail at the boundary between two systems that were each tested separately. The analysis of why hybrid events fall apart at the room-to-chat handoff is a useful companion read for the boundary-testing discipline.
FAQ
Who should own the sponsored-booth rider?
The booth coordinator owns the document; the show-floor AV lead owns the test-and-acceptance record. The sponsor’s technical contact owns the demo build and the fallback decision for demo-specific failures. Name all three in the rider.
Can we just use the venue’s general Wi-Fi for a demo?
Sometimes, but the rider should not assume it. The Javits Center exhibitor guide recommends wired internet for business-critical tasks such as product demos to avoid signal interference. That is a venue-specific recommendation, not a universal rule, so confirm the specific service and test it during load-in.
What if the sponsor refuses to provide a booth diagram?
Record the refusal in the rider and mark the network and power rows as “to confirm.” The Javits guide states that submitting a diagram before arrival helps reduce labor costs and prevents installation delays, so the risk of proceeding without one belongs in the document, not in a hallway conversation.
Does a signed rider mean the booth is compliant?
No. A stage plan documents intent but does not certify rigging, electrical, accessibility, occupancy, or egress compliance, and the same limit applies here. The rider is a planning and handoff document; the venue’s work rules and the show’s safety plan govern compliance.
How specific should the network requirement be?
Specific enough to test. Record wired or wireless, the service, the drop location, the addressing method, the expected traffic pattern, and the failure behavior. The Eventbrite RFID access-control rider is a useful model for specificity — it requires one unrestricted hardline connection with DHCP per scanning location and sets a minimum speed per drop — even though it is an access-control document, not a booth-demo standard.