Build a Scene-by-Scene Cast Breakdown From a TV Pilot

Ask five people how many characters are in a pilot and you'll get five answers, because the question is hiding at least three of them: how many people speak, how many people the camera needs, and how many people the story is about. A cast breakdown answers the second one. It's a grid — one row per person the pilot asks for, one column per scene, and a mark wherever the script puts them in that scene.

Build the grid from the scenes. Use your screenwriting software's reports to get a fast first pass, then spend your attention where a report and a script tend to disagree, which is in three places: the person who is in the room and says nothing, the voice that is heard from somewhere else, and the name that turns out to belong to two people, or to one person twice.

Put the columns up before you extract anything

The grid needs four things per entry: who, which scene, whether they are physically there, and whether their voice is in the scene without them. Keep presence and voice in separate columns. A character heard over a phone or on a recording is a role in the pilot and a blank in the presence column, and if you collapse the two you will spend the rest of the pitch talking about a person you never actually put in a room.

Two more fields, boring and load-bearing. The first is the draft: a date, a version label, whatever your file is called. A breakdown with no draft attached is a breakdown of nothing in particular, and the moment the script is revised it becomes a claim about a script that no longer exists. The second is a locator for every entry. Scene number plus the opening words of the heading works well, and it survives renumbering better than a page number does.

A cast list, a character report and a location report don't answer the same question. Final Draft's documentation for its report set describes several report types with different contents — scene reports, character reports, cast reports, tag reports — and the differences matter more than the names suggest. A list built from who speaks is a list built from dialogue, and dialogue is only one of the ways a person gets into a scene.

Here is where it's worth reading the documentation slowly. Final Draft tracks speaking characters, and its cast-list feature includes an operation for inserting a non-speaking character into a scene's cast list. It also associates the Cast List element itself with three-camera formatting. What that means for you: the documented route to a non-speaking entry sits inside a feature that the documentation describes in a three-camera context. It is not a reason to reformat your single-camera pilot so a report will behave. Format the script the way the script should be formatted and carry the silent appearance yourself, as a manual row with a locator, if your format's tooling won't hold it.

(Those documentation pages were read in September 2026. If your version differs, your version wins.)

Now walk the scenes

Everything below uses an invented fragment, three scenes of a pilot called Night Desk. It's here to make the checking concrete, not because I generated reports from it — the extraction shown is a hand reading of the character cues, which is what you can do today, in any tool, on any draft. Run your own extraction when you get to your own script.

The fixed facts of the fragment:

• Three names appear in character cues: MIRA, RENATA, and — above one block of dialogue in scene 3 — HOTEL WORKER.
• Scene 1. Mira speaks on the phone. A porter crosses the lobby with a cart and stays in the room until the scene ends. He says nothing. The action calls him the porter.
• Scene 2. Mira is alone. She speaks, then plays a recording. Renata is the voice on that recording. Renata is not in the building.
• Scene 3. Mira speaks. So does the porter from scene 1 — the action in scene 3 identifies him — but the cue above his dialogue reads HOTEL WORKER.

Start with the lazy pass, the one that takes thirty seconds and produces a number you'll be tempted to keep. Underline every character cue that has dialogue beneath it. You get three names: MIRA, RENATA, HOTEL WORKER. A dialogue-derived report is doing something like this, though exactly which elements it reads depends on your script's formatting and the report you chose. Either way, the list is wrong in three ways at once: it carries no row for the porter's silent crossing in scene 1, it files his scene-3 dialogue under a name that belongs to nobody, and it seats Renata in a room she never enters.

The person in the room who says nothing

The porter is in scene 1. He has a cart, a path across the lobby and a reason to stay in it. None of that is dialogue, so none of it is in the list. A speech-based extraction cannot find a person who never speaks; that isn't a bug you can argue your way out of, it's the shape of the input.

So add him by hand: row PORTER, scene 1, presence yes, voice no, note "crosses with cart, remains, no dialogue." If your script's format and tooling support an explicit non-speaking entry, use it. If not, the manual row with a scene locator is the honest record, and it's the one you can defend in a meeting.

A silent role is still a role. The script is asking for a body in a room, on a path, holding something. Who fills it and how is somebody else's document.

The voice that isn't in the room

Scene 2 has Renata's dialogue in it, so a dialogue-first pass puts her in scene 2 as though she were standing there. She isn't. The action says the voice comes out of a recording and that she is somewhere else entirely. Move her to the voice-only column for scene 2 and leave the presence column empty.

One caution while you're reading parentheticals. O.S. and V.O. are not used identically from script to script, and plenty of writers reach for one where a different writer reaches for the other. Read the abbreviation, then read the action paragraph above it. The action is the part that says whether a person is behind a door or on a hard drive, and it's the part no character report is reading for you.

Two labels, one person

Scene 3 gives the porter dialogue under a name that belongs to nobody. Before you merge anything, decide which of three things you're looking at:

• An alias — the same person, deliberately labeled differently because the story is hiding the connection.
• A mistaken element — the same person, labeled wrongly by accident, in a draft that hasn't been cleaned up.
• Another person — two distinct roles that happen to overlap in one scene.

The script has to settle it, not the report. Here, the action in scene 3 identifies the man as the porter from the first scene, so the cue is an accidental label, not a disguise and not a second hire. Note that both possible errors are real and they run in opposite directions: merge a deliberately separate character into another row and you erase a part; leave an accidental name standing and your cast count grows by a phantom.

Fix the cue, not the export

The temptation is to open the report, retype HOTEL WORKER as PORTER, and call it done. Don't. A report is an extraction; it isn't a live editor for the screenplay, and a change made in the report does not travel back into the script that generated it. Hand-edit the export and you have a tidy document and an unchanged source — and the next time anyone regenerates the list, the error is back, along with a fresh reason to distrust your numbers.

So correct the source. Keep the draft you were given untouched, make the cue fix in a working copy, and write down what you changed and why. Renaming a cue in a working copy is a script edit; treat it like one.

Then regenerate and look at the same three scenes again. The regenerated list should now show PORTER speaking in scene 3. That's confirmation that your edit propagated — it is not confirmation that the list is complete, because the scene 1 presence never lived in a cue and no amount of regenerating will find it. You will re-add that row by hand every time, which is fine as long as you know it.

The reconciled grid

Condensed to people and scenes, it looks like this. Each cell stands for the two fields you kept apart a level down — presence and voice — while the draft label, the per-entry locator and the notes column stay with the entry-level rows rather than in the table.

Nine cells: five physical presences, one voice-only entry, three blanks. Three people, two of whom are ever in the room.

Look at what the lazy pass did. It produced three names, and three is also the right head count — for entirely wrong reasons. Its three placements are each wrong in a different way: no row for the porter's silent first appearance, his second filed under a label that isn't his, and Renata in a room she never enters. This is the argument for building the grid from the scenes rather than from a total: a count can survive a list whose placements and labels are wrong, and the count is the part everyone remembers from the meeting.

What the grid is worth in the pitch

The grid lets you describe the pilot accurately: two people carry all three scenes, the third is a voice on a recording, one of the two is silent in his first appearance and speaks in his second. That's a real statement about the pilot's demands, and it's one you can point to a scene for.

It does not let you say what any of it costs. Presence isn't shoot days, a silent role isn't a cheaper role, and a voice-only part is still a part to cast. It doesn't rank anyone's importance either — a character with no lines in the first scene can be the one the whole pilot turns on, and nothing in a cue count can see the difference. And it says nothing about episodes that don't exist yet, because the pilot is the only script you have.

Keep the version, the locators and the open question

Two things travel with the grid: the draft it describes, and a short notes column for anything you couldn't settle. If a character's entrance is genuinely ambiguous in the action, write "entrance unconfirmed" and cite the scene. If an identity is still unresolved — a label nobody can account for, a voice whose speaker the pilot never names — leave it visible in the notes rather than choosing a tidy answer.

A breakdown that still has a question in it is more useful than one that has quietly guessed. The guess will end up in the pitch deck, and then it will end up in a conversation with someone who has read the script.

Frequently asked questions

What question does a scene-by-scene cast breakdown actually answer?

It answers how many people the camera needs, not how many people speak and not how many the story is about. The grid has one row per person the pilot asks for, one column per scene, and marks presence and voice separately wherever the script puts them in that scene.

Why keep presence and voice in separate columns?

A character heard over a phone or recording is a role in the pilot but a blank in the presence column. If the two are collapsed, the breakdown seats someone in a room they never enter and the pitch ends up talking about a person who was never put there.

Why not fix a mistaken cue directly in the exported report?

A report is an extraction, not a live editor for the screenplay; changes made in it do not travel back into the script. Hand-editing the export leaves the source unchanged, and regenerating brings the error back. Correct the cue in a working copy, keep the original draft untouched, and note what changed and why.

What can the reconciled grid not tell you when you pitch?

It cannot say what any of it costs. Presence is not shoot days, a silent role is not cheaper, and a voice-only part is still a part to cast. It does not rank importance, because a character with no lines in the first scene can be the one the pilot turns on, and it says nothing about episodes that do not exist yet.

How should an unresolved identity or ambiguous entrance be handled?

Leave it visible in a notes column with a scene citation rather than choosing a tidy guess. If an entrance is genuinely ambiguous, write 'entrance unconfirmed'; if a label or a voice's speaker is unresolved, keep it open. A breakdown with a question in it is more useful than one that has quietly guessed, because the guess will reach the pitch deck and then someone who has read the script.

Further reading

• Estimate a Pilot’s Running Time from Scenes, Not Page Count — Use when the grid invites a runtime estimate: it builds a dated timing model from spoken passages, actions, holds and transitions rather than page count.
• Build a Searchable Script Concordance for a Series Bible — Use this when a label or an unnamed voice needs checking beyond one scene; it keeps a manifest, searches literally, and confirms each hit before writing anything down.