How a live-event teleprompter should work with a running order

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.

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.

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.

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.

The speaker needs to read one line. The operator needs to know what happens if the next line is wrong.

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.

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.

Founder, EventBlok. Live, hybrid and broadcast producer, showcaller and technical director, in production since 1996.

About EventBlok