Support replies
Refunds, bugs, complaints and apologies. Filter by role or search for the kind of ticket in front of you.
10 templates · free · no sign-up
I'm a…
Speed matters more than completeness. Acknowledge, then dig in.
Subject: Re: [their subject]
Hi [Name], Thanks for writing in — I've picked this up. Let me make sure I've understood: [restate their problem in your own words]. I'm looking into it now and will come back to you by [realistic time]. If anything changes before then I'll let you know. [Your name]
Say it's real, say it's yours, say what happens next.
Subject: Re: [their subject]
Hi [Name], You're right, and thank you for the clear report — I've reproduced it here. It's now with our engineers as [ticket reference]. I don't have a fix date yet, but I'll update you [when] whether or not there's news. In the meantime, [workaround, if there is one]. Sorry for the trouble. [Your name]
If you're saying yes, say it in the first line. Don't make them read for it.
Subject: Refund processed
Hi [Name], I've refunded [amount] — it'll be back on your [payment method] within [x] working days. Sorry it didn't work out. If you'd be willing to tell me what went wrong, I'd genuinely like to know; it's how we fix things. [Your name]
Give the reason plainly, then offer whatever you actually can.
Subject: Re: refund request
Hi [Name], I've looked into this properly, and I'm not able to refund [purchase] — [clear reason, referencing the policy]. I know that isn't the answer you wanted. What I can do is [alternative: credit, extension, plan change, hands-on help]. If you'd like me to escalate it, say so and I'll pass it to [team]. [Your name]
Don't match their temperature. Acknowledge, own, fix.
Subject: Re: [their subject]
Hi [Name], You're right to be annoyed — [restate what went wrong, without excuses]. Here's what I'm doing about it: [action], by [time]. Here's what we're doing so it doesn't recur: [change]. I'm handling this personally. If it stalls, reply here and it comes straight back to me. [Your name]
Early and vague beats late and detailed.
Subject: [Product] — service disruption
Hi [Name], [Product] is currently [what's broken], affecting [who]. It started at [time]. We know what's causing it and we're working on it now. Live updates: [status page link]. Next update from me by [time], even if there's nothing new to say. Sorry for the disruption. [Your name]
A clear no is kinder than a vague 'on the roadmap'.
Subject: Re: [feature]
Hi [Name], Thanks for suggesting [feature] — it's a fair idea and I've logged it. Being straight with you: it isn't something we plan to build soon. Our focus for the next [period] is [priority], and this doesn't fit alongside it. The nearest thing today is [workaround]. Happy to set it up with you if that helps. [Your name]
Never imply they imagined it. Ask for what you need.
Subject: Re: [their subject]
Hi [Name], I've tried to recreate this on my side and haven't managed it yet — which usually means something specific to your setup, and that's useful to know. Could you tell me: • What you clicked just before it happened • Which browser or device • A screenshot, if it happens again With those I should be able to pin it down quickly. [Your name]
Confirm the fix, leave the door open.
Subject: Re: [their subject]
Hi [Name], [What was wrong] is now fixed — [what you did]. Could you confirm it's behaving at your end? I'll leave this open for a couple of days in case anything resurfaces. After that it closes automatically, but replying here reopens it any time. [Your name]
When the apology needs to cost you something to land.
Subject: Sorry about [what happened]
Hi [Name], [What happened] shouldn't have happened, and I'm sorry — particularly because [acknowledge the actual consequence for them]. I've [gesture: credited your account / extended your plan / refunded the month]. It doesn't undo the disruption, but it's the honest thing to do. [What we've changed] so it doesn't happen again. [Your name]
Nothing matches that
Try a plainer word, or clear the filters above.
Support replies that open with policy background and reach the decision in paragraph three read as reluctant, even when the outcome is generous. The customer has one question and it should be answered in the first line.
This is most obvious with refunds. Leading with the refund and the timescale means everything after it is read in a better mood. Leading with the policy means the customer starts composing an angry reply while still hunting for the answer. The same principle applies to bugs, outages and feature requests: decision first, reasoning second.
A holding reply within an hour beats a perfect answer tomorrow. Silence is what converts a problem into a complaint, because the customer starts to suspect nobody is looking.
The first response should confirm you have read it, restate the problem in your own words so they can correct you, and give a realistic time for the real answer. Then meet that time, including when there is nothing new. The restatement earns its place by catching misunderstandings before you spend an afternoon investigating the wrong thing.
When someone writes in furious the instinct is to defend. Acknowledge the specific thing that went wrong first, in your own words, so they can see you understood rather than deflected.
Naming the actual consequence matters more than the apology. Sorry for the inconvenience is filler; sorry that this meant your invoices went out three days late shows you read what they wrote. Offering a named point of contact de-escalates more reliably than any wording, because much of the anger in support is about feeling processed rather than about the original fault.
Declining a refund or a feature request is unpleasant, so it tends to get buried in hedging that leaves the customer unsure what was decided. That produces a second, angrier message.
State the decision, give the real reason, then offer whatever you genuinely can. An honest no with a workable alternative is respected far more often than people expect. What is not respected is a refusal attributed vaguely to another team, or a feature request thanked for and quietly buried, which everyone recognises as a no that was too awkward to say.
Agents under pressure promise fix dates they cannot control, and a missed fix date does more damage than an honest lack of one.
Say the report is real, say it is with engineering, give a reference, and commit to an update on a specific date whether or not there is news. That is a promise you can keep. During an outage, early and vague beats late and detailed: what is broken, who is affected, when it started, and when the next update lands. Hitting that update time is the most reassuring thing you can do mid-incident.
Templates exist so the structure is already decided and the agent's attention can go to the specifics. They stop working the moment they are sent unedited, because customers recognise boilerplate instantly.
Keep the skeleton and rewrite the first and last lines: the opening should reference their actual situation and the closing should say what happens next in this specific case. That captures most of the speed benefit with almost none of the coldness. Reading your most-used templates aloud occasionally is worth doing, since phrases that felt fine written often sound stiff when spoken.
