Resources
Keep a consistent voice across a writing team
Turn abstract voice adjectives into annotated examples, channel rules and editorial decisions that contributors can apply to real assignments.

A team can agree that its writing should sound clear, confident and friendly while disagreeing about almost every sentence. One contributor interprets friendly as playful. Another adds reassurance to each paragraph. An editor removes both and replaces them with a formal explanation. The same arguments return on the next assignment.
Consistency improves when a voice guide records decisions people can apply. It should show how the organization addresses a reader, how it explains difficult subjects and how its language changes with the situation. A handful of annotated examples often does more work than a page of adjectives.
AI-assisted drafting makes those decisions worth documenting carefully. A tool can produce many variations quickly, but the team still needs to decide which version fits the reader and why. Start with a one-page guide and an example library that can grow as actual questions arise.
Separate steady voice from situational tone
Mailchimp’s voice and tone guidance distinguishes a relatively stable voice from a tone that adapts to the reader’s circumstances. Its own personality choices belong to Mailchimp; a different organization should make its own choices. The useful distinction is between a lasting relationship with the audience and the mood appropriate to a particular moment.
A project-management company might choose to sound practical, candid and respectful. Its release announcement can show enthusiasm. Its service interruption message should give the current situation and next update directly. Both can belong to the same organization without sharing the same emotional register.
Write the stable voice as behavior. “Respectful” might mean explaining unfamiliar terms without calling a task easy. “Candid” might mean stating a limitation beside the relevant feature. “Practical” might mean ending instructional sections with a specific next action. These statements give reviewers something they can identify in a draft.
Build the guide from actual writing decisions
Collect a small selection of approved work: an instructional paragraph, an announcement, a difficult customer message and a longer explanation. Choose examples that show different writing jobs. Three promotional paragraphs will not teach a support writer how to handle frustration.
Ask editors to mark the exact phrases that express the desired voice. Explain the decision beneath each example. A note such as “Names the limitation before offering the workaround” teaches a pattern a contributor can reuse. “Sounds like us” leaves the reasoning hidden.
Do the same with a few examples that need revision. Use invented or appropriately anonymized text when sharing mistakes would embarrass a colleague. Keep the discussion about the reader’s experience and the choices available to the writer.
Do not turn one founder’s conversational habits into mandatory rules by accident. Decide whether a phrase belongs to the brand, to a particular spokesperson or only to that piece. An interview should preserve the speaker’s character; a help page should support the user’s task.
Show a before-and-after example with a reason
Consider this illustrative sentence: “We’re super excited to bring your team our amazing new approval experience.” A practical revision could be: “You can now assign a backup reviewer to keep approvals moving when someone is away.”
The revision replaces vague enthusiasm with the capability and its use. If that capability has an account restriction, the surrounding copy should state it. Voice editing must not erase the conditions that make a claim accurate.
Now consider an error message: “Oops! Your upload has hit a tiny snag.” A more helpful version could be: “The file did not upload. Try again, or choose a file under the stated size limit.” That wording is only appropriate if those actions match the actual product behavior. A writer should confirm the cause and available recovery path rather than inventing a reassuring instruction.
The GOV.UK guidance on writing for user interfaces emphasizes writing for how people use a service, including readers who do not examine every word closely. For a team voice guide, this supports reviewing messages in their surrounding screen or workflow, where the wording has a job to perform.
Give each channel a short tone note
A newsletter, billing notice and documentation page may share terminology but need different pacing. Add a short note for each recurring channel: the reader’s likely state, the message’s main job and the amount of personality that helps.
For a tutorial, the reader may be concentrating on an unfamiliar task. Prefer direct steps, visible prerequisites and examples that explain the result. For a product announcement, a brief expression of enthusiasm can fit, followed by the practical change and any limits. For an apology, acknowledge the problem and explain the available next step before adding brand personality.
Keep these notes brief enough that a contributor can consult them during an assignment. If exceptions fill the page, the rule may be too broad. “Always be upbeat” creates predictable trouble in difficult messages. “Match the reader’s situation and explain what happens next” gives a writer more useful direction.
Maintain a vocabulary and decision log
Record the preferred names of products, features and common actions. Include capitalization and a short definition where similar terms cause confusion. Decide, for example, whether “review” means checking a draft and “approval” means authorizing publication. Using those words interchangeably can obscure responsibilities.
Keep mechanical preferences separate from voice principles. Date formats, serial commas and heading capitalization belong in a style reference. They matter, but they should not crowd out guidance about how the organization explains uncertainty or addresses a frustrated reader.
Create a decision log for recurring disputes. Each entry needs the question, the decision, the reason and an example. “Use ‘people’ instead of ‘users’ in customer-facing educational articles, except when discussing a product role named User” is a decision a writer can follow. Give the log an owner who can settle conflicts and remove outdated entries.
Brief AI tools with the relevant examples
For an AI-assisted assignment, supply the short voice guide, the channel note and two examples that match the task. Identify which facts in the examples are illustrative and must not appear in the new piece. Include the assignment’s sources and constraints separately.
Ask for a draft that follows the documented behaviors. Avoid relying on a request to “sound human” or “write in our brand voice” when neither phrase has been defined. Those instructions leave the model and editor to supply their own assumptions.
Review the output against the guide without treating the guide as a guarantee. A sentence may imitate the rhythm of an example while missing its purpose. The backup-reviewer sentence works because it explains a real capability in a relevant situation, not because every announcement should begin with the same three words.
Calibrate editors on one short passage
Have two or three reviewers edit the same paragraph independently. Compare their changes and ask which rule explains each one. If a reviewer cannot connect a change to the reader’s needs, factual accuracy or a documented choice, it may be personal preference.
Use disagreement to improve the guide. Perhaps the team has never decided how much humor belongs in onboarding, or when a technical term deserves a definition. Add one example that resolves the issue. Avoid expanding the guide with a new prohibition after every unusual sentence.
Set a modest review rhythm, such as revisiting the examples after a batch of published work. Remove examples tied to obsolete product behavior. Keep a date and owner on the guide so contributors know which version to use.
Start your one-page version with three voice behaviors, three annotated examples, a few channel notes and the person responsible for decisions. Give it to someone who did not help write it and ask them to revise a real passage. The places where they hesitate will tell you what the guide needs next.
