FAQ / Handling client revisions on a voiceover
What is the best way to handle client revisions on a voiceover?
Number the paragraphs in your delivery, make revisions a line-numbered list against that delivery, scope them in your contract, and use a paragraph-based recording workflow so per-line revisions are cheap to do.
Deliver with line numbers
Send the merged audio plus a numbered list of paragraphs. "Paragraph 14: ..." not "the part about the launch". Numbered paragraphs are a revision contract: when the client says "change line 14", you both know exactly what audio is changing. With unstructured drafts, you spend half a revision cycle on "wait, which sentence?"
Set a revision budget in the contract
"Two rounds of per-line revisions included; additional revisions billed at $X per line" is a perfectly reasonable clause. Without it, "just a small tweak" becomes a third record session.
Receive revisions as a marked-up script
Ask the client to send revisions as the original script with changes tracked or highlighted, not as a long email describing changes. A marked-up script is unambiguous; an email always has at least one "you know what I mean" that does not survive translation to audio.
If the client is not comfortable with a tracked-changes doc, send them the SRT or VTT caption file from your first export. They can edit cue text directly. That gives you a line-numbered, time-coded revision document for free.
Apply revisions one row at a time
Open the original VoiceOverAndOver project. For each numbered revision:
- Edit the text on that row.
- Re-record that row.
- Save.
Then re-merge and re-export. The unchanged paragraphs are still the exact audio you delivered the first time.
Send a clean diff of what changed
Along with the revised merged file, send a one-line note for every paragraph you touched: "Updated paragraph 14 ('We are excited to announce...' -> 'Today we launch...')". The client signs off faster when they know exactly what changed and what did not.
Archive every delivery
Keep the project at every delivery checkpoint. v1 delivered, v2 delivered, final delivered. If a later request asks for "the line we had in v1, but with the wording from v2", you can rebuild it without guessing.