Apology Statement
Draft a public apology or incident statement that takes responsibility, states facts and remedies, and avoids the phrases that make it worse.
Draft a public statement about what happened. What happened, factually: [THE EVENT. Plain facts only, including what you got wrong.] Who was harmed and how: [AFFECTED PEOPLE + CONCRETE IMPACT] What we know for certain: [CONFIRMED FACTS] What we do not know yet: [OPEN QUESTIONS] What we have already done: [ACTIONS TAKEN, WITH DATES] What we will do, and by when: [COMMITMENTS + DATES. Only ones we will actually meet.] Who is speaking: [COMPANY / NAMED EXECUTIVE] Channel: [e.g. "email to affected customers" / "post on our site" / "statement to press"] Structure the statement in this order: 1. What happened, in the first sentence, in the words an affected person would use. 2. Who it affected and how. Be specific about scope: numbers and dates if we have them. 3. Responsibility, stated plainly and without conditions. 4. What we have done already. 5. What we will do, with dates. 6. What we do not know yet and when we will update. 7. How to reach a human about it. Rules: - No "we apologize for any inconvenience", no "mistakes were made", no "we take X very seriously", no "out of an abundance of caution". These phrases are read as evasion because they usually are. - Never claim to be sorry that people "feel" a certain way. Apologize for the thing that was done. - Do not explain the cause before acknowledging the harm. Context that arrives first reads as excuse-making. - Claim only what my facts support. If a commitment above is not backed by a decision that has actually been made, flag it [NOT COMMITTED] instead of publishing it. - Length: as short as the facts allow. A short statement that answers the obvious questions beats a long one that dodges them. Return the statement, then a list of the three hardest follow-up questions this will provoke and the honest answer to each.
How to use
The banned-phrase list is the practical core: every one of those phrases exists to sound apologetic without accepting responsibility, and audiences decoded them years ago. The follow-up questions section is what makes this worth running before a legal review rather than after, since it surfaces the commitments you cannot keep while they are still editable. Never publish a date in section 5 that someone has not actually agreed to own.
More writing prompts
Rewrite the text below in plain language for [AUDIENCE, e.g. "patients with no medical background" / "customers reading a policy update" / "new hires on day one"]. Target reading level: [e.g. "8th grade" / "as simple as the content allows"]. How to rewrite: - Lead with what the reader must DO or what happens to them. Background comes af
Plain Language Rewrite
Rewrite dense policy, legal, medical, or technical text at a target reading level without losing a single obligation or number.
Write a comparison article for the query: [e.g. "Notion vs Obsidian" / "best Mailchimp alternatives"]. Options to compare: [LIST 2-8 OPTIONS] Who is searching this: [READER + WHAT THEY ARE TRYING TO DECIDE] My relationship to these products: [e.g. "I make one of them" / "I use two of them daily" / "none, I am researching"] Facts I can su
Comparison Article
Write an honest X vs Y or best alternatives article: real differentiators, a decision table, and a clear pick for each type of reader.
Build an FAQ page for [PRODUCT/SERVICE/TOPIC]. Real questions people ask me: """ [PASTE SUPPORT TICKETS, SALES CALL NOTES, SEARCH QUERIES, OR COMMENTS. RAW IS FINE.] """ Facts I can state as true: [PRICING, POLICIES, LIMITS, TIMELINES] Do this: 1. **Cluster** the raw questions into distinct questions people actually ask. Merge duplicat
FAQ Page From Real Questions
Turn support tickets and sales objections into an FAQ page that answers in the first sentence and is structured for AI search engines.