Reply to a customer email

A reply that acknowledges the real problem before offering the fix — and apologises exactly once.

When to use it

Support or account replies where the customer is upset and the wrong tone makes it worse — a real fix wrapped in the right acknowledgement.

What it prevents

The corporate non-apology. Without direction, models produce a reply that apologises three times, promises the world, and never states the actual fix. The instruction to acknowledge once and lead with the concrete step is what turns it into a message that helps.

The prompt

Draft a reply to the customer email below.

### Audience
A paying customer whose export failed before a deadline. They are stressed, not hostile.

### Context
The bug was real and is now fixed. We cannot recover the export they lost, but they can re-run it in under a minute.

### Requirements
- Length: Under 120 words.
- Output format: A greeting, two short paragraphs, and a sign-off.
- Acknowledge the specific failure before offering the fix.
- Give the exact steps to re-run the export.
- Avoid: apologising more than once, corporate filler, and promising it will never recur.

### Example of the wanted output
Hi Dana — you are right, the export failed the day before your meeting, and that is on us.

### Email
"""
Your export tool ate an hour of my work the day before a board meeting. Fix this.
"""

Why each part is there

Every section of that prompt exists because a specific failure happens without it. These are the checks it passes, and what each one is protecting you from:

• States a concrete task — why this matters
• Avoids vague language — why this matters
• Specifies an output format — why this matters
• Gives context or audience — why this matters
• Avoids dangling references — why this matters
• Includes an example — why this matters
• Separates data from instructions — why this matters
• Avoids over-aggressive phrasing — why this matters
• Defines what a good answer looks like — why this matters

How to adapt this one

Swap the situation and be honest about what you can and cannot do — the model can only be straight with the customer if you are straight with it. Keep the length cap and the “apologise once” rule; over-apologising reads as either insincere or panicked. And keep the instruction to name the specific failure, because a generic “sorry for any inconvenience” tells the customer you did not read their message.

The mistake this prompt avoids

Letting the model over-promise. A model optimising to please will happily pledge that this will never happen again — a commitment you cannot keep and should not make. Tell it what is actually true: the bug is fixed, here is the workaround, here is what we are watching. Specifics rebuild trust; promises spend it.

A variation

Handling a complaint you cannot resolve in the customer's favour? Drop the “offer the fix” framing and ask for a reply that explains the decision, the reason, and the one thing they can still do — a clear no beats a warm maybe. The hardest support emails are the ones with no good news, and those need more structure, not less.

Check your version

Once you have adapted it, run it through the checker. The same nine checks that graded this page will grade yours, free and in your browser — paste it in, or build one from scratch by answering a few questions.