---
title: "Brand voice examples, and how to write rules AI can follow | Rainbrand"
description: "Learn from seven published voice guides, then turn their useful habits into rules, examples and tone instructions for your own agents."
url: "https://www.rainbrand.com/blog/brand-voice-examples/"
---

By [Tomas Ward](https://www.linkedin.com/in/tomasward1/)

Published 28 Oct 2026

8 min read

# Brand voice examples, and how to write rules AI can follow

Learn from seven published voice guides, then turn their useful habits into rules, examples and tone instructions for your own agents.

## TL;DR

Learn from how published voice guides turn a brand's voice into instructions: clear limits, preferred wording, paired examples and tone that fits the situation. Choose rules for your own audience, and make them specific enough that an agent can apply them and a reviewer can check the result.

## Where the useful examples are

A list of famous brands, adjectives drawn from their ads and a few social posts shows what a voice sounds like once it's finished. It doesn't show what the writers were told. If you give an agent only “witty and irreverent”, you leave it to decide what those words mean for your brand.

Some organisations publish the guidance itself. The seven below give you something more useful to study: the instructions behind the copy. We read their public guides for this article; we have not tested a model's ability to reproduce each voice.

| Guide | Written for | Habit worth borrowing |
| --- | --- | --- |
| Mailchimp | Its content | Limits and tie-breakers |
| GOV.UK | Government content and services | Replacements and exceptions |
| Microsoft | Its products and content | Before-and-after pairs |
| Google | Developer documentation | Examples on either side of the target |
| Atlassian | Interfaces and app experiences | Tone by message type |
| Shopify | Apps in its admin | Tone by observable situation |
| Monzo | Writing across the bank | Trait levels by channel |

They also disagree. [Google recommends negative contractions](https://developers.google.com/style/contractions) such as “don't”, because a reader scanning a page can miss a separate “not”. [GOV.UK avoids them](https://guidance.publishing.service.gov.uk/writing-to-gov-uk-standards/writing-guidelines/clear-language/), because readers can find them hard to read or mistake their meaning. Microsoft includes “let's” in its [recommended contractions](https://learn.microsoft.com/en-us/style-guide/top-10-tips-style-voice); Google's [tone guide](https://developers.google.com/style/tone) discourages that phrasing.

Combining every rule would give your agent conflicting instructions. Borrow the way a guide makes a decision, then make that decision for your own audience.

## Mailchimp: give traits limits

[Mailchimp's voice guide](https://styleguide.mailchimp.com/voice-and-tone/) combines a plainspoken voice with dry humour. It also settles the conflict between those traits: clarity takes priority over entertainment, and uncertain jokes can be left out. Freddie, its mascot, gets a particularly concrete rule: he does not speak, so writers should not give him a voice.

Those instructions are easier to apply than the humour adjectives alone. An agent can remove a joke that obscures a message, and a reviewer can check whether it has written dialogue for Freddie. Deciding whether a line has the right kind of dry humour still needs examples.

For your guide, keep the memorable trait name and add the decision underneath it. If you want playful launch copy and clear product instructions, say which messages may contain jokes and what a joke must never make harder to understand.

## GOV.UK: include replacements and exceptions

GOV.UK's [tone guidance](https://guidance.publishing.service.gov.uk/writing-to-gov-uk-standards/writing-guidelines/right-tone/) calls for direct, concise government content. Its [clear-language rules](https://guidance.publishing.service.gov.uk/writing-to-gov-uk-standards/writing-guidelines/clear-language/) turn that intention into instructions an editor can apply: replace formal words with familiar ones, and explain necessary specialist terms on first use.

The [words-to-avoid list](https://guidance.publishing.service.gov.uk/writing-to-gov-uk-standards/style-guides/a-to-z-style-guide/#words-to-avoid) is useful because it goes beyond prohibitions. It offers alternatives to vague language and names exceptions. “Deploy” is acceptable in military or software contexts; “leverage” has a financial exception.

That is a good structure for your vocabulary rules. Give the word, its preferred replacement and the circumstances where it remains accurate. A software brand that copied the prohibited words and lost the exceptions would make its own technical writing worse.

## Microsoft: show the edit

Microsoft's [style and voice tips](https://learn.microsoft.com/en-us/style-guide/top-10-tips-style-voice) pair advice with a before and after. Under the instruction to write conversationally, “Invalid ID” becomes “You need an ID that looks like this: [someone@example.com](mailto:someone@example.com)”. The revised line gives the reader a usable example of the expected input.

The pair teaches a specific editing move. For a similar message in your own product, an agent can replace a bare rejection with the required format. Add a pair from your own edits and explain what the revision fixes. Include examples from longer work if you expect the same guide to shape articles or emails; short interface strings do not show how those formats should develop.

## Google: show where the range ends

[Google's developer documentation guide](https://developers.google.com/style/tone) places a recommended sentence between versions that are too informal and too formal. One row contrasts an excited endorsement of an API with an inflated description of acquiring user information. The middle version says plainly what the API lets you collect.

A recommended example gives the agent a target. Examples on either side show the choices you would edit out. This is useful for instructions such as “conversational”, where a casual greeting and a clear technical explanation can both appear to fit the word.

Google also discourages describing procedures as easy or quick. If you use a similar rule, explain why it belongs: someone who is stuck needs the next step, and calling the task easy adds nothing to that step.

## Atlassian: connect tone to message type

[Atlassian's public guide](https://atlassian.design/foundations/content/voice-tone) covers interfaces and app experiences. Its traits include boldness, optimism and a practical approach with occasional light touches. It varies their use by audience and situation, including errors and completed tasks. Broader marketing guidance is linked separately for Atlassian staff.

For an agent, message types provide something concrete to work from. A repeated error message and a one-time completion message need different treatment. Atlassian also cautions that a pleasing flourish can become annoying when encountered repeatedly.

Borrow the connection to a situation the task identifies. If your guidance asks the writer to judge the reader's mood, also say what to do when that mood is unknown.

## Shopify: use the situation you can observe

Shopify's [app-writing guide](https://shopify.dev/docs/apps/design/content/voice-and-tone) addresses developers whose apps form part of the merchant's Shopify experience. It points out that a writer cannot know a merchant's emotional state and should concentrate on the situation.

For a routine action, it recommends a simple confirmation such as “Product saved”. It discourages calling a basic action a success or assuming that the merchant feels like celebrating. For serious problems, it asks writers to explain the impact and provide useful next steps.

This gives an agent a way to select tone from the task. “Confirm that a product was saved” contains enough information to choose a restrained response. “Make it encouraging” leaves open whether encouragement is useful there.

If your product writes on behalf of other brands, include this situation-level guidance in what their agents receive. It tells the writer when a trait applies.

## Monzo: explain the level and the literal misreading

[Monzo's writing principles](https://monzo.com/tone-of-voice) apply across the bank. They vary traits by channel: the channel table sets warm wit to “None” for operational communications and customer service, while marketing and organic social allow more. That gives a writer a starting decision about humour before choosing a line.

The guide also explains a potential misreading of its “everyday magic” trait. It means an unexpected, welcome touch in the experience; it does not call for magical language. The name alone could be read as an instruction to use that vocabulary.

If you use a named trait, write down the literal interpretation you want to avoid. Add examples to explain levels such as “medium”. A channel table can establish that humour is allowed without showing how much belongs in a particular email.

## Turn an example into your own instruction

The useful pattern across these guides is a decision you can carry into a draft. Keep its source, scope and reason when you adapt it. [Anthropic's prompting guidance](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices) likewise recommends relevant, varied examples and explaining the reason behind an instruction.

Here is an instructional example for fictional Acme, which makes Atlas Pro, a design tool. It adapts the habits above.

```
Trait: Friendly
Audience: Product designers using Atlas Pro
Rule: In an error message, name the problem and the next action.
Tone: Calm; leave humour out of errors and support replies.
Priority: Keep the instruction clear if a playful line competes with it.
Preferred wording: Use familiar product terms such as "export".
Avoid: Greetings or celebrations that delay the useful information.

Illustrative near-miss:
"Oops! Your export hit a snag."

Illustrative preferred version, if a missing file is the confirmed cause:
"A linked file is missing. Relink it and export again."

Reason: A designer needs to know what to fix.
Fact to supply for each task: The actual cause and available next action.
```

The last line matters. An example can teach the right sentence shape while supplying the wrong cause for the next error. Label proposed examples and approved copy, and keep the task's facts separate.

Use this request to find gaps in an existing guide:

Ask your agent

```
Read our brand voice guide. For each trait, identify its scope, practical rules, reasons, examples and any priority when rules conflict. Quote the source passage for each finding. Flag adjectives that still leave the writing decision open. Draft proposed additions separately, using our own approved copy where available. Do not treat a proposed example as an existing brand fact or change the maintained guide yet.
```

## Keep the source and the rule together

For a complete file to inspect, [download the TANNIN example Brand Skill](https://www.rainbrand.com/downloads/tannin-brand-skill.zip) and open `references/voice-and-messaging.md`. A Brand Skill is brand guidance and asset references arranged for an agent to use. This package turns Anna Kuziuk's TANNIN tea-room concept into guidance and assets for agents.

The voice file permits playful campaign statements while keeping utility wording literal. It separates source phrases from a new demonstration headline. Read its `ATTRIBUTION.md` alongside it so those distinctions stay visible when you reuse the example.

When this work recurs, [Rainbrand maintains brand context](https://docs.rainbrand.com/guides/create-brand) that connected agents can use. Add your guide as a brand source, or [prepare an edit](https://docs.rainbrand.com/guides/edit-brand) to an existing brand. Inspect the proposed changes, refine them if needed and apply or discard the edit. After applying it, request a new [Brief](https://docs.rainbrand.com/guides/request-brief), which selects guidance and assets for the writing task. Name the audience, channel and situation so the relevant tone rules can be selected.

Start with one disagreement your team encounters, such as contractions or celebration after a routine action. Choose the rule that serves your audience, record the reason and add a near-miss. [The voice-guide tutorial](https://www.rainbrand.com/blog/write-a-brand-voice-guide-for-ai/) shows how to build and test the rest of the guide from those records.

## More in Brand voice

- 28 Oct 2026 9 min read

    ### [How to write brand voice guidelines AI tools can follow](https://www.rainbrand.com/blog/write-a-brand-voice-guide-for-ai/)

    Build a voice guide from real edits, with rules, examples, tone by situation and a worksheet you can test on your agents' writing tasks.

One brand, every agent.

[Connect your agents](https://docs.rainbrand.com/mcp/getting-started)