KoltrixWriting a style guide your AI drafts can follow
A one-page style guide template for AI-drafted email: voice, banned words, formatting, sign-offs, and the policies a model must never invent on its own.
On this page(6 sections)
- Why one page
- The template
- Section by section, with examples
- 1. Voice: three adjectives and their opposites
- 2. Structure: the answer first
- 3. Words to avoid
- 4. Greetings and sign-offs
- 5. The "never invent" list
- 6. Tone by situation
- 7. Real examples
- Mistakes that make style guides fail
- How to roll it out
- Bottom line
Left to its defaults, an AI drafting assistant writes like a polite stranger: "I hope this email finds you well," three sentences of apology, and a closing offer to help with anything else at all. It's not wrong, exactly. It just doesn't sound like your team.
A short style guide fixes most of that. It also does something more important: it tells the model what it must never make up. This post gives you a one-page template you can fill in, plus good-and-bad examples for each section.
Why one page
A long brand book written for marketing doesn't translate well to email drafting. Models (and people) follow short, concrete instructions better than long, abstract ones. One page forces you to choose what matters. If your guide needs a table of contents, it's too long for this purpose.
The guide serves two audiences at once: the AI producing drafts, and the teammates reviewing them. Both should be able to read it in two minutes.
The template
Copy this, fill in the brackets, and delete anything that doesn't apply.
EMAIL STYLE GUIDE – [Team / mailbox name]
Last updated: [date] Owner: [name]
1. WHO WE ARE IN EMAIL
We sound like: [three adjectives, e.g. direct, warm, competent]
We do not sound like: [e.g. a call center, a law firm, a hype ad]
Default reading level: plain English, short sentences.
2. STRUCTURE
- Answer or main point in the first two lines.
- Short paragraphs (1–3 sentences).
- Numbered steps for instructions.
- One question per email where possible.
- Typical length: [e.g. under 150 words unless steps are needed].
3. WORDS AND PHRASES
Use: [e.g. "you can", "here's how", customer's own terms]
Avoid: [e.g. "I hope this finds you well", "unfortunately",
"per our policy", "kindly", "do not hesitate", exclamation marks]
Product names: [exact spelling and capitalization]
4. GREETINGS AND SIGN-OFFS
Greeting: [e.g. "Hi [first name],"]
Sign-off: [e.g. first name only; no "Best regards"]
Signature: [what's included]
5. NEVER INVENT – ASK A HUMAN
The draft must not state or promise anything about:
- Refunds, credits, discounts or pricing exceptions
- Delivery dates, release dates or timelines
- Legal, security or compliance commitments
- Features that are not in [link to docs]
If the reply needs one of these, write [NEEDS DECISION: ...]
instead of making it up.
6. TONE BY SITUATION
Upset customer: acknowledge specifically, no defensiveness.
Bug report: thank, confirm what we know, give next step.
Sales question: answer plainly, no pressure.
Saying no: say it early, explain briefly, offer an alternative.
7. EXAMPLES
[Two or three real replies the team is proud of, anonymized]
Section by section, with examples
1. Voice: three adjectives and their opposites
Adjectives alone are vague; "friendly" means different things to different people. Pairing them with what you're not makes them concrete.
| Instead of | Write |
|---|---|
| "We're thrilled to help you with your inquiry!" | "Happy to help with this." |
| "Please be advised that the feature is unavailable." | "That feature isn't available yet." |
2. Structure: the answer first
Models love to build up to the point. Your guide should explicitly tell them not to.
| Instead of | Write |
|---|---|
| "Thanks so much for reaching out. I completely understand how frustrating... After looking into it, it seems that..." | "You can export your data from Settings → Export. Here's how:" |
3. Words to avoid
Every team has phrases that make them wince. List them. Common candidates in support email:
- "I hope this email finds you well"
- "Unfortunately" (usually unnecessary; just say what's true)
- "Please do not hesitate to contact us"
- "We apologize for any inconvenience" (vague; apologize for the specific thing)
- "Kindly" as a request
Also list your own product's terminology. If your product has "workspaces," the draft shouldn't say "accounts" or "organizations."
4. Greetings and sign-offs
Small, but highly visible. A consistent greeting and sign-off makes drafts from different people feel like one team. Decide whether replies are signed by an individual's first name or by the team, and stick to it.
5. The "never invent" list
This is the most important section. Language models are fluent, and fluent text can contain confident fabrications: a refund window you don't offer, a release date nobody agreed to, a feature that doesn't exist.
| Bad draft | Good draft |
|---|---|
| "We'll have this fixed by Friday." | "Our engineers are on it. I'll update you by [NEEDS DECISION: update time]." |
| "I've gone ahead and refunded your last three months." | "[NEEDS DECISION: refund request for three months]" |
| "Yes, you can sync with that calendar app." | "[NEEDS DECISION: confirm calendar integration exists]" |
A visible placeholder is far better than a plausible guess, because reviewers can't miss it. The reviewer fills it in, or escalates.
6. Tone by situation
The same voice flexes by situation. Short rules per scenario help both the model and new teammates. Keep each to one line.
7. Real examples
Two or three anonymized replies your team considers excellent often teach more than all the rules combined. Pick examples that show the voice in difficult situations, not just easy ones.
Mistakes that make style guides fail
Writing aspirations instead of instructions. "We delight our customers" gives a model nothing to act on. "Answer in the first two lines" does. Every line in the guide should be something a reviewer can check a draft against.
Copying the marketing voice. A homepage can be punchy and bold. Support email needs to be calm and precise, especially when something has gone wrong. Borrow the vocabulary from marketing, not the energy.
Forgetting the reviewer. If teammates don't know the guide exists, they'll "fix" drafts back toward their personal style, and the guide stops mattering. Walk the team through it once, and link it wherever people review drafts.
Listing too many banned phrases. Twenty avoided phrases is a reasonable ceiling. Beyond that, people stop reading the list and the model gets contradictory signals.
Never updating it. Products change. A feature that didn't exist in spring might be in the docs by autumn, and the "never invent" list should move with it. Put the owner's name and the last-updated date at the top so it's obvious when the guide is stale.
Treating it as a replacement for judgment. The guide narrows the range of drafts; it doesn't make them correct. Facts, commitments and tone in a tense situation still need a person's eyes before anything is sent.
How to roll it out
- Draft the guide in an hour. Don't aim for perfect; aim for version one.
- Test on real threads. Generate drafts for ten recent emails with the guide in place, and compare with what your team actually sent.
- Note recurring problems. If drafts keep using a phrase you dislike, add it to the avoid list.
- Review monthly at first, then quarterly. Date every change.
- Keep reviewing drafts before sending. A style guide improves drafts; it doesn't replace the person who reads them.
Bottom line
A one-page guide covering voice, structure, banned phrases, sign-offs, situational tone and real examples gets AI drafts most of the way to sounding like your team. The section that matters most is the "never invent" list, with a visible placeholder for anything that needs a human decision.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
