How a live-event teleprompter should work with a running order
A teleprompter at a live event is not a video autocue. It has to follow a speaker who goes off script, survive a running order that changes, and never show the operator something different from the crew. Here is what that requires.
The short answer
A live-event teleprompter should scroll at the speaker's pace rather than a fixed speed, let an operator take manual control instantly, and read its script from the same running order the crew are calling. If the prompter and the showflow can disagree about which item is live, the prompter will eventually be showing the wrong script to someone standing in front of an audience.
Why live is different from broadcast
Broadcast autocue solves a narrower problem: a presenter reading a written script at a known pace, usually rehearsed, usually to time. Live events break all three assumptions.
Speakers depart from the script and come back to it. They take a question mid-section. They skip a paragraph because the previous session already covered it. And the running order behind them is being edited while they speak. A fixed-speed scroll is unusable in that environment within about ninety seconds.
What it has to do
Four requirements separate a prompter that helps from one the operator ends up fighting.
Follow the voice, not the clock
The scroll position should track where the speaker actually is. Voice following handles the normal case; the important part is what happens when it loses them.
Hand over instantly
An operator must be able to take manual control in one action, without a mode change or a confirmation. The moment they need it, they need it now.
Show drift honestly
The operator should be able to see how far ahead or behind the script the speaker is running. A prompter that hides its own uncertainty is worse than one with no automation at all.
Read the live running order
When the order changes, the prompter should already know. A script loaded from a file before doors is a copy, and copies go stale.
The operator view matters as much as the speaker view
Most attention goes to what the speaker sees — large type, sensible line breaks, a clear active line. The operator view is what determines whether the prompter survives a difficult moment.
An operator needs the same script with position, pace and drift visible, plus the cue they are heading into. If they have to look at a second screen to know what is next, they are reconciling two documents under time pressure — which is exactly the failure this is meant to prevent.
How EventBlok approaches this
The EventBlok prompter follows the speaker's voice, with an operator mirror that shows position, pace and drift and allows manual control. The script reads the same running order as the showflow, so an item that moves moves for both — the prompter is a view of the event record rather than a file loaded before doors.
How that shared record propagates a change is covered in how a change reaches every screen.
Plan the event. Publish the programme. Run the show.
One event spine, many views. Build the programme once, then give every person the right live view of it.