How to Write Support Emails That Delight

Is delight actually the right goal?

Mostly no, and the industry's obsession with it produces longer emails than customers want. Someone who wrote to support is not looking for a relationship. They are looking to stop thinking about this and get back to their day. The kindest thing you can do is give them their afternoon back.

That reframing has a practical payoff, because "delight" cannot be optimised and thread length can. An email that resolves the issue in one exchange, with no ambiguity and nothing left to chase, produces the satisfaction scores that warmth was supposed to buy. Charm layered on top of a vague answer produces a polite customer who writes back twice more.

There is a narrow exception worth naming. When you have genuinely harmed someone, lost their data, charged them wrongly, broken a promise, tone carries real weight and brevity reads as indifference. Those emails deserve more words and more care. They are also perhaps one in fifty, which is exactly why most advice about warmth is calibrated to the wrong situation.

What is the one-reply test?

Write the draft. Then, before sending, write down the single most likely reply. Here is a worked example.

Draft: "Hi Sam, I have refunded the duplicate charge. It should appear shortly. Sorry for the trouble."

Predicted reply: "Thanks, how long is shortly, and will this happen again next month?"

Both of those questions were answerable at the moment of writing, and neither was answered, so you have guaranteed a second exchange and a second context switch for both of you. Revised: "Hi Sam, I have refunded the duplicate charge of $49. Your bank should show it within five business days. The duplicate happened because the subscription was upgraded twice on the same day; I have removed the second entry, so your next invoice on the 3rd will be a single charge of $49."

Same information, one exchange, and no invitation to worry. In our experience the predicted reply is obvious to the writer roughly nine times out of ten. The habit is not insight, it is remembering to look.

It also buys you a length budget you probably are not using. Analysing 16 billion emails from 2 million users, Kooti and colleagues found that half of all replies are shorter than 43 words and that "the most likely reply length is only five words", while "half of the replies are within 47 minutes of receiving the message" (WWW 2015). That is consumer email, not support email, so read it as a description of the habits your customer brings to your thread rather than a target. They are skimming, and they are answering fast.

What structure should every reply follow?

Five parts, in this order. The order matters more than the wording.

Answer. The resolution or the current status, in the first sentence. If you cannot resolve it yet, the first sentence says what happens next and when.

Specific acknowledgement. One line proving you read their message, referencing their actual situation. "Thank you for contacting support" proves nothing; "the export failed on your February report" proves you read it.

Steps, if the customer must act. Numbered, with real UI labels rather than descriptions of them. "Click your profile icon, top right" beats "navigate to your account settings".

The pre-empted follow-up. Whatever the one-reply test surfaced.

A specific close. Not "let us know if you have questions", which is filler nobody reads. Give a concrete next move: "If it fails again after clearing the cache, reply here and I will pull the report manually."

Which phrases should you delete from every template?

Corporate padding is not merely stylistic. Each of these phrases either dodges responsibility or adds length without adding information, and customers have learned to read past them.

The last row is the one that surprises people. Removing "unfortunately" makes refusals shorter and, oddly, warmer, because the sentence stops apologising for itself and starts explaining.

Templates for the everyday cases

Treat these as scaffolding. Every bracket is a place where a human has to do actual work.

Bug report acknowledgement. "Thanks for reporting this, [Name]. I reproduced it on my account: [exactly what you saw]. It is now with engineering as [ticket reference]. I will update you here by [specific date] whether or not it is fixed by then. In the meantime this workaround should unblock you: [steps]."

The improvement over the usual version is the promise to update on a fixed date even without news. Silence after "we are on it" generates more chase emails than any other pattern in support.

Feature request. "That is a reasonable ask, [Name], and we do not have it today. I have logged it with your use case attached, because the detail about [their specific workflow] is the part product actually needs. I am not going to promise a timeline I cannot keep. Here is how other customers handle it now: [workaround]."

Billing correction. "I see the charge, [Name], and it is wrong. Here is what happened: [one sentence]. I have issued a [refund or credit] of [amount], which should appear by [date]. You do not need to do anything. If it has not landed by [date], reply here and I will chase it."

Escalation to engineering. "[Name], this is a bug rather than a configuration issue, so I have handed it to engineering with your logs, [specific details] and your account ID. I own this thread, so you do not need to follow up separately. I will write to you on [day] with either a fix or a status."

Templates for the emails nobody publishes

These are the ones that decide whether your support is respected, and almost every article on this topic skips them.

Refusing a refund outside policy. "[Name], I am not able to refund this one. Our refund window is thirty days and this charge is from [date]. I know that is not the answer you wanted. What I can do is [cancel the renewal now / move you to the lower plan / apply a credit toward next term], so you are not paying for time you will not use. Tell me which you would prefer and I will action it today."

Decision first, reason once, and one concrete alternative. Do not repeat the policy, do not use "unfortunately", and do not offer to check with a manager unless you intend to.

Missing a deadline you promised. "[Name], I told you this would be fixed by Thursday and it is not. That is on me. The current position is [honest status]. My new estimate is [date], and I have set a reminder to write to you on [earlier date] regardless of whether it is done. If this timeline breaks something on your side, tell me and I will look at [specific mitigation]."

Telling a customer it will not be fixed. "[Name], I have an answer and it is not the one I wanted. We have decided not to change [behaviour], because [genuine reason]. That is a firm decision rather than a backlog item, so I would rather tell you plainly than let you wait on it. The closest workaround is [X]. If that does not work for how you use [product], I am happy to talk through whether we are still the right fit."

That last sentence is uncomfortable and worth keeping. Telling a customer you might not suit them buys more trust than any amount of positive framing, and it saves both parties a slow, resentful churn.

Data you cannot recover. "[Name], I have checked with engineering and the [items] deleted on [date] are not recoverable. Backups cover [scope], and this fell outside that. I am sorry, that is genuinely bad. Here is what I can do: [any partial restoration], and here is how to prevent it recurring: [specific setting]. If this has created real work for you, tell me and I will see what we can do on the account."

How do you say no without inviting an argument?

Structure does most of the work. State the decision in the first sentence, give the reason exactly once, offer the single best alternative you actually have, and stop. The pattern that generates arguments is hedged refusal: two paragraphs of sympathy, a buried "however", and a policy reference that reads as an invitation to negotiate.

Never soften with "I will see what I can do" when you have already decided. It sets up a second disappointment, and the second one costs more than the first would have.

If your answer genuinely depends on someone else, say who and when. "I need approval from our billing lead and I will have it by Thursday" is a real answer. "Let me check with the team" is not.

Should AI write your support emails?

For drafts, often yes. For sending, be specific about where it stops. The awkward truth is that AI drafts are strongest on exactly the emails that were easy to write anyway, the how-to answers and the routine confirmations, and weakest on the ones this article spends most of its length on. A model drafting a refund refusal will produce something fluent, over-apologetic and full of the phrases in the table above.

The practical line we draw: never let a draft send unread on refunds, outages, angry customers, or anything involving data loss. Those threads need a deliberate handoff to a person rather than a confidence score deciding for you. Corebee generates drafts an agent edits before sending, which suits the routine half and stays out of the way on the rest.

There is a second-order risk worth naming. Teams that adopt drafting tools sometimes see their emails converge on one voice, which is fine, and one length, which is not. Watch for replies getting longer, because models pad. The one-reply test still applies, and it applies to the model's output more than to yours.

How do you measure whether an email was good?

Three signals, in order of usefulness. Replies per resolved conversation, which is the closest proxy to the one-reply test at scale. Reopen rate within seven days, which catches answers that looked complete but were not. And reading a random sample aloud each week, which catches everything the numbers miss.

Be careful with satisfaction surveys at low volume. Thirty responses a week will swing several points on noise alone, and chasing that movement produces meetings rather than improvements. Look at quarters, or look at the free-text comments instead of the score.

For team coaching, a weekly review of a handful of real threads works better than any style guide, provided you review the hard ones. Reviewing easy tickets teaches nothing, because nobody writes a bad email about a password reset.

Where this breaks

If your agents write in a language they do not speak natively, template quality is not your bottleneck and this advice will not help much. Invest in fewer, better-localised templates and give people permission to be brief.

Regulated notices are not support emails. Breach notifications, statutory disclosures and anything with a legal deadline belong to legal, and you should not be templating them in your help desk.

And there is a whole category where the correct email is two lines plus a refund. When the customer is right, the fastest possible resolution beats the best-written explanation. Craft applied to a message that should have been a refund reads as stalling.

What should you do this week?

Pick your five highest-volume reply types and rewrite them with the answer moved to the first line. Then pick the three hardest conversations from last month, refusals, missed commitments, bad news, and write templates for those, because those are the ones your team is currently improvising under pressure.

Run the one-reply test on every outbound message for a week and count how often you catch something. Most people are surprised. Finally, delete the phrases in the table from every saved reply you own; it takes twenty minutes and it is the highest-return edit available. If you want the drafting side handled while you keep control of the hard messages, you can start a free trial and see how the drafts land against your own threads.