Hybrid event rehearsal checklist: test both attendee experiences

A hybrid event rehearsal should prove that someone in the room and someone watching remotely can access everything their ticket promises, follow the programme and get help when something breaks. Run both journeys together using real attendee accounts, the actual production setup and clear pass or fail checks. Then deliberately break the parts most likely to fail and practise the response.

So you've tested the microphones, the speaker can share their slides and the stream is live. You're ready, right? Try asking the person watching at home to hear a question from the back of the room. Or ask your door team what happens when a remote ticket holder arrives at the venue. That's where a hybrid rehearsal earns its place.

You're selling two ways to attend one event. Each has its own weak spots, and the handoffs between them can make both worse. A room can applaud a brilliant answer while remote buyers hear silence. An online poll can work perfectly while people in the venue have no idea a vote is happening.

This checklist walks you through the ticket journey, the live session, audience participation, accessibility, failure drills and the final decision to open. Use it to find problems while fixing them is still cheaper than explaining them to paying attendees.

Start with what each ticket actually promises

The first thing you want to do is put your ticket page beside your rehearsal checklist. Every promise on that page needs a test. If remote buyers get live questions, test a remote question reaching the speaker. If they get a replay, test a recording becoming a playable replay. If venue buyers get access to the digital materials, test that too.

Avoid writing "same experience" unless you can explain what that means. A remote attendee won't get the venue atmosphere, and an attendee in the room shouldn't need to watch their phone to follow the stage. Your job is to deliver the experience each buyer chose, with fair access to the parts you promised both groups.

Create two test tickets with different email addresses. Label one venue and one remote. Add any paid upgrade that changes access. Keep tests separate from actual sales reporting, and follow your ticketing provider's supported testing process. You don't need to invent purchases or refund live orders just to make a rehearsal look real.

Assign a person to each attendee journey. They should follow the instructions a buyer receives without borrowing a producer's login or asking the technician where to click. Choose someone who didn't build the setup. People who know every workaround make terrible substitutes for a first time attendee.

Your test sheet needs five fields for each promise:

• The buyer action, such as opening the joining email.

• The expected result, such as reaching the correct session.

• The evidence, such as a screenshot taken from the attendee account.

• The person responsible for fixing a failure.

• The result after the fix is tested again.

Write observable results. "Remote joining feels easy" leaves everyone arguing. "The test buyer follows the joining email and reaches the holding screen without staff help" gives you something you can check. A promise passes when the attendee completes it under the conditions you agreed to support.

You might discover a ticket promise that your production setup can't deliver. Change the setup or correct the offer before selling more of it. Existing buyers need clear communication about any material change, handled according to your published terms and applicable requirements. Don't quietly turn a live workshop into a recording because the interactive part proved difficult.

If you're still choosing the programme, our hybrid event ideas can help. At rehearsal stage, though, your focus should narrow. You're proving the experience you've already sold, rather than adding another activity because somebody found an interesting tool.

Rehearse with the people and equipment that will run the event

A speaker check and a full rehearsal do different jobs. The speaker check catches a poor microphone, a confusing presentation or a missing cable. The full rehearsal tests whether the people operating the event can deliver it together. You need both when a speaker's setup or a session handoff adds risk.

Bring the actual host, show caller, remote moderator and technical operators into the full rehearsal. The show caller is the person who gives the instructions to start, switch, hold or stop. Your venue lead and support lead also need to practise the points where their work affects access or the programme.

For a smaller event, one person may hold more than one role. Test whether they can actually do those jobs at the same time. A host who is answering a remote access complaint can't also introduce the next speaker cleanly. The rehearsal should expose that conflict before you're relying on a superhuman version of your team.

Use the planned computers, microphones, cameras, lighting, presentation files and network connection. A successful rehearsal on somebody's home laptop tells you little about the venue machine with different permissions. Keep the same account roles too. An administrator's successful login doesn't prove a ticket buyer can enter.

Put your remote test attendee outside the venue network. Ask them to use an ordinary supported device and connection. They must report what reaches them, including captions, slides and holding messages. The preview monitor beside the production desk shows the production view. It doesn't prove the remote audience receives the same thing.

Ask suppliers which parts of the actual setup won't be available until event day. Record those gaps and name the test that will cover each one after installation. A provisional pass should never quietly become a final pass. If the final camera arrives later, the final camera still needs testing.

Keep a simple record of the configuration you tested. Include the programme version, presentation version, account permissions and connection used. You don't need a technical essay. You need enough detail to know whether a late change has invalidated a result. A new video file or relocated access point can change what previously worked. Keep the latest test results somewhere the event team can reach without asking you to forward another attachment.

The UK's Health and Safety Executive advises organisers to coordinate work, provide relevant information and check agreed controls. That guidance concerns event safety. The same practical habit helps your rehearsal: the right people need to know what they're responsible for, and someone needs to verify the agreed action happened.

Walk through purchase, confirmation and entry

Start before the welcome screen. Read the event listing on a phone. Can a buyer distinguish venue admission from remote access? Is the start time clear? Does the ticket description explain which sessions, questions, materials or recordings it includes? A perfect broadcast doesn't fix a buyer arriving with the wrong expectation.

Next, follow the confirmation process using your test accounts. Check the event name, ticket type, time, location and support details. Test every joining link in the message. If access instructions arrive in a separate email, the confirmation should tell buyers when to expect it. Otherwise support gets the entirely reasonable question, "Where's my link?"

For venue admission, scan the test ticket using the staff account and device you plan to use. Check what the door operator sees, and practise the supported manual lookup process for someone whose phone won't open their ticket. Repeat a scan to see how the system reports an already checked ticket.

Loopyah's ticketing and check-in tools give buyers confirmation emails linking to their QR tickets, and let door staff scan tickets with their own access. Rehearse that real workflow. You don't need to build a separate guest spreadsheet just to give the door team something to use.

For remote access, start with the message the buyer receives. Open it on a supported phone and computer, using the correct ticket permissions. Check any account creation, password reset, browser request or waiting screen. Close the session and return. An attendee who joins late or refreshes shouldn't have to guess which link remains valid.

Your streaming service handles the remote player and its access rules. Ticketing and attendee email can support the buyer journey, but they don't prove the broadcast is working. Test the connection between the systems explicitly, especially if your team has to grant remote access separately after a ticket sells.

Try an account without the required access. It should reach the intended denial or upgrade message, with a useful next step. Don't share administrator credentials to make the test pass. You're checking that valid buyers get in and that access restrictions behave the way you intended.

Now test a misunderstanding. Have your remote ticket tester ask whether they can enter the venue. Have your venue tester ask where to watch online. Support should have a consistent answer based on the ticket terms. If an upgrade is available, verify the approved purchase and access process rather than improvising a favour.

Check the programme from both sides of the screen

Run the opening as if people have paid to watch it. The venue doors open, the remote holding screen appears, the host welcomes both audiences and the first session starts. Stop using "we'll do the introduction on the day" as a shortcut. Introductions are where timing, camera, microphone and screen cues first collide.

Ask the venue tester to sit where an ordinary attendee would sit. Can they hear the host and see the useful detail? Ask the remote tester what they receive. They should see the intended picture and hear the intended sound, with neither a private crew conversation nor a silent speaker appearing without explanation.

Audio deserves separate attention. Test the stage microphone, remote speaker, audience microphone and any video playback. A technician hearing the room sound is different from a remote attendee hearing it through the player. Have the remote tester repeat a phrase from each source so you're checking comprehension, not merely whether a meter moves.

Try an actual audience question from the room. The microphone must reach the person asking, or the host must repeat their question into a live microphone. Test the reverse journey too. A remote speaker's answer needs to reach the venue clearly without creating feedback when it comes back through the broadcast setup.

Watch a slide with small text and a slide with a detailed diagram. Ask the remote tester to read the relevant label, then ask the venue tester. If either can't, change the presentation or how it's shown. "It's visible on the laptop" is a very low bar for a paid event.

Play the exact videos you'll use, including their sound. Check the start, the end and the return to the speaker. Confirm you have the necessary permission to use and record the material. A rehearsal that works technically doesn't grant broadcast or replay rights.

Test each change of format. Move from a venue speaker to a remote speaker, from slides to discussion, and from the programme to a break. Remote attendees need to know when to return and what they can do meanwhile. A camera pointed at an empty stage doesn't explain a break.

Don't stop at the smooth transition. Let the session overrun and practise the decision that follows. Who shortens the next introduction? Who updates the holding message? Which promised activity stays protected? Keep the decisions with the person authorised to change the programme, so the moderator doesn't quietly sacrifice remote questions to catch up.

Make audience participation work across both groups

Here's where a hybrid event can feel connected or awkward. The host asks for questions, hands shoot up in the room, and the remote chat fills with questions nobody sees. Your technology might be working exactly as configured. Your audience process is failing.

Rehearse the complete question journey. The remote tester submits a question, the moderator identifies it, the host receives it and the speaker answers it aloud. The remote tester then confirms they heard the answer. A question appearing in a dashboard is only the first step.

Give the host a clear cue for remote questions. That might be a private message, a dedicated screen or an agreed prompt from the moderator. Test it while the host is speaking and looking at the audience. A cue that works only when everybody stares at a laptop won't survive the live programme.

Decide how you'll balance questions before the rehearsal. You might alternate between venue and remote questions or collect both into one moderated queue. Pick the method that fits the session and explain it to attendees. There is no benefit in promising equal access if the host can only see one audience.

Test a question that's too long, off topic or abusive. The moderator needs the authority and tools to handle it without stopping the session. Keep private support requests out of the public question queue. Someone reporting a login problem shouldn't have to publish their email address to get assistance.

For polls, check how each audience joins and when the result appears. The venue attendee may use their phone while the remote attendee uses a browser panel. Explain both routes. If you display live results, confirm they don't obscure the speaker or make the presentation unreadable on a smaller screen.

Streaming delay can affect participation. Use your actual setup to observe when a host's instruction reaches the remote tester and when their response arrives. Then adjust the activity window. Don't publish a universal delay target borrowed from another event. The acceptable timing depends on whether you're collecting questions, running a quiz or taking a live vote.

For workshops or breakout sessions, test a move into the assigned group and the return. Check the instructions, the facilitator's view and what happens when someone disconnects halfway through. If the activity can't include remote attendees as promised, redesign it while you still have time.

Test accessibility as part of delivery

Accessibility belongs in the rehearsal because a feature can be switched on and still be unusable. Captions might cover the relevant part of a slide. A keyboard user might reach the player but get stuck before the question box. A speaker might keep saying "as you can see" without explaining the information.

W3C's accessible events checklist covers remote, venue and hybrid participation, including accessible materials and clear presentation practices. Use it to brief the people delivering your event. Your rehearsal then checks whether those choices work in the actual attendee journey.

Try the supported joining and participation routes using a keyboard. Check that the current control is visible and that the user can reach the player, captions, questions and support. Enlarge the page and verify that essential instructions and controls remain usable. Record where the tester gets stuck instead of declaring the whole platform accessible.

W3C's Easy Checks for web accessibility is useful for this first inspection. It also makes clear that quick checks aren't a comprehensive accessibility assessment. Use specialist evaluation and attendee feedback where needed, especially when your event depends on a complex player or interactive workshop.

Test the caption service with the actual speakers and vocabulary. Include names, technical terms and an audience question. Check whether captions appear for every audio source you intend attendees to hear, and whether a viewer can find the control. Give your captioner the programme and terminology they need before the event.

W3C explains in its caption guidance that captions convey speech and relevant non-speech audio. Your test should therefore check useful meaning, rather than whether words happen to be moving across the screen. If a necessary audio source has no usable captions, record the problem and test the remedy.

Ask presenters to describe the visual detail needed to understand their point. That matters for remote attendees who can't see a slide clearly and for people who use descriptions to access visual information. Rehearse the explanation with a real chart or demonstration so the speaker can practise saying what matters.

For the venue journey, walk the agreed accessible route with the venue lead and check the arrangements you've offered. Confirm how an attendee requests help privately. Keep your event's safety and access procedures with the people qualified to own them. A production rehearsal should check these handoffs without replacing the venue's safety process.

Break the setup and practise the response

A backup is only useful if the team can use it. Saying "we've got another laptop" leaves open whether it has the slides, permissions and right connections. During rehearsal, make the primary route unavailable and operate the backup. Record what both audiences experience while the team switches.

Choose realistic drills based on your setup. You don't need to create a disaster film. Start with the failures that would prevent access, remove essential content or leave paying attendees without an explanation. Agree the drills with your technical team so nobody creates a safety problem while trying to test one.

• A remote speaker drops out during their session.

• Venue audio disappears from the remote player.

• A presentation won't open on the show computer.

• A valid buyer can't access the remote session.

• Captions stop during a promised live session.

• The support lead becomes unavailable.

For each drill, check detection first. Who notices the failure? A remote audio problem can go unseen by everyone in the room, so your remote monitoring role matters. Make the tester report what happened through the same route they'll use on event day.

Then check the decision. Who can hold the programme, use the backup or change the running order? The technical operator needs permission to act within agreed limits, while the host needs one clear instruction. If everyone proposes a different fix in the crew chat, your rehearsal has found a command problem.

Practise the attendee message while the repair happens. "We're fixing a technical issue affecting the remote audio. Please stay on this page; we'll update you here" gives people a useful action. Give another update at the promised point even if you haven't solved the issue. Silence makes people refresh, leave or flood support.

Test whether your fallback can deliver the essential promise. A prerecorded talk may replace a presentation, but it doesn't replace a live question session unless you have another way to answer questions. Check speaker permission before using recordings. Don't call a reduced experience a full recovery just because the video starts playing again.

A technical interruption and a venue emergency need different responses. The HSE's event emergency guidance recommends defined responsibilities, pre-agreed announcements and testing communication systems. Keep emergency authority with the designated venue and safety team. Your hybrid rehearsal should confirm how production follows their instructions and informs remote attendees.

Check support, recordings and the end of the event

Support should be part of the rehearsal, not a contact address pasted into the final email. Have the remote tester ask for help without entering the session. They need a route they can find before login. Have the venue tester ask a door operator a ticket question while admission continues.

Time the response against the service you intend to provide, and test the escalation to someone who can fix access. Use safe test details. Never put a real attendee's payment information into a rehearsal chat or screenshot. The support lead should know which information they need and which information they should never request.

Rehearse an attendee update too. Confirm who writes it, who approves a programme change and who sends it. Loopyah's attendee email tools let you send a test to yourself and schedule messages. Use the test to check the joining instructions and support details before they reach buyers.

Keep the holding page or another independent update route ready for a live interruption. Email can carry instructions, but your team also needs to tell people already watching what is happening. Practise that message in the player and check that it reaches the remote test attendee.

If your ticket includes recordings, check the recording itself after rehearsal. Open the exported file, listen to the different speakers and inspect slides and captions. Confirm the agreed editing and publication process, permissions, access period and owner. A recording indicator during the show doesn't prove a useful replay exists afterward.

Run the closing announcement. Both audiences should know what happens next, where materials appear and how to raise an unresolved issue. Test the final links with attendee permissions. Then check that the public stream ends while any private crew conversation stays private. That last button deserves a rehearsal too.

Run a rehearsal that exposes the difficult moments

For a paid conference with a shared main stage, build your rehearsal around one representative session. Start with the buyer instructions, open both attendee routes, welcome the audiences, introduce a venue speaker and bring in a remote speaker. Use actual slides and a video. Then take questions through both routes and finish with the recording and closing checks.

You can compress the speeches, but don't compress the handoffs. A speaker can deliver a short passage instead of their entire talk. The team still needs to switch microphones, change the picture, display the presentation and give the next cue. Those are the moments you're trying to prove.

Tell your testers to include ordinary attendee behaviour. The remote attendee joins after the welcome, refreshes during a break and asks where the materials are. The venue attendee arrives with a ticket they can't display and asks a question without waiting for the microphone. Staff should practise helping them without losing control of the session.

Introduce a failure. Ask the technical team to interrupt the venue's primary production internet connection safely. Check whether the tested backup restores the broadcast and whether the support lead can update buyers through a separate route while the player is unavailable. Once delivery resumes, both testers confirm sound, slides and captions before the show caller restarts the session.

Now check what the exercise revealed. Perhaps the backup connection worked, but the host never told remote buyers what was happening. Perhaps the door operator solved the ticket problem by messaging the producer, pulling them away from the speaker recovery. Both are useful findings. Fix the handoff rather than telling people to pay more attention.

Leave room in the rehearsal booking for fixes and another attempt. A schedule filled entirely with first attempts leaves you with a list of unresolved issues when the supplier packs up. Agree which people must stay for retests, especially if their departure would make a critical fix impossible to verify. Finish with the evidence you need to authorise delivery, while everyone who owns an unresolved problem understands their next action.

Turn rehearsal failures into a clear decision to open

Finish with a short review while the people who saw the problems are still available. Collect reports from your venue and remote testers before the production team explains what it intended to deliver. Their reports describe the experience buyers actually received.

Separate failures that block delivery from improvements that can wait. No usable remote audio, valid buyers unable to enter, or an untested response to a critical interruption should block the affected promise. A slightly untidy holding graphic may be worth fixing, but it doesn't deserve the same attention as missing captions or broken access.

For every blocker, write the actual condition, the person responsible and the retest required. "Fix audio" is too loose. "Remote tester cannot hear audience questions; audio operator to correct the feed and repeat a room question through the attendee player" tells everyone what will count as fixed.

Retest the whole affected journey after a change. A corrected email link must work for the buyer receiving it. A replacement microphone must work in the room and in the stream. Close the issue after the tester confirms the result, rather than when the person making the change says they're finished.

Keep the final signoff small enough to read. List the ticket promises tested, unresolved limitations, tested backups and the person authorising the event to proceed. If somebody accepts a limitation, record the attendee consequence and communication required. Approval doesn't make a broken promise disappear.

On event day, repeat the checks most vulnerable to change. Open the buyer links, confirm staff access, listen through the remote player and check captions. Verify the latest slides and the opening cues. If a supplier has changed equipment since rehearsal, test the affected route again before admitting attendees.

Your hybrid event is ready when both attendee journeys work, the team can recover from the failures you've tested and the remaining limitations have an honest decision behind them. Keep the signed checklist beside the running order. When doors open and the remote holding screen goes live, everyone should know what to do next.