Public apology statement prompt

When to use it

Use this when you need a customer-facing apology and want a concrete starting point rather than generic advice. Replace the fictional details with your own confirmed facts before using the result in a real setting.

The prompt

## Role
Act as a accountable public communications editor. Apply professional judgment while keeping your reasoning understandable to someone who is not a specialist.

## Context
Elm Table, a fictional meal delivery company, sent 74 orders a day late after an internal routing error. Customers were notified only after the promised delivery window. No food safety incident has been reported. Refunds for delivery charges have been approved, but their processing timeline has not yet been confirmed.

## Objective
Draft an apology that clearly owns the failure and explains the approved remedy without overstating what is known.

## Audience
The primary users are service business owners. Make the deliverable usable in their day-to-day work, with enough explanation to support decisions but no unnecessary background lecture.

## Requirements
Provide a 250–350-word customer email, a 70-word public statement, and an internal fact-check checklist. Acknowledge both the delay and late communication. State that the refund timeline will be shared once confirmed. Separate an immediate remedy from proposed process changes requiring approval. Identify operational facts that need sign-off before sending, and suggest a concrete owner for the next customer update without inventing a name.

## Constraints
Do not blame a vendor, claim that nobody was harmed, disclose customer information, or promise this can never happen again. Do not add unapproved credits or refund dates. Work only with the scenario and any material explicitly supplied. Label assumptions and distinguish proposed actions from confirmed facts.

## Tone & style
Be direct, thoughtful, and specific. Prefer plain English, concrete examples, and short paragraphs. Match the language to the intended reader rather than relying on jargon or generic motivational phrasing.

## Output format
Present the requested deliverable first, using descriptive headings and tables only where they improve usability. Keep supporting notes separate from copy intended for publication or direct use. Finish with a short checklist of outstanding decisions or verification steps.

## What to avoid
Avoid filler, unsupported certainty, and details invented to make the result seem more complete. Do not let a polished presentation conceal missing information or conflicting requirements.

## Success criteria
A customer can understand what happened, what the company accepts responsibility for, and what information is still forthcoming. Check the result against the stated constraints before presenting it and correct any inconsistencies you find.

## Clarifying questions
Ask up to three focused questions only if missing information would materially change the result. Otherwise proceed with the fictional scenario, state any necessary assumptions briefly, and identify what a real user should confirm before relying on the output.

Why it works

• The scenario gives the model concrete facts and boundaries instead of asking it to invent a brief.
• The requirements specify the actual deliverables and the important edge cases for this task.
• The constraints make unsupported claims and unapproved commitments harder to slip into the result.
• The success criteria turn review into a practical check: a customer can understand what happened, what the company accepts responsibility for, and what information is still forthcoming.

Make it yours

Build a tailored version with PromptDeck by replacing the fictional scenario with your own context, audience, and constraints. Keep the verification steps so the final result reflects what you actually know.