Someone changes the narrator. Someone else spells the product name phonetically. The next editor restores the official spelling, and the old pronunciation comes back. Nobody made an unreasonable decision. The team just never wrote the decision down.
A voice style guide is a reusable document that explains how your organization should sound and how a finished recording gets approved. It isn't a collection of adjectives about being friendly. It connects choices to examples another person can follow without calling the original producer.
Write it once as a working reference, then revise it when your decisions change. The aim is fewer repeated conversations, not a rulebook nobody opens.
What should a practical voice style guide contain?
Start with the questions that appear at a handoff. Which voice belongs in this project? How should this name sound? Does the introduction have to match the previous episode? Who says the file is ready?
Give each answer a clear home in the document. Put the purpose and owner near the top, followed by voice assignments, pronunciation, pacing, recurring script conventions, delivery requirements and approvals. Keep the guide wherever your team already stores production references. It doesn't have to be a special system.
Include a small set of approved audio examples alongside the rules. “Calm but not sleepy” is open to interpretation. A reviewed training introduction makes that direction audible. Explain what the example demonstrates rather than asking colleagues to copy every accidental detail.
Also define where the guide doesn't apply. A character performance may need different rules from a product tutorial. Exceptions are easier to handle when the normal path is clear and the person who can approve a departure is named.
How do you choose a voice for each content type?
Assign voices by the listener's task, not by whichever demo sounds most impressive. A support explanation needs clarity and patience. A launch introduction may need more energy. A recurring series benefits from a recognizable narrator even when the subject changes.
Write an assignment table that your team can actually use:
| Content type | Delivery direction | Approval example |
|---|---|---|
| Product tutorial | Direct, measured, clear on action words | Reviewed setup explanation |
| Customer story | Warm, attentive, restrained emphasis | Approved story opening |
| Internal briefing | Conversational, concise, clear on names | Reviewed team update |
| Promotional introduction | Energetic without rushing the offer | Approved campaign introduction |
Add the actual chosen voice name and engine beside each row in your own document. Keep a fallback only if you've auditioned it. “Any similar voice” pushes an unresolved casting decision onto the next producer.
Use the voice library to audition representative passages, including awkward names and dense sentences. Our voice consistency guide offers a useful companion when you're turning a favorite read into a repeatable reference. A shared guide should preserve a decision, not pretend every voice handles every script the same way.
How should you document product and people names?
Create a pronunciation section with the written term, the intended spoken form, its context and the person who confirmed it. For a person's name, ask that person when possible. Don't treat a colleague's confident guess as the approved reference.
Separate official spelling from pronunciation guidance. The public script may need the proper brand name even when a spoken rendering needs help. Vois's pronunciation dictionary provides a place to apply those pronunciation decisions without turning the visible script into a page of improvised spellings.
Test entries inside real sentences. A name in isolation doesn't reveal how it sounds beside an abbreviation or a similar word. Include the target language in the record, and don't assume an English approximation is a suitable rule for every localized edition.
Store an approved audio example for difficult terms. If an entry changes, note which active projects need review. The guide should say who can alter these records and who checks the resulting narration. Otherwise a quick correction in one project can quietly become an unreviewed policy for the next.
How do you write pacing rules people can follow?
Describe what the listener needs to do during the recording. “Pause after an instruction so the viewer can locate the control” is more useful than “sound professional.” Tie the direction to comprehension, not an abstract personality trait.
Write separate guidance for explanations, lists and emotional passages. An explanation may need a clear break before the consequence. A list needs distinct items without making each one sound like the end of the recording. An emotional passage may need restraint rather than slower speech everywhere.
Use examples of script edits as well as finished audio. Show how a long sentence became shorter spoken thoughts. Note where Vois pause nodes belong and why, but leave room for a producer to listen and adjust the surrounding phrasing.
Avoid making a single speaking speed the whole policy. The same pace can feel comfortable in a familiar greeting and hurried in a sentence full of unfamiliar terminology. Ask reviewers to check whether the important words land, whether a listener can follow the instructions and whether the delivery suits the content type.
What intro and outro conventions should a team share?
Specify the job of each recurring passage. An introduction might identify the series and tell the listener what they'll be able to do. An outro might name the next action and make the ending unmistakable. Those jobs are more durable than a fashionable catchphrase.
Keep approved wording for elements that must remain exact, such as a show name. Mark the parts that should change, such as the topic or destination. This prevents a copied introduction from promising the wrong lesson or naming an outdated resource.
Include sound conventions where relevant. If a music cue announces the start of a series, say when it appears relative to the voice. If training instructions should run without a bed, record that choice too. Don't make the editor infer it from an old export.
Allow content to begin directly when a repeated introduction would get in the way. A short support answer doesn't necessarily need the full ceremony of a show opening. Consistency means making similar decisions for similar situations, not forcing every recording into the same mold.
How should you name and deliver voiceover files?
Choose a naming pattern that identifies the project, section, language and revision without opening the file. A name such as setup-guide_account-access_en_review-b.wav is an example, not a required Vois format. Define what your own language labels and revision markers mean.
Separate working exports from approved deliverables. A filename containing “final” doesn't prove anyone approved it, especially when a newer “final” arrives later. Keep the status in your release record and make sure it points to an exact file.
Document the requested format and destination preset, then check them before delivery. Include whether the recipient needs a voice-only track or an arranged mix. Retain the source project so a correction doesn't start with someone trying to edit a compressed delivery file.
For recurring voiceover work, this section often prevents the least glamorous mistakes: sending the wrong language, replacing an approved version or delivering music when an editor expected isolated narration. Clear names won't replace listening, but they make the right file easier to find.
Who approves a release and keeps the guide current?
Name a release owner. Other reviewers can check subject accuracy, pronunciation and language, but someone needs responsibility for the final decision. “The team approved it” is difficult to act on when the comments disagree.
Ask reviewers for specific findings with a section reference and a proposed correction where possible. “Something feels off” can start a discussion, but it isn't enough to close a production task. Separate factual corrections from optional stylistic preferences.
Before release, the owner should listen to the exported file, confirm that required corrections are present and record which version was approved. A script approval alone doesn't catch a mispronounced name or a clipped ending.
Then feed useful decisions back into the guide. Don't rewrite it after every project. Update it when the team chooses a new narrator, changes a name pronunciation or discovers a delivery requirement worth preserving. Test its usefulness by handing the next project to someone who didn't write it.
Give your next teammate a decision they can reuse.
The Vois Team