A brand voice document can read beautifully and still fail the moment you paste it into a prompt. It says the brand is bold, friendly, human, then leaves the assistant to work out what those words mean. The output shifts with every writer, channel and model.
A voice file that works describes choices someone can check. It shows how a sentence should sound, which version is wrong, and how the tone moves when the situation moves. It also needs an owner, or it joins the pile of approved files nobody updates.
We think examples do more work than adjectives. A short rule sitting beside a real line gives an AI something concrete to copy.
Turn principles into writing decisions
Start with the reader and the job. Atlassian's brand team tells staff to state audience, purpose and tone when using AI to write, and to keep fact-checking and accountability with a person. Those fields belong near the top of your document, because the language after them changes when they change.
Examples should show the edit, not only the finished line. Microsoft's style and voice tips pair each rule with the text to replace and a better version. That format exposes the decision. Asking an AI to sound more conversational does not.
Use these sections in this order
- File header. Example: Version 1.4, owned by marketing operations, reviewed on 2 September 2026.
- Purpose and scope. Example: Use this file for website pages, emails and organic social posts.
- Audience. Example: Write for a Singapore marketing manager who knows the business problem but does not write code.
- Brand position. Example: We give practical advice before mentioning a service, because trust depends on useful detail.
- Voice principles. Example: Sound warm and direct by using everyday words, short openings and specific nouns.
- Tone by situation. Example: For a launch, sound confident; for a service problem, stay calm and precise.
- Language rules. Example: Use Singaporean spelling, sentence-case headings and contractions where they sound natural.
- Approved and avoided terms. Example: Say customer group; avoid target persona unless the research team uses that term.
- Do and don't pairs. Example: Write 'Save the report as a PDF.' Avoid 'You can proceed to save the report in PDF format.'
- Reference samples. Example: One approved email opening, with a note on which voice principle it demonstrates.
- Test and change record. Example: Test five common tasks, record the failures, note each edit under version 1.5.
Keep the document short enough to attach to a normal task. Push long campaign references into separate files and link them from the voice document. The core file holds rules that apply often. Examples tied to one promotion expire fast.
Leave out company history unless it changes today's writing. Skip the page of personality adjectives, and skip pages of perfect copy with no notes. An AI needs the decision behind the example: why the approved version works, which rule it applies, and where that rule should not apply.
The file should also set authority. Say which claims need a source, which product names must match official copy, and when the assistant has to stop and ask a human. Style cannot rescue an invented fact.
Test the voice file against real work
Build a small test set from work your team already does. An email, a landing page opening, a paid social caption, a reply to a complaint. Add one hard case, such as a factual correction that must not sound defensive. Run the same prompts twice, once without the voice file and once with it.
Score each response for audience fit, tone, banned language, factual restraint and edit time. Keep the original outputs. Google describes using a ground-truth dataset and baseline prompt when testing prompt changes through a model upgrade. Yours can be a table in a spreadsheet, as long as the examples stay fixed and the standard is written down.
Test again when the model changes, or when the file gets a real edit. GitHub's instruction-file workflow lets teams validate changes in a feature branch before merging them. A marketing team can copy the principle with a dated draft and a named reviewer.
Give one person the final call
Name an owner who can settle conflicts and delete examples that have aged out. Then set a review cadence and write it into the file itself. Quarterly suits most teams. If your products or your tools move faster than that, review sooner.
Start with three pieces of approved copy and write the rules that explain why they work. Test the resulting file on one live brief. Keep the edits that reduce corrections, record the new version, and get a human editor to approve it before the team adopts it.