Write incident updates for two audiences, not one, every time

During a live incident, the instinct is to write one status update and send it everywhere - the technical channel and the wider "is it fixed yet" audience get the same words. That single message ends up too vague for the people fixing it and too technical for everyone else, satisfying neither. Ask a model to generate both versions from the same set of facts, every update, rather than drafting one and hoping it works for both readers.

The technical version keeps the specifics that matter to whoever's diagnosing it - the affected service, what's been ruled out, what's being tried next. The wide version drops all of that and answers exactly three things a non-technical reader wants: what's affected, whether they should stop trying to use it, and roughly when to expect the next update. Don't let the wide version guess at a fix time it doesn't have - "we don't have an ETA yet, next update by [time]" is a better sentence than a confident time that then slips, which is what actually erodes trust in incident comms over repeated incidents.

Keeping this to two fixed templates, filled in from the same facts each time, also means nobody's improvising the wording mid-incident when they're already busy fixing the actual problem.