An incident message
Status page and email copy for when everything is down and something has to be said.
Treść promptu
You are a support lead who writes incident messages that keep customers from leaving. What broke: {feature or service} Who is affected: {everyone / some / certain plans} Started at: {time} What is known about the cause: {or "investigating"} Expected fix: {estimate or "unknown"} Is data at risk: {yes / no / investigating} Write three texts: 1. The first message, within 15 minutes: what is down, who it touches, when the next update comes. You do not need the cause — you need to show you can see it. 2. A progress update: what has been done, what is left. No technical detail that means nothing to a customer. 3. The closing message: what it was, what was fixed, what will stop it recurring. Plus: 4. What to say when you do not know the timing. You cannot lie and you cannot go quiet — how to phrase it. 5. A dedicated line about data: it is the first question people have, even when they do not write it. 6. Five phrasings never to use — the ones that make customers angrier. 7. Who to message personally rather than leaving it on the status page. Write like a person, not like a legal department. "We apologise for any inconvenience caused" is not an apology.
To, co w nawiasach klamrowych, zamieniasz na swoje.
Przykładowy wynik
First: "Since 14:20 reports will not open. Everything else is working. We are on it; next update at 14:50. Your data is intact, nothing has been lost." No ETA: "We cannot give a time yet. The moment we understand the cause we will. Updates every 30 minutes, even when there is no news." Never: "scheduled maintenance" during an unplanned outage, "some users" during a total one, "all clear" before anyone verified it.
Podobne prompty
Your idea broken down into risks plus a one-week test plan — before you spend months.
You are a product strategist who has seen plenty of projects die. Assess my SaaS idea honestly, without cheering me on. Idea: {what the service does} For whom: {who, as narrowly as possible} What the person does today without us: {how the job gets done now} How I plan to charge: {model and price} Time and money I can spend before first revenue: {resources} Break it down: 1. The problem: does it hurt regularly, or is it a one-off inconvenience? Answer plainly. 2. Who pays: the user themselves or their manager — and why that changes the product. 3. The three main risks: why this could fail. For each — the cheapest way to test it. 4. What already exists on the market, including a spreadsheet, a notebook and "do nothing" — count those as competitors too. 5. The most dangerous assumption: the one that makes everything else pointless if it's wrong. 6. A one-week test plan: what to do on which day to get a signal without writing code. 7. The kill criterion: what result means the idea should be dropped. If the idea is weak, say so in the first paragraph.
Pokaż przykładowy wynikUkryj przykład
Most dangerous assumption: that the bookkeeper is allowed to change tools. The finance director decides, not them — so you sell "fewer reporting errors", not "more convenient". Kill criterion: if fewer than 3 out of 20 conversations end in "let me try it", drop the idea.
The smallest set of features you can already sell, plus what's deferred and why.
Help me draw the boundary of an MVP that can actually be shipped and sold. Product: {what the service does} The main scenario: {what the user does from login to result} Who the user is: {description} Time available for development: {timeframe} Who is building it: {one developer / a team / no-code} Do this: 1. One user path from sign-up to first value — step by step, no branches. 2. The features without which that path doesn't work. Each with a reason why it can't be dropped. 3. Features that feel mandatory but aren't needed in an MVP — and what replaces them for now (manual work, an email, a spreadsheet). 4. What to cut entirely, and why it won't stop you selling. 5. The boundaries: what the product does NOT do. Wordings for the site so nobody expects otherwise. 6. An estimate in weeks, broken down, with a note on where the estimate is least reliable. 7. What can be done by hand for the first few months instead of being automated. Rule: if a feature can be replaced by a human at launch, it does not belong in the MVP.
Pokaż przykładowy wynikUkryj przykład
Do it by hand: PDF export is done by support on request for the first months. Three requests a week is one hour; automating it would have cost two weeks. Boundary for the site: "We don't replace your accountant — we prepare the data for them."
A feature turned into tasks with testable criteria — including errors and empty states.
Ten prompt należy do zestawu PRO
Odblokuj dostępTables, relations and indexes derived from your scenarios — plus where the schema will strain.
Ten prompt należy do zestawu PRO
Odblokuj dostęp