Every team that writes with AI eventually produces some version of the same document: a page of adjectives. Confident but not arrogant. Warm but professional. Clear and concise. Concise but thorough. The page gets pinned in a channel, someone pastes it into a prompt, and the output barely changes — because adjectives are not instructions.
A tone-of-voice guide that a model can follow is made of different material: choices with two named options, examples with a stated reason, and a list of things not to do phrased as forbidden constructions rather than forbidden moods. This guide walks through how to build one, in the order that makes it usable.
Why "friendly but professional" produces nothing
An adjective describes a result. It does not describe a decision. When you tell a writer or a model to be professional, you have stated a goal and withheld the method, so it falls back on whatever convention it has seen most often — usually the register of corporate press releases, which is professional in the least useful sense of the word.
There is a second problem: adjectives without a reference point are unfalsifiable. Nobody can look at a draft and say "this is not warm enough" with any confidence, so the feedback loop never closes and the guide never improves.
The fix is to replace every adjective with a choice. Not "be friendly" but "address the reader as you, not as customers." Not "be concise" but "cut any sentence whose only job is to announce what the next sentence does." Two named options turn a preference into a rule you can apply to a paragraph, and rules can be applied consistently — which is the entire point of a guide.
Describe choices, not adjectives
Run this exercise over your existing guide. For each adjective, write the sentence that violates it and the sentence that satisfies it. If you cannot produce both examples quickly, the adjective is not ready to be in the guide.
Here is the test that matters: could a reasonably careful person apply this rule and reach the same verdict you would? If not, the rule is still too abstract. "Avoid jargon" fails that test, because what counts as jargon depends on the audience. "Expand an acronym on first use, then use the short form" passes it.
Guides built this way get shorter, not longer. Most teams find that three quarters of the adjectives in their original document collapse into a dozen concrete choices, and the remaining quarter were never actionable to begin with.
The four sliders worth writing down
Most voice differences between publications can be located on four axes. Naming your position on each one captures more than a page of prose.
- Distance. How close the writer stands to the reader. First person plural, direct second person, or impersonal advisory. Pick one as the default and note the exceptions.
- Certainty. How much hedging you allow. "This usually works" and "this works" are different publications. Decide which one you are, and say when you break the rule — usually for claims you can verify yourself.
- Sentence length. Not a number, a habit. Long sentences that carry an argument versus short sentences that carry a point. Most editorial voices are recognisable here before anywhere else.
- Specificity. Whether you name prices, tools, durations and counts, or stay general. This is the axis that most often separates a useful publication from a forgettable one.
Write your default for each axis in one line, with one example. Four lines total. That is a usable voice specification, and it fits in a prompt without crowding out the actual task.
Keep a banned-construction list
Models do not have a bad vocabulary so much as a set of overused constructions. Banning words rarely works, because the model substitutes a synonym and the problem survives. Banning constructions works, because the construction is the problem.
A useful list usually includes sentence openers that announce rather than say something ("It is important to note that"), transitions that inflate a small point ("but the real secret is"), tricolons used as filler, rhetorical questions in body prose, and closing paragraphs that restate the introduction in different words. Add to the list whenever you find yourself deleting the same shape twice, and phrase each entry as a construction, not a word.
Keep the list short enough to read in one screen. A banned list of eighty items gets ignored by humans and diluted by models; fifteen items get applied.
One good and bad pair beats ten rules
The single highest-value page in a voice guide is a table of paired examples: a sentence that sounds like you, and the same sentence rewritten to sound like a generic marketing department. Four or five pairs will do more work than the rest of the document combined, because they let a writer generalise from cases instead of parsing abstractions.
Write each pair about your own subject, not about an abstract example. Generic pairs teach nothing because the difference has to be inferred. Pairs drawn from your actual products and articles teach both the voice and the subject at once.
Label the pairs with the reason, briefly. "We use the plain verb because the reader is deciding whether to spend money, and hedging makes that decision slower." A labelled pair survives turnover; an unlabelled one gets copied without being understood, and then misapplied to a different context.
Where the guide has to live to get used
A guide is used when it is closer to the work than to the archive. If it lives in a wiki that nobody opens while writing, it is documentation, not a rule. Put the four sliders and the banned constructions directly in the prompt or template that generates drafts, and keep the longer document for humans. The one-paragraph version is the one that shapes output; the long version exists so people can understand why.
For teams, keep both versions synchronised from a single source. When someone proposes a new rule, the test is whether it can be stated in one line and demonstrated with a pair. If it cannot, it belongs in a discussion, not in the guide.
Reviewing output against the guide
Review becomes fast once the guide is concrete, because most edits fall into three buckets: the draft used an adjective-register the guide forbids, it hedged a claim the guide says to state plainly, or it stayed general where the guide demands specifics. Name the bucket when you give feedback. "This is a hedging problem, not a tone problem" tells the writer or the prompt what to change next time.
Track which bucket produces the most edits over a month. That is your guide's weakest axis, and it is where the next revision should go. A voice guide that is not producing a measurable reduction in one of those buckets is not being applied.
Updating the guide without rewriting it every month
Voice guides die from over-maintenance as often as from neglect. Aim for a monthly twenty-minute pass: add banned constructions you caught yourself removing, promote a repeated edit into a rule, retire any rule nobody has cited in a quarter.
Change one axis at a time. Rewriting all four sliders at once invalidates the examples and the banned list along with them, and the team spends the next month relearning instead of writing. A voice is a set of habits, and habits change one at a time or not at all.