How to Write a Voice Guide a Model Can Follow

Sentence length is the single most actionable lever in a voice guide, because it is countable. Do not write "keep sentences short." Write a range, a share of the text that must fall inside it, and a hard ceiling.

Start from real published copy. Pull 10 to 15 paragraphs your team considers on-voice and count words per sentence by hand or with a script. You are looking for a distribution, not an average: most brand voices mix short punchy sentences, medium explanatory ones and the occasional long sentence that carries a qualification or a list. A guide that targets 12 to 18 words everywhere will flatten that rhythm.

Here is a workable structure for the sentence length block:

SENTENCE LENGTH
- Target range: 8 to 20 words for 80 percent of sentences.
- Short sentences (1 to 7 words): use for emphasis, at most one per paragraph.
- Long sentences (21 to 35 words): at most one per 100 words, never two in a row.
- Hard ceiling: 40 words. Split anything longer.
- No sentence starts with "There is" or "It is" unless the next clause names the actor.
- Average across a 300-word section: 14 to 17 words.

What each band looks like in practice, using a support-context example:

Two details make this block reliable. First, state how the model should handle lists and bullets, since bullet fragments often fall outside any word range and a model will either over-correct or ignore the rule. Second, give the model permission to break the range once per paragraph; a hard rule with no escape hatch produces choppy, robotic copy, which Vapi's voice prompting guide warns about from the spoken side: models trained on text are verbose by default, and a prompt that only says "be concise" does not fix it.

For marketing pages where a single bloated paragraph costs conversions, set the average lower and the ceiling tighter. For documentation or legal-adjacent copy, raise the ceiling and add a rule that subordinate clauses go last. The numbers change by content type; the structure does not.

A banned list without replacements fails, because the model still needs a word and tends to reach for a synonym from the same family. Always pair each entry with the reason and the substitute.

How to AI's analysis of overused AI vocabulary catalogs the words that most reliably signal machine-written text, including delve, realm, tapestry, harness, unlock, leverage, seamless, robust, elevate and game-changer. Grammarly's humanizer page frames the same problem from the editing side: the goal is text that reads naturally while staying true to the original message, which is what a banned list plus replacements produces when it is specific.

Build the list in three tiers:

1. Never use, no exceptions. Words with no place in your voice at all.
2. Use only with a named object. Verbs that are fine when concrete ("leverage" is banned, "use" is fine; "unlock" is banned, "open" is fine).
3. Banned constructions. Patterns rather than words, such as "It's not X, it's Y," triple-item lists in every paragraph, or opening sentences with "In today's."

Two compliance constraints belong in this block when the content is promotional. The FTC's Disclosures 101 for social media influencers requires disclosures to be hard to miss, in simple language, and not buried in a group of hashtags; a voice guide that bans vague terms like "sp" or "collab" for disclosures matches that guidance. The FTC's advertising and marketing hub sets the broader standard that claims in ads must be truthful and evidence-based, so add a rule that any superlative needs a source or gets cut. If your copy touches products in regulated categories, also check the specific rules before you let a model draft unsupervised.

One practical tip: keep the banned list versioned and short. A 300-word list gets skimmed by the model as much as by a human. Twenty to forty entries, each with a replacement, is enough to change output, and you can grow it as you spot repeats during testing.

Samples do what rules cannot: they show the rhythm, the level of directness, and how the voice handles bad news. Glean's guide recommends pairing every rule with annotated writing samples so the model can see the rule applied, and Optimizely gives a prompt pattern that does the same thing with examples of the brand voice plus a rewrite instruction.

Include two or three paragraphs, 80 to 150 words each, and annotate each one. The annotation is the part most guides leave out, and it is what makes the sample usable:

SAMPLE 1: order delay email (annotate: what to copy)
"Your order is running two days late. The carrier flagged a delay at the
regional hub, and the new delivery date is Thursday. You do not need to do
anything. If Thursday does not work, reply to this email and we will hold
the package at the nearest pickup point."

Why this is on-voice:
- First sentence states the problem in 8 words.
- One long sentence (28 words) carries the condition and the fix.
- No apology paragraph before the facts.
- Second-person throughout; no passive voice in the first three sentences.
- Zero banned words.

Pick samples that cover different jobs, not different topics: a good-news confirmation, a bad-news delay or failure, and a persuasive product paragraph. Those three exercise most of the tension in a voice guide, because a voice that works on a launch post often falls apart when it has to deliver a delay.

There are limits on relying on samples alone. Quora answers on making AI writing sound human push back on the sample-and-style-guide approach from practitioners who have run it, and the substance of that objection is worth internalizing: if the reference set is whatever you approved most recently, the model drifts toward that, so keep the samples fixed and curated rather than swapping in recent drafts. Treat the sample block as a locked artifact and update it deliberately, not by accretion.

If your content runs in several languages, add a rule about what travels and what does not. Optimizely recommends localizing tone for cultural context while keeping the core personality, and a voice guide should say explicitly which rules survive translation (directness, no hype) and which are English-specific (contractions, sentence length bands may need recalibration per language).

Put the voice section in your system prompt and keep it in a fixed order, so you can diff versions and so the model sees constraints before it sees the task. A workable order is identity, audience, sentence rules, banned list, samples, then output format. Vapi's prompting guide breaks production voice prompts into six sections (identity and personality, response guidelines, guardrails, context, workflow, examples) and notes that the prompt is re-executed on every turn, which is why bloat costs you: every token in the voice section is paid for on every request. For text generation the latency point matters less, but the discipline does not change. Keep the voice section to roughly 300 to 600 words.

VOICE (read before writing)
1. Who is speaking: [brand], to [audience]. Plain, direct, no hype.
2. Sentence length: 8 to 20 words for 80% of sentences. Max 35. No
   two long sentences in a row.
3. Banned: delve, leverage, seamless, robust, elevate, game-changer,
   unlock, "It's not X, it's Y", "In today's". See list for replacements.
4. Claims: every superlative needs a source or gets cut.
5. Samples: [three annotated paragraphs].
6. Output: [format, length, structure].

Two decisions come up every time. The first is where the voice guide lives: inline in the prompt, or retrieved from a document store. If you generate across many surfaces (support macros, product pages, ad copy) with different prompts, a single maintained guide that is retrieved and injected keeps the version consistent. Glean recommends building a template the AI can retrieve and apply, and connecting it to approved knowledge rather than relying on memory. If you run one prompt, inline is simpler and easier to diff.

The second is guardrails versus preferences. Rules that must never break (disclosure language, no invented statistics, no prices unless sourced) belong in a short hard block the model is told overrides everything else, which mirrors the guardrails section in Vapi's guide. Style preferences (sentence rhythm, banned words) sit below it. Mixing the two teaches the model that all rules are negotiable.

If you run many models and want one place to route text, image and embedding calls while keeping the same voice section, Quanta Inference exposes them through one OpenAI-compatible API key, which makes A/B testing a guide across models a configuration change rather than a rewrite.

Generating one paragraph and liking it proves nothing. Probabilistic regressions do not show up in one-off testing, as Vapi's guide puts it, and its test-and-refine loop is the right shape: design, test against a representative set, refine, repeat.

Run this procedure on every guide change:

1. Generate 10 paragraphs from the guide using 10 different briefs, including at least two bad-news or correction scenarios.
2. Count sentences per paragraph and record how many fall inside 8 to 20 words, how many exceed 35, and the average.
3. Search the output for every banned word and construction, case-insensitive. Record the count.
4. Check that every superlative and number has a source in the brief.
5. Read each paragraph against the three samples and mark pass or fail.
6. Compare the numbers to your thresholds and iterate.

Set pass thresholds before you look at output, or you will rationalize whatever came back:

Worked example: a support-email guide fails at 7 of 10 sentences in range, with an average of 24 words. The cause is usually the model packing the condition and the fix into one clause. The fix is not "write shorter sentences" (already there) but a new rule: "If a sentence contains both a condition and an instruction, split it into two sentences and put the condition first." Regenerate the same 10 briefs and recount. If the average drops to 15 and in-range hits 9 of 10, keep the rule; if not, the model is ignoring the block and you need the rule higher in the prompt.

For support and conversational copy, add a listening check. Vapi's guide notes that spoken responses must be concise and that turn-taking replaces scrolling, so read the output aloud and cut anything you cannot say in one breath. Reference points on voice latency and brevity appear in VoiceInfra's voice prompt engineering guide, though read the specific figures there with care since they are the author's compilation rather than a primary study.

Two more testing notes. Score against your samples, not against your taste; taste moves, samples do not. And keep the 10 briefs in a file so every future guide change is measured on the same inputs, otherwise you cannot tell whether the guide improved or the briefs got easier.

The iterate step is where guides die. Every correction adds a rule, the section grows past a thousand words, and the model starts dropping the ones at the bottom. Manage it with a simple policy: a rule earns its place only if a counted failure traces to its absence.

Keep a change log with three columns: the failure (which metric, which brief), the rule added, and the before-and-after score on the 10-brief set. Delete any rule that has not fired a failure in two consecutive test rounds; the banned list is the exception, because a dormant banned word still costs you when a new model reaches for it. Merge overlapping rules when you edit, and keep the whole voice section under about 600 words by cutting examples before you cut rules.

When you rewrite an output by hand, that rewrite is data. Note what you changed (a sentence split, a word swap, a deleted paragraph) and turn the pattern into a rule rather than leaving it as a one-off fix. Optimizely makes the same case for brand voice QA, using a model to scan a batch of drafts and flag deviations from the stated tone, which is just the counting step above run by machine. Reserve sensitive or high-stakes messaging for human writers, as Optimizely advises, and let the guide handle the high-volume middle.

If the guide needs to run across many content types and you would rather have a specialist build and test it with you than start from a blank prompt, Quanta takes a description of the document, site or workflow and pairs you with someone who builds it.