KoltrixTurning recurring emails into reusable reply snippets
A worked example of building a team snippet library: finding recurring questions, writing snippets with placeholders, a personalize-this-line rule, and pruning.
On this page(11 sections)
- The setup
- Step 1: Find what actually recurs
- Step 2: Write the snippet, not the essay
- Step 3: Add the "personalize this line" rule
- Step 4: Name and organize snippets
- Step 5: Decide where snippets live and who owns them
- Step 6: Version and update
- Step 7: Retire what nobody uses
- Step 8: Teach new teammates how to use them
- Common mistakes
- Key takeaways
If you've typed the same explanation of how to export data three times this week, you don't have a writing problem. You have a missing snippet.
Snippets (also called canned responses, saved replies, or templates) save time, but bad ones make your team sound robotic. This post walks through building a small, useful snippet library from scratch, using a fictional six-person SaaS team as the example.
The setup
Our example team runs a project management tool. They share a support@ inbox and a hello@ inbox. Everyone has been writing replies from scratch, and a few people keep private text files of their favorite answers. Those private files are the first sign a team needs a shared library.
The goal for this exercise: a library of around ten to fifteen snippets that cover the most common questions, sound like the team, and stay current.
Step 1: Find what actually recurs
Don't start by brainstorming. Start with evidence.
The team exported subject lines and first lines from the last month of support email into a spreadsheet and grouped them by question. A tally after about an hour of sorting looked like this (illustrative, not a benchmark):
| Question theme | Rough count last month |
|---|---|
| How do I export my projects? | Many |
| How do I add or remove a teammate? | Many |
| Can I change my billing date? | Several |
| Why didn't I get the invite email? | Several |
| Do you have an API? | Several |
| Can I get a refund? | A few |
| Is there a mobile app? | A few |
| One-off bugs and unique questions | The rest |
The top of the list is where snippets pay off. The long tail of unique questions should be written fresh every time.
Rule of thumb: if the team has answered something three or more times in a month in roughly the same way, it's a snippet candidate.
Step 2: Write the snippet, not the essay
For each candidate, the team pulled the best real reply anyone had sent and edited it down. Here's the export snippet:
Hi [first name],
You can export everything from Settings > Data > Export. Choose CSV for
spreadsheets or JSON if you're moving to another tool. Exports include
projects, tasks and comments; attachments come as a separate zip.
[PERSONALIZE: one line about their specific situation, e.g. the size of
their account or the tool they're moving to]
If anything looks off in the file, reply here and I'll take a look.
[your name]
A few design choices worth copying:
- Placeholders in brackets for anything that changes per customer.
- A mandatory personalization line. The snippet is incomplete until someone writes it.
- Short. It answers the question and stops.
- A clear next step at the end.
Step 3: Add the "personalize this line" rule
This is the single habit that separates good snippet use from bad. The team agreed:
Every snippet has at least one line that must be written fresh for this customer. Never send a snippet with the placeholder still in it.
Why it matters:
- Customers notice when a reply ignores what they wrote.
- Writing one fresh line forces you to re-read their email, which catches the second question they asked.
- It keeps the team thinking instead of pasting.
To catch mistakes, they put placeholders in capital letters and brackets so an unfilled one is obvious before sending.
Step 4: Name and organize snippets
Snippet libraries get messy fast. The team used a naming pattern that sorts well and is searchable:
billing - change billing date
billing - refund request (needs approval)
data - export projects
team - add or remove teammate
team - invite email not received
product - API availability
product - mobile app
Category first, then a short description. Anything that requires a judgment call or approval says so in the name.
Step 5: Decide where snippets live and who owns them
Options depend on your tools: a built-in saved replies feature, a text expander, or a shared document. What matters more than the tool:
- One shared source. No private copies drifting out of date.
- An owner per snippet, or one owner for the whole library on a small team.
- A last-reviewed date on each snippet.
The team chose one person to own the library, with anyone allowed to propose changes.
Step 6: Version and update
Products change, and snippets that describe the product go stale. The team tied snippet reviews to two triggers:
- Product changes. When a feature changes, whoever ships it flags any affected snippets.
- A monthly skim. The owner reads every snippet once a month. It takes about fifteen minutes for a small library.
When a snippet changes, they note what changed and when at the bottom of the snippet's entry in the shared doc. That helps when a customer says "but your team told me something different last month".
Step 7: Retire what nobody uses
Some snippets turn out to be rarely used, or used and then heavily rewritten every time. Both are signals:
- Rarely used: delete it. A smaller library is easier to search.
- Always rewritten: the snippet is wrong, outdated, or the question varies too much for a template. Rewrite it from the best recent reply, or drop it.
After two months, the example team was down to eleven snippets from an initial fifteen, and people used all eleven.
Step 8: Teach new teammates how to use them
A snippet library is only as good as the habits around it. When the example team hired its next support person, they added a short section to onboarding:
- Read every snippet once on day one, so you know what exists.
- For the first week, open the original customer email side by side with the snippet and check that the snippet actually answers what they asked.
- If you find yourself editing the same part of a snippet every time, tell the owner. That edit probably belongs in the snippet.
- When in doubt, write from scratch. A thoughtful custom reply is never wrong; a mismatched snippet often is.
New people are also the best reviewers of the library. They notice jargon, missing steps, and assumptions that the rest of the team stopped seeing long ago.
Common mistakes
- Writing snippets for every possible question. Most questions don't recur enough.
- Snippets that are too long. If it doesn't fit on a phone screen without scrolling much, cut it.
- Locking tone into one person's voice. Write in your team voice, not the founder's personal style.
- Snippets with policy decisions baked in. Refund snippets should say what needs approval rather than promise outcomes.
Key takeaways
- Build snippets from real recurring questions, not from guesses.
- Start each snippet from the best real reply, then shorten it.
- Require one freshly written line per send; never ship an unfilled placeholder.
- Name snippets by category, keep one shared source, and give the library an owner.
- Review monthly and delete snippets that are unused or always rewritten.
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.
