How Voice-Following Teleprompters Behave When You Go Off Script: A Measured Test

“Follows your voice” is the easiest claim in the teleprompter category to make and the hardest to check, because the interesting cases are the ones you cannot see in a demo: what happens when you stop, when you improvise, when you repeat a sentence, when you skip a line, when the transcript is wrong. This post measures those cases. The numbers come from a deterministic harness that feeds words into Sayscroll's script-matching engine under eight scenarios, so every figure below can be regenerated exactly. The protocol itself needs no code, and the last section shows how to run it by voice on any prompter.

What a voice-following prompter actually has to solve

Speech recognition produces a stream of words. The prompter has to decide, for each one, where in the script it belongs, and it has to get four situations right at once:

• Noise. The transcript will drop words, mishear words, and insert fillers. The position must not stall on every error.
• Pauses and ad-libs. Unscripted speech must not move the position, and returning to the script must pick it up quickly.
• Re-reads. Saying a sentence again must move the position back, not forward.
• Skips. Dropping a line must be recognised, but a common word that also appears three paragraphs later must not drag the script there.

The categories of prompter that advertise voice control solve these differently. A voice-activity approach scrolls whenever it hears speech, which handles pauses and nothing else: an ad-lib scrolls the script just as fast as a read. A keyword-anchored approach jumps to the next occurrence of a recognised word, which handles skips and creates false jumps on every common word. A word-level matcher with a global search handles re-reads but can be flung across a long script by an echoed phrase. Sayscroll's matcher is word-level with a deliberately local search window, and the results below are what that design does.

Method

The script is a 350-word English passage in 28 short lines, the kind of formatting the script-writing guide recommends. The harness feeds it to the matcher one word at a time, exactly as live transcription would, and after every scripted word asks one question: is the word the prompter highlights the word that was just spoken? That single check, “active word equals spoken word”, is the tracking score. Scenarios are built by changing what is fed: dropping or corrupting words, inserting unscripted speech, repeating a stretch, or jumping ahead. No audio, timing, or network is involved, so the test isolates the matching logic from the speech engine; that limitation is discussed at the end.

1. Straight read and noisy transcripts

First the baseline, then the same read with a fixed share of words dropped or misheard (one letter changed) and a filler word inserted every twenty-five words.

A transcript that loses or garbles one word in five is far worse than real recognition delivers in a quiet room, and tracking still stayed on the spoken word 99.6% of the time. The mechanism is tolerance in the right places: short words must match exactly, longer words tolerate a letter or two, and a small lookahead lets the matcher step over a dropped word instead of waiting for it.

2. Pauses and ad-libs

A pause produces no words, so it produces no movement: the position simply holds. An ad-lib is the harder case, because the words are real and some of them (“the”, “to”, “we”) exist in the script. After forty scripted words, the harness inserted an unscripted aside of increasing length, then resumed reading.

The position never moved during an aside of any length, and reading resumed with a re-lock on the second scripted word. The 99.7% in the last column is that one word: the first scripted word after an ad-lib is spoken before the lock lands. In practice this is why you can take a question from the audience, tell a story, or lose your train of thought entirely, and the prompter is where you left it when you come back.

3. Re-reading a sentence

The most common real-world event is a flub: the speaker stops and says the sentence again. After fifty scripted words, the harness re-read the last N words, then continued.

Re-reads of up to fifteen words lock back within two words and the prompter never jumped ahead. A twenty-word re-read starts outside the backward search window, so the lock lands only once the speaker draws back within range, five words in. This is the behaviour you want for a retake done in place: say the line again and keep going; the talking-head workflow is built on it.

4. Skipping ahead

Skips are where local search shows its trade-off. After forty words the harness jumped S words forward and kept reading.

A dropped phrase or a dropped line, up to about a dozen words, re-locks within two words. From fifteen words on, the prompter holds and waits, and the reader scrolls to the new section by hand; the prompter then continues from the line they scroll to. That cut-off is a design choice, not a limitation of the search: the next table shows why a wider window would be worse.

5. Decoys: why the window is narrow

While the matcher was off script after an ad-lib, the harness said things designed to fool it.

Common words never move the position on their own: a re-lock needs at least two matching words with enough letters between them. A distinctive phrase moves the position only when it sits within roughly fifteen words of where the speaker was. Long scripts contain many coincidental echoes of short phrases, and a prompter that follows them across the document ruins recordings; a prompter that ignores them asks you to scroll for a long jump. Sayscroll takes the second trade.

6. Digits, symbols, and a language switch

Two smaller checks with practical consequences. First, the same spoken sentence against a script written with digits and against one written as words:

Recognition transcribes what it hears, so “twenty twenty six” cannot match “2026”. The matcher stepped over the digits and recovered on “of viewers”, but the sentence-final “8%” had nothing after it to recover on and was never highlighted. Write numbers the way you say them; the same applies to acronyms and unusual names.

Second, a Spanish sentence inside an English script: “Welcome back to the channel and thanks for watching. Como decía mi abuela, lo barato sale caro, y por eso hoy probamos tres micrófonos. So let us find out whether the cheapest one actually holds up.” Fed word by word, tracking was 100% with no off-script moment at either switch. Matching works on normalised words with accents stripped, so the language of a word is irrelevant to the matcher; whether the speech engine transcribes both languages correctly is the real question, and Sayscroll's does across 60+ languages, with the site's language hinted first on each localised site (see the Spanish teleprompter page for the hint's effect).

What this means in practice

• Pauses are free. Stop for as long as you like; after thirty seconds of silence the prompter pauses fully and resumes on a tap.
• Ad-libs are free. Any length, and reading resumes on the second word.
• Flubs are free. Re-read the sentence in place; the prompter follows you back within two words.
• Small skips are free, up to about a dozen words. For a longer jump, scroll to the line you want and the prompter continues from there.
• Write what you say. Numbers, acronyms, and names in their spoken form.
• Mixed languages are fine for the matcher; give the speech engine the right hint by using the localised site for the language you mostly speak.

Limitations

The harness tests the matcher, not the microphone. Real recognition quality depends on accent, noise, and distance from the mic, and the noisy-transcript scenario is a proxy for that, not a measurement of it. Latency is not measured here; the live engine streams audio in small slices and the scroll is damped so the text glides rather than jumps, but that is a separate property. The script is 350 words in one language pair, and the scenarios are synthetic and deterministic. None of this replaces reading a real script on camera, which is why the protocol below exists.

Run the protocol on any prompter

1. Straight read. Paste a 300-plus-word script in short lines and read it at a natural pace. Does the highlight stay on the word you are saying?
2. Pause. Stop mid-sentence for five seconds. Does the text wait?
3. Ad-lib. Talk off script for twenty seconds, then return. Does the position hold, and how many words does the re-lock take?
4. Re-read. Say a sentence twice. Does the prompter follow you back or run ahead?
5. Skip. Drop a line. Does it catch up, and how far can you skip before it stops trying?
6. Decoy. While off script, say a few common words and then a phrase from a distant paragraph. Does anything jump?
7. Digits. Include a year and a percentage written as digits. Note where tracking stalls.
8. Second language. Include one sentence in another language you speak. Does tracking survive the switch?

Ten minutes on those eight steps separates “offers voice control” from “follows your voice”. The category-level comparison is in the best teleprompter apps; the design behind the local search window is explained on the voice-controlled teleprompter page; and the free demo lets you run every step above on a short script with no account.