When a broadband network goes down, contact volumes spike because nearly every affected customer asks the same two questions: is it just me, and when will it be back. The way to handle the spike is to answer those questions before the customer has to queue for them, by telling affected customers first, giving honest updates, and taking fault reports without a wait.
That sounds obvious. Most operators still do the opposite, because the systems that know about the outage and the systems that talk to customers are not connected.
What happens to contact volumes in an outage
An outage does not produce a gentle rise. It produces a wall, usually within minutes of the fault, from every channel at once: calls, chats, WhatsApp, emails and social posts. Then a second wave when the first ETA passes, and a third when service comes back for some customers and not others.
Look at what those contacts actually say and the pattern is narrow. Is there a fault in my area. When will it be fixed. Do I need to do anything. Will I be compensated. Very few of them need a person to investigate anything, because the operator already knows the answer. It just has not reached the customer.
Why the queue is the real damage
The outage is the network's fault. The queue is the customer service operation's fault, and customers judge it more harshly.
Someone who loses their broadband for four hours will usually accept that faults happen. Someone who spends forty minutes on hold to be told "yes, there is a known issue in your area" remembers the forty minutes. That is the contact that turns into a complaint, a bad review, or the reason they go when the contract ends.
The queue also blocks everyone else. The customer with a billing question, the one moving house, the vulnerable customer who genuinely needs help: all of them sit behind several hundred people asking the same thing.
Tell people before they ask
The cheapest contact is the one that never happens. When an incident is confirmed, message the customers you know are affected on the channel they already use: text, email, WhatsApp, an app notification. Say what is down, which area, what you know so far, and when the next update will come.
Then do the same on the status page and the website's home page, and change the phone line's opening message. Many operators update one of these and forget the others, so the IVR tells callers there are no known issues while the status page says otherwise. Customers notice.
We wrote more about why a one-way message is half the job in notification to conversation. An outage message should accept a reply.
A status-aware agent says it first
This is where a conversational agent earns its place, and where most get it wrong.
A generic chatbot hears "my internet is down" and starts router troubleshooting: turn it off and on, check the lights, try another cable. During a known outage that is insulting. The customer does ten minutes of pointless steps and then has to ask for a person anyway.
A status-aware agent checks the customer's postcode or account against live incident data before it does anything else. If they are in an affected area, the first thing it says is that there is a known fault there, what it is, and what the latest update is. If they are not, it knows this is probably a different problem and moves into diagnosis.
The hard part is the data. The incident has to exist somewhere the agent can read, in a form it can match against an address or an account, and someone in the network team has to own keeping it current. In our builds that integration and that ownership take longer to agree than anything on the conversation side. If incidents live in an engineer's spreadsheet or a group chat, sort that out first.
ETAs, and being honest about them
Give an estimated fix time only when engineering has given one. If there is no estimate yet, say so, and say when the next update will be. "We do not know yet, the next update is at 3pm" is a perfectly good answer.
Update the ETA before it passes, not after. A time that comes and goes in silence produces the second wave of contacts, angrier than the first. An agent reading live incident data handles this without anyone remembering: every customer who asks gets the current position, not the one from two hours ago.
And when service comes back, say so, and ask customers to check. Partial restorations are where agents and people both trip up, because the incident shows as resolved while some customers are still offline.
Collect fault reports without a queue
Some customers do need to report something: they are not in the incident area, or they are and still offline after the fix. Let them report it in the conversation. Take the account, the address, what is happening and since when, and raise the ticket with the history attached.
This matters for compensation as well as for the repair. Ofcom's automatic compensation scheme pays customers of signed-up providers £10.34 for each calendar day their service is not repaired, once it is still not fixed two full working days after they reported the fault. That is the rate from 1 April 2026. Ofcom's guidance also says customers should still be compensated when the cause is outside the provider's control, giving extreme weather, strikes and third-party acts as examples. So the time each report was made is a record you will need, and an agent logs it exactly. We set out what each failure costs in Ofcom automatic compensation: what it costs.
When to hand to a human
The agent should handle the common question and step aside for the uncommon one. Hand over when:
- The customer is vulnerable or relies on the line, for example for a care alarm or a medical reason. Ofcom requires providers to offer priority fault repair on landline and broadband to disabled customers who need an urgent repair, for those who have registered in advance.
- They work from home and need a workaround today.
- They want to complain or cancel.
- The agent cannot confirm whether they are affected.
The handover should carry everything: the account, the incident it matched, what the customer was told and what they asked for. Nobody should have to explain an outage twice. There is more on how a well-built agent handles the limits of what it knows in what happens when an AI agent does not know the answer.
What to set up before the next outage
Most of this cannot be built during an incident. Before the next one:
- Put incidents somewhere a system can read, matched to postcodes or network areas, with a named owner for keeping them current.
- Write the outage messages now: first notice, update, no ETA yet, restored. Agree who can send them.
- Connect the status page, the phone line's opening message and the agent to the same source, so they cannot disagree.
- Decide the handover rules, especially for vulnerable customers.
- Make sure fault reports are logged with a time, so compensation can be worked out without arguments.
- Rehearse it. Pick a past incident and walk it through.
If you want to see how a status-aware agent answers an outage question, you can try our agent, or talk to us about connecting one to your incident data.
