Customer Status-Update Broadcaster: Calm, Consistent Incident Comms

The problem this kills

It's the middle of an outage. Something is down, customers are noticing, and the people who could be fixing it are instead staring at a blank email trying to find the right calm, honest words — for the third time in an hour. The first update went out worded one way, the second contradicted it slightly, and now nobody's sure what you've already told customers. Someone over-promises a fix time. Someone else accidentally sends to the wrong list. By the time it's resolved, the incident itself was stressful, but the communication was chaos.

Customers don't expect you to be perfect during an outage. They expect to be told what's happening, in plain language, without spin or silence. That means a steady drumbeat of staged updates — "we're investigating," "we've identified it," "we're monitoring the fix," "it's resolved" — each consistent with the last, each timestamped, none of them written from scratch while the building is on fire. You do not need to be a developer to build the tool that makes that easy.

What you'll build

A simple internal web tool for your support and incident team. When something breaks, you open an incident and pick the affected-customer list. For each stage — investigating, identified, monitoring, resolved — the tool drafts the update for you in your established house voice: calm, specific, and non-speculative. The incident lead reviews and edits the exact wording, then approves. Only then does Resend send it to the affected customers, and the update lands timestamped on the incident timeline so everyone can see exactly what was said and when. You repeat per stage until the incident is resolved. Nothing is ever auto-sent mid-crisis, and the same stage can't go out twice by accident. The whole incident — every update plus who received it — exports as CSV for your records.

What's inside the Implementation Plan

The downloadable plan is a step-by-step file you paste into an AI coding agent. It opens by interviewing you about your business — how you run incidents today, which channels and lists you use, the stages and severity levels you actually have, your house voice and any wording you must never use, your typical and peak incident volumes, and your real approval rules. It reads a short spec back to you for a thumbs-up, then builds the tool around your answers instead of a generic template. From there it walks the agent through the data model, importing the affected-customer list, the AI drafting per stage, the review-and-approve gate, the Resend send, the self-building timeline, and the CSV exports. Every step ends with a ready-to-copy prompt.

The governance it includes (this is the point)

This isn't a toy. The plan builds in the controls a real support function needs during its most sensitive moments: login so only your team can use it, row-level security so people only see their own organization's incidents and customer lists, a complete audit trail of every draft, edit, approval, and send (who, what, when), a hard human-approval gate so no update ever reaches customers until the incident lead signs off on the exact words, and duplicate guards keyed to incident ID plus stage so the same stage update can never be blasted out twice. The AI drafts; a person decides; nothing auto-sends in a crisis.

Who it's for

Incident managers, support leads, and on-call communicators who own customer comms during outages and are tired of writing emails from scratch while everything's broken. If you can describe how you talk to customers during an incident, you can build this.

You've got this — open the plan, paste the first prompt, and you'll be drafting your first staged incident update this weekend.