How to Prompt AI to Write an Apology Email
The default output is polished and hollow. Banning four specific constructions and forcing the cause into the first line is what turns it into something usable.
Prompt AI to write a customer apology email and you will get something polished, warm, and completely hollow. "We sincerely apologise for any inconvenience this may have caused." Nobody has ever felt better after reading that sentence. The fix is not a better tone instruction. It is a lesson prompt engineering fundamentals teaches everywhere: ban the four specific constructions that produce corporate mush, and force the model to name what went wrong in the first line.
Here is the prompt, then why each rule is in it.
The prompt to write a customer apology email
Write an apology email to a customer.
What happened: [exactly what went wrong, in your own words]
Impact on them: [what it cost them, in time, money, or trust]
Cause: [the real reason, one sentence]
What we are doing: [the specific fix and when it lands]
What they get: [refund, credit, extension, or nothing]
Rules:
- First sentence states what went wrong. No greeting pleasantries
before it.
- Active voice throughout. "We deployed a bad change", never
"an issue was identified".
- Never "any inconvenience", "we apologise if", "unfortunately",
or "we value your business".
- Do not explain how hard we worked on the fix.
- Do not ask them to understand.
- If we are not offering compensation, say nothing about it rather
than explaining why not.
- Under 150 words.
- Sign off with a name and a direct way to reply.Why each rule earns its place
**First sentence states the problem.** The default output opens with a paragraph of throat-clearing before it admits anything. A customer who has been affected already knows something went wrong; making them read two sentences of warmth to find out whether you know too is its own small insult.
**Active voice.** "An issue was identified" is the grammatical structure of avoiding responsibility, and models produce it constantly because it is everywhere in the corporate writing they learned from. Forcing active voice forces a subject, and the subject is you.
**Banning "we apologise if".** The conditional turns an apology into a hypothetical. So does "any inconvenience", which shrinks a real cost into a vague one. These are not stylistic preferences. They are the specific words that make an apology read as legal cover.
**No "unfortunately".** It frames the failure as weather. Things you did are not misfortune.
**No account of your heroic response.** "Our team worked through the night" is a request for sympathy, addressed to the person you inconvenienced. Cut it.
**Silence on compensation you are not offering.** A paragraph explaining why they are not getting a refund is a paragraph reminding them that they are not getting a refund. If the answer is no, do not raise the subject.
The part the model cannot do
Everything above is craft. The substance has to come from you, and it is the cause line that people fudge.
If you write "an issue with our systems", the email will say "an issue with our systems", and the customer will read it as "we are not telling you". If you write "we shipped a change on Tuesday that broke checkout for anyone paying in euros, and our monitoring did not catch it for four hours", the email can be specific, and specificity is the entire mechanism by which apologies restore trust.
You do not have to include all of that detail in the final email. But the model cannot compress a detail you never gave it, and it will invent a plausible cause if you leave the field vague. That is the single most dangerous failure mode here: a fabricated technical explanation sent to a customer, in your name, which someone may later quote back to you.
Read every apology email before it goes out. This is not a category to automate end to end.
Adjusting for how bad it was
One prompt does not cover every failure. Three tiers, and the differences are structural rather than tonal.
Severity | Example | What changes in the prompt |
|---|---|---|
Minor | Slow support reply, small billing error | Two sentences. Fix stated. No compensation paragraph, no cause explanation. |
Real | Hours of downtime, data delayed, wrong charge | Full structure. Name the cause. Compensation if you have one. |
Serious | Data exposed, money lost, something they cannot undo | Do not send an email first. Call. The email follows the call and confirms in writing what you said. |
If the third row involves personal data, the email is not your first obligation either. In the UK the ICO sets out when a personal data breach must be reported and to whom, on a clock that starts before you have finished writing to anyone.
The third row is the one to internalise. An email as the first contact after a serious failure reads as hiding, no matter how well written it is. Use the email to document, not to break the news.
A worked example
Input to the model:
What happened: our booking system double-charged 62 customers on Saturday. Impact: money taken twice, some overdrafts. Cause: a retry loop in our payment code fired twice when the provider timed out. What we are doing: refunds already sent, retry logic fixed and deployed Sunday. What they get: full refund of the duplicate plus a £20 credit.
What comes back should read close to this:
On Saturday we charged you twice for your booking. That was our fault: our payment code retried a request that had already gone through, and it took us until Sunday morning to catch it.
>
The duplicate charge has been refunded and should appear in your account within three working days. If your bank charged you a fee because of it, reply to this email and we will cover that too. We have also added a £20 credit to your account.
>
The retry bug is fixed and deployed. Reply to this address if anything is still wrong and it comes straight to me.
Two hundred words of input, and the output is usable with a light edit. Compare that to what "write an apology email about a billing issue" produces, which is a template with your product name dropped into it.
Where this sits alongside other customer writing
Apology emails are one of a small set of high-stakes customer messages where the model is a drafting aid and never the sender. The same logic governs handling customer refund requests with AI and triaging support tickets: the model does the sorting and the first draft, a person does the judgement.
If your business has a defined voice, feed it in rather than describing it, using the approach in prompting AI to match your brand voice. Apology emails are exactly where an off-voice message is most noticeable, because the customer is already paying close attention.
And if you find yourself writing a lot of these, the message worth reading is not about your writing. Our notes on reducing churn on an AI subscription product cover the version of this problem that no email fixes.
FAQ
Should I tell the customer the technical cause?
Enough of it that the explanation is falsifiable. "A retry bug in our payment code" is specific and checkable. "A technical issue" is not, and customers have learned to read the vague version as evasion.
Is it dishonest to have AI draft an apology?
No more than having a colleague draft one. What matters is that a person with authority reads it, agrees with every claim in it, and signs it. The dishonesty would be sending a cause you did not verify.
How soon should the apology go out?
As soon as you know what happened, even if the fix is not finished. An email that says "this is broken, here is what we know, the fix lands Thursday" beats a complete account three days later.
Should I offer compensation every time?
No. Compensation for a minor inconvenience reads as buying someone off, and it trains customers to complain. Offer it when there was a real cost, and make it proportionate to that cost.
How did this land?
About the author
Developer Advocate
Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.
