By the Onsites AI team · Last updated · 5-minute read
Templates get a bad reputation because most of us have received a template that pretended it was not one — "Dear Valued Customer," it began, before ignoring everything the customer had said. The fix is not avoiding templates; it is building them honestly: a strong reusable core, a visible personal layer on top, and team-wide rules that keep ten people sounding like one. Used this way, templates are why small teams answer quickly without answering carelessly. This guide gives you ten structures that cover most of a small team's email volume, plus the etiquette that keeps them human.
Every good support reply has five blocks: greeting with a name, one line of context proving you read the thread ("your order #1041..."), the actual answer, the next step with an owner and time, and a consistent sign-off. Templates should supply the skeleton and the answer; the context line and the next step are filled in fresh every time, and they are where the humanity lives. A reply whose context line is specific, next step dated, and sign-off steady reads as personal even if two thirds of the words came from a saved template — because the parts people scan for identity are exactly the parts you personalized.
1 · First reply, problem known. Greeting, context line, a short fix in numbered steps, "reply directly to this email if a step fails." Close with the promise you can actually keep — see the SLA guide for why the promise must be one number you never miss.
2 · First reply, problem not yet known. Acknowledge within the hour, state what you need to diagnose (a screenshot, an order number, a timestamp), and give the time you will respond once it arrives. Never guess a fix for an undiagnosed problem; guessing costs credibility twice — now and when the real fix lands.
3 · Still working on it. The update nobody wants to send: what has been done, what is in the way, and the exact time of the next update. Sent proactively, it defuses more anger than any apology after silence.
4 · Delivered / resolved. Confirm the outcome, link or attach the proof, and invite recontact in one line. This is also where a one-question satisfaction ask belongs, if you run the no-tool CSAT habit.
5 · Bad news: cannot do it. Lead with the answer ("I'm afraid we can't extend the return window"), give the reason honestly, and immediately offer the nearest thing you can do. Never bury the no under three paragraphs of throat-clearing — the saying-no guide holds the full playbook.
6 · Refund and money matters. State the amount, the method and the posting time, then the confirmation to expect. Money emails are reread and forwarded; precision here is a feature — the refund replies guide covers the variations including partial refunds.
7 · Delay notifications. The customer should hear about a delay from you before they notice it themselves: the reason in one clause, the new date, and the compensation if any. Full structures live in the shipping-delay guide.
8 · Chasing information. Restate what is blocked ("I can't rebook until the order number is confirmed"), make the ask binary and easy, and time-box politely: "if I don't hear back by Thursday I'll close this for now — reopening is one reply away."
9 · Reopening an old thread. Summarize the previous state in two lines from the desk's history before asking anything. Nothing frustrates long-term customers like re-explaining; nothing signals care like the summary proving you didn't need them to re-explain.
10 · Escalation to a human. When a thread passes to a senior teammate, the handoff email names the person ("my colleague Ana owns this now"), repeats the promise, and never makes the customer repeat the problem — the escalation matrix keeps this structured.
Write at the reading level of the customer's own messages, not above them; drop idioms when the customer is writing in a second language — and when the reply must cross a language, the desk's Copilot translates for 3 credits rather than leaving grammar to luck. Prefer "I" to "we" for actions and "we" for policies ("I've refunded this; our policy is 30 days"). Never scold, even when the customer is wrong — "quick note: that offer has expired, here's the current one" beats any correction that begins with "actually." And keep humor out of every template that touches money, delays or complaints: in writing, before a stranger, humor is a coin flip you don't need.
Templates are also a governance tool, and three habits make them work across people. House them in the desk as canned responses rather than a Google Doc, so the current version is one click away in the reply box — a doc drifts; a desk template updates in place for everyone. Fix the variable parts centrally: greeting style, sign-off, tense and the house "we're on it" phrase belong to the team, not to each agent's taste. Review monthly: delete templates unused for 60 days, and read the last ten sent replies against each surviving one — if agents rework half of every template before sending, the template is wrong, not the agents.
Shorter than you think, for one reason: every extra sentence competes with the next step for attention. Resolve-with-steps emails (structures 1 and 6) earn their length; everything else should survive the squint test — if the customer cannot find the ask or the answer in a five-second scan, cut. A useful discipline is one screen: no reply needs a scroll on a phone. And templates are measured the way the KPI guide measures everything — by outcomes per template: time to resolve threads started with it, reopened rate, and rework (edits agents make before sending). Two of those three numbers come free from the desk's history, which is one more reason templates belong in the queue rather than in a document.
One warning to end on: templates compound in both directions. Good ones make a two-person team answer like a disciplined ten-person team in its second year; bad ones make a ten-person team answer like a machine that has never read the ticket. The difference, every time, is whether the context line and next step were written for this customer — and that is a habit, not a document.
What makes an email template feel personal rather than automated?
Three things: a context line that proves you read the thread (order number, their exact problem), a next step with a named owner and time, and a steady sign-off. The reusable core can be templated as long as these identity-carrying parts are written fresh.
How many email templates does a small support team actually need?
Around ten structures: first reply (known and unknown problem), progress update, resolution, bad news, refunds, delay notification, chasing information, reopening an old thread and escalation handoff. Most volume fits these patterns with a personal layer on top.
Where should support templates live for a team?
In the help desk itself as canned responses, not in a shared document. Desk templates appear inside the reply box and update in place for everyone, so the team always sends the current version.
How do we stop five agents from sounding like five different companies?
Fix the variable parts team-wide: greeting style, sign-off, core phrases and tense. Review templates monthly, delete unused ones, and note that if agents rework half of every template before sending, the template itself needs fixing.
How can we write good support emails when the customer writes in another language?
Write plainly, avoid idioms, and use the desk's AI translation for the reply — on Onsites AI a translation costs 3 prepaid credits, so cross-language replies stay consistent without leaving the shared inbox.