How to send proactive service outage notices with an AI agent

Start the notice from a declared incident, never from an alert. The agent drafts the notice from the incident record, works out which customers are affected from your service map, and prepares the send. The incident communications lead approves the first notice and any change in scope. Routine "still working on it" updates then go out at depth 3 on approved wording.

What is the process, and who owns it?

A proactive outage notice tells affected customers about a problem before they find it themselves: what is not working, who is affected, what they can do meanwhile, and when they will hear next. Sent well, it prevents a flood of contacts and keeps trust. Sent badly, to the wrong people or with a guess about the cause, it creates a second incident.

The incident manager owns the incident and its status. The incident communications lead owns every customer-facing word. Support owns the inbound side, which is covered in handling contact spikes during a service outage. Name all three before the next incident, not during it. The wider support position is in the AI support agent that knows when to say no.

What does the agent prepare, step by step?

1. Agent, depth 1: reads the declared incident. Affected services, regions, start time, current status, next review time. The incident record is a sealed source; monitoring alerts and social posts are not.
2. Agent, depth 1: identifies affected customers. From your service map: which customers use the affected service, in the affected region, on the affected product. It produces a count and a list, not a guess.
3. Agent, depth 1: checks contact rules. Which channel each customer has agreed to for service messages, quiet hours, and accessibility needs such as large print or a preferred language.
4. Agent, depth 2: drafts the first notice from an approved template: what is affected, in plain words; who is affected; what to do meanwhile; when the next update will come. No cause, no fix time unless the incident manager has stated one.
5. Person, incident communications lead: approves the first send. Checks the wording, the audience count and the channel.
6. Agent, depth 3: sends the approved notice and posts the same words to your status page or help centre.
7. Agent, depth 3: sends routine updates at the promised times, on an approved "still in progress, next update at" template, as long as scope has not changed.
8. Person, communications lead: approves any change. New services or regions, a stated cause, a fix time, and the resolution notice.

What does a named person approve, and why?

The first send, because it is the hardest to undo. Once thousands of customers have a message, a correction is a second message, and the correction becomes the story. The communications lead checks three things in a minute: is the wording accurate, is the audience right, is the channel right.

Every scope change, for the same reason. And the resolution notice, because "fixed" is a claim the incident manager must confirm. Customers who are told a service is working and then find it is not will not believe the next notice.

Compensation is never in an outage notice unless a person has decided it. A sentence like "we'll make it right" reads as a promise. Whether and how an agent may compensate is a separate question, covered in can an AI agent compensate a customer for a service outage.

Which controls matter, and what evidence do they leave?

Declared incident as the only trigger. Evidence: the incident identifier on every notice.

Audience from the service map, counted before send. Evidence: the count and the query used, approved with the first notice.

Template wording only. Evidence: template and version on each send.

Update promises kept. If the notice says "next update at three o'clock", the agent sends one at three, even if nothing has changed. Evidence: promised time against actual time.

Service messages, not marketing. Outage notices go only through channels customers accepted for service messages, and they carry no offers. Evidence: the channel rule applied per customer.

Where does it usually go wrong?

Alerts trigger notices. A monitoring blip becomes a customer message, then the alert clears. Only declared incidents count.

The audience is too wide. Everyone gets the notice "to be safe", and unaffected customers start contacting you to ask whether they are affected. Use the service map.

The cause is guessed. An early draft says "due to a third-party problem", which turns out to be wrong. Leave cause out until the incident manager states it.

The status page and the messages disagree. Customers compare them. Post the same words to both.

Promised updates are missed. Silence after a promise is worse than no promise. Missed updates are the most common complaint after an outage.

Notices go out at night. Quiet hours apply unless the outage itself is urgent for customers, such as a payment failure before a deadline. Decide that rule in advance.

What should you measure?

• Time from incident declared to first notice sent.
• Contacts from notified customers, against those not notified. A good notice lowers the first.
• Notices sent to unaffected customers, found by checking the service map afterwards.
• Promised updates on time.
• Corrections sent. Should be rare.

Outage notices are part of service recovery, explained in what is service recovery. A clear notice that says what you cannot yet promise is part of good service, a point made in a refusal with a reason is good service.

Where Pryme fits

In Pryme, the first notice and any change of scope are held for the incident communications lead, while routine updates on approved wording can be certified at depth 3. The incident record arrives as sealed, so a monitoring alert or a social post alone cannot start a send.