Why it is written this way
The most common flaw in AI-generated apology emails is repeating "we are deeply sorry" five times while failing to clearly explain what went wrong and what will happen next. It is easy to confuse excessive apologies with sincerity, but what clients actually need are the facts and immediate next steps. This prompt restricts repetitive apologies to guarantee space for factual explanations and concrete action plans.
Setting the Role to "Head of Customer Support" in the first paragraph anchors the perspective. Without a defined role, models tend to write like PR representatives—polishing the tone while removing accountability. The Task sequence (Facts → Apology → Actions Taken → Prevention) is explicitly enforced because standard AI outputs often scramble this order.
The critical element in the Constraints section is the placeholder mechanism: [To be confirmed]. When prompted without compensation or refund terms, models tend to invent plausible terms. Unauthorized compensation promises in an official email create serious liability risks. Offering an explicit placeholder tag encourages the model to leave those fields open cleanly.
The final paragraph instructs the model to self-evaluate its draft against key criteria before outputting the final version, filtering out missed actions or subtle excuses. Wrapping the issue description in """ delimiters ensures customer inquiry text is treated as reference data rather than prompt instructions.
Unfamiliar terms? See Aha AI: role-prompting, hallucination
Compared with a bad example
Write an apology email to a customer. We had a service outage yesterday.
(paste customer support ticket screenshot)
With only one line of context, the model hallucinates the outage duration, scope of impact, and recovery steps. Sending such a draft risks delivering inaccurate information to the client, escalating the issue. Without an action response plan, the email defaults to empty promises like "We will do our best to prevent recurrence," providing the customer with zero tangible reassurance.
Variations
Initial Notice When Root Cause Is Unknown
You are a Head of Customer Support. Write an initial update email to {{other party}}. The root cause is still under investigation and cannot be disclosed yet.
Clearly distinguish between what is currently confirmed and what remains unconfirmed, without speculating on the cause. Commit to a specific timeframe for the next update in one sentence, and provide any temporary workarounds the customer can use in the meantime. Keep the body under 150 words.
occurred problem: """ {{occurred problem}} """
Drafting an apology before identifying the root cause often introduces misleading speculation. This variation focuses strictly on confirming known facts and establishing a clear follow-up timeline.
Internal Incident Summary Report
Please summarize the incident below as an internal post-incident report. Omit all apology phrasing and focus solely on factual details.
Structure the summary into five sections: Incident Time & Duration, Scope of Impact, Root Cause ({{root cause}}), Action Taken & Next Steps ({{action response plan}}), and Remaining Risks. Mark any missing details as "Needs Verification."
occurred problem: """ {{occurred problem}} """
Internal reporting requires concise, actionable facts rather than apologetic language. Structuring the report into fixed categories makes it immediately usable for post-mortem meetings.
Related prompts
Last updated 2026-09-02 · Found a mistake? Let us know