Run an Audience Poll During a Small TV-Format Trial

A rehearsal poll is four operations sharing one interface. People enter. They answer. They stop answering. Somebody sees a result. The tool may present all of that as a single "launch," which is how rehearsals fail in a specific, boring way: you hide the results so the room can't influence itself, somebody asks whether voting is still open, and the honest answer is that nobody checked.

Hiding a chart is a display decision. Closing a poll is a collection decision. Doing the first tells you nothing about the second.

So give them separate checks and separate lines in the record: the joining route, the answer behavior, the cutoff, the result. That's the whole method. What follows applies it to a small format trial with four people in a room and one question about which prop a host should open next. Slido is the bounded tool example, because its provider guide for live polls describes results visibility, accepting votes and reset as distinct controls. How your own tool groups them is something you check rather than assume.

Freeze the rehearsal question and answer behavior

Before anyone opens a settings panel, write down what the poll actually is. Not the gist — the strings and the settings:

• The question, word for word.
• Every option, in the order participants will see them.
• Single selection or multiple.
• Who is meant to answer: the four people in the rehearsal room, by seat position, not "the audience."
• The cutoff — the time voting stops.
• A question version. Q1 now. Q2 if anyone rewords it later.

The version number isn't paperwork. If the wording shifts midway through a rehearsal, the answers are answers to different questions, and pooling them produces a number nobody can defend.

The running example: Q1, "Which prop should the host open next?", single selection, three options — the padlocked toolbox, the taped cardboard crate, the draped trolley — four named participants, cutoff 14:20, the moment the segment's run-through starts.

Single selection keeps the arithmetic honest. Four participants means at most four responses, and each response is one person's choice. If you allow multiple selections — "pick up to two" — then six selections across four people is unremarkable and says nothing about six of anybody. Decide that before you see the chart, because afterward you will be tempted to read selections as people.

One thing the configuration does not do is decide what the votes are for. If the format hasn't settled whether the host must open the winning prop or may overrule it, that belongs to the format, not the tool. A poll that works perfectly still doesn't tell you what an answer changes on air.

Enter through the participant route before the rehearsal

Configure the poll, then leave the operator screen. On a phone or tablet — a device of the kind participants actually hold — join the way they will, using the code, link or QR image you plan to show. Check it at roughly the size and distance they'll see it.

Then look at what the participant sees rather than what the operator sees. Is the question legible without zooming? Are the three options distinguishable at a glance, or does one read as a caption for another? Is it obvious that an answer has registered? What happens if you tap twice?

The operator dashboard is a control surface. It has no obligation to resemble the participant experience, and it usually doesn't. A preview inside the operator's tool is a useful first look, not proof that the route on a participant's phone behaves the same way. If the setup offers more than one way in, testing one proves nothing about the others.

Note what you used: the tool, the account, the plan it sits on, the device, the route. Plan differences are real, and "it worked in the demo" is a sentence about a different setup.

In the example, the operator joins on a phone before the room arrives and submits one deliberate test response — the toolbox — to confirm that collection starts and that the operator count moves while participants can see nothing. Then it gets cleared, and the clearance is written down. That test response is why the record lists intended inputs: without it, a later count of five against four participants is a mystery instead of a lookup.

Exercise display and collection independently

This is the distinction the whole rehearsal exists to prove.

Hide the results. Then submit a response from the participant side and watch the operator count. If the count moves, hiding the chart did not close the collection. That is the normal, intended behavior of a live poll, and it is the exact confusion that ruins a cutoff: someone hides the results early to keep the room neutral, and the poll quietly stays open through the reveal, the discussion, and the argument about the toolbox.

Now the cutoff. At 14:20, lock voting. Then stay on the participant device and try to make trouble: answer for the first time, and try to change an answer you already gave. Re-enter the poll after closure, the way a latecomer would, and look at what that person actually gets — a closed notice, a stale question, a blank screen, or nothing at all.

For the example, P4 is the designated troublemaker: intended to answer the toolbox before the cutoff, then attempt to change to the trolley at 14:21, one minute after the lock.

Whatever you observe is specific to the checked setup — this tool, this route, this device, this account, this question. It is not evidence about who voted, and it is not a security boundary. A poll that refuses a changed answer from a polite rehearsal participant has demonstrated that a button did something; it has not established that votes are attributable to distinct humans, and it certainly hasn't established anything about a live prize.

The provider's guide describes a lock control and a participant-view test route, which is why those are worth testing. The guide is documentation of the provider's controls, not a native run. Whether a locked poll refuses a changed answer, what a returning participant sees, whether results export, and which of these controls your plan includes were not established by reading it — that's what the rehearsal is for.

Capture the closed result before clearing anything

A result that gets cleared before anyone wrote it down cannot be reconstructed from a later chart. Not approximately, not by memory.

Capture the record while the poll is still closed and still populated:

The actual count and the distribution are blank on purpose, and so is the outcome of P4's attempt. This rehearsal hasn't been run. The point of writing those fields before you know the answers is that the log has to be able to say either thing.

And it matters, because the two outcomes look like this. If the lock refuses the change, and all four intended inputs arrive, the closed chart reads toolbox 2, crate 2, trolley 0. If the lock accepts it, the chart reads toolbox 1, crate 2, trolley 1. Same total either way: four responses, four participants. The finished chart cannot tell you which happened. The record can — but only if somebody wrote down the intended change before making it, and the actual outcome immediately after.

Then decide what "reset" means for what comes next. A continued rehearsal is the same run with the same question and the same people; a fresh rehearsal is a new run with its own identifier, even if the question is identical. Clear the responses only after you've decided which one you're starting, and say so in the record. If run R2 turns out to need the same question, it still gets its own line, its own cutoff, and its own count.

Declare what happens when the digital route fails

Someone's phone will not load the page. Decide in advance what happens, and make it serve the same bounded question rather than a vaguely related one. A raised hand for "which prop should the host open next" is a legitimate fallback. A shouted discussion about which prop is more interesting is not, because it answers a different question.

Then record whether the fallback replaced the digital run or started a separate collection. This is where counts get silently poisoned. Suppose the route works for three of your four participants and the fourth can't join, so you take a show of hands at the same cutoff. You now have three digital responses and a room of four hands covering the same four people. Three plus four is seven responses from four people, and at least one of them answered twice. Either take the show of hands from the participant who couldn't join, and report three digital plus one hand, or take hands from everyone and treat the digital slips as a cross-check — but pick one, write down which, and never add the two columns.

If the fallback replaces the digital run, the digital responses stop being part of the result. Say that in the record, not in your head.

What the rehearsal result can and cannot say

The result can say: this question, this version, this joining route, at this cutoff, with these declared inputs, produced these responses, with these interventions and failures attached.

It cannot say how an audience would answer, because four people in a rehearsal room are four people in a rehearsal room. It cannot say how many unique humans voted, because a response count isn't an identity check. It cannot support a prize decision, because a lock you tested once on one route under one account isn't a security boundary. Those limits aren't hedging. They're the difference between a documented rehearsal and a number that collapses the first time somebody asks how it was collected.

So the sentence that goes into the pitch note is unglamorous and complete: "Q1, single selection, four named participants, voting open 14:05–14:20, results hidden throughout collection, one change attempt after the lock, recorded as [refused / accepted], four responses at close, retained before reset." Plus the tool, account and plan, the device and joining route that were actually checked, and the fallback that was or wasn't used.

The chart is the loudest artifact and the least informative one. Keep it, and keep everything that made it mean something: who could get in, when collection stopped, and what happened at the boundary. Without those lines, a clean final chart is just a picture.

Frequently asked questions

What is the difference between hiding results and closing a poll?

Hiding results is a display decision; closing a poll is a collection decision. A live poll can hide the chart and still accept responses. Test it by hiding results, submitting a response from the participant side, and watching whether the operator count moves. If it moves, hiding did not close collection.

What should be fixed before the rehearsal starts?

Write down the question word for word, every option in displayed order, single or multiple selection, who is meant to answer by seat position rather than as the audience, the cutoff time, and a question version. If wording shifts later, answers to different questions cannot be pooled defensibly.

How should the cutoff be tested?

At the cutoff, lock voting. Then stay on the participant device and try to answer for the first time, change an existing answer, and re-enter the poll as a latecomer would. Observe what each attempt gets — a closed notice, a stale question, a blank screen, or nothing. Whatever you observe is specific to the checked tool, route, device, account, and question.

Why capture the result before clearing anything?

A cleared result cannot be reconstructed from a later chart. Capture the closed and populated record, including intended inputs, interventions, failures, responses at lock, post-lock attempts, and reset. In the example, whether a lock refused or accepted a change produced different distributions but the same total, so the finished chart alone could not tell which happened; the record can.

How should a fallback be handled if someone cannot join digitally?

Decide in advance and make the fallback serve the same bounded question. A raised hand for the same question is legitimate; a shouted discussion of a different question is not. Record whether the fallback replaced the digital run or started a separate collection. Never add digital responses and a show of hands covering the same people — that can count one person twice.

Further reading

• What Did Your Unscripted Format Test Actually Prove? — Use this when you have a result and need to say only what the record supports: it separates comprehension, unaided operation, repeatability and appeal across different artifacts.