Incident Communication to Customers

Customer communication during an ICT incident should tell affected people, in plain language, what has stopped or degraded, what it means for them, what the firm is doing, and when they will hear next. Early messages will be incomplete, and they should say so, rather than pretending to a certainty the firm does not yet have. Later messages should update the picture, correct earlier statements where needed, and explain what customers should do, if anything. The aim is not to reassure at all costs, but to leave customers less uncertain than they were before the message.

The first message should answer the questions a customer asks on discovering a problem, which are usually whether the problem is with their own device or with the firm, whether their money or data is affected, and whether there is anything they should do. It should name the service affected in the words customers use for it, not in internal system names. It should give a plain description of the effect, such as being unable to log in or to make a payment, and it should avoid technical detail that does not change what the customer experiences. If the firm does not yet know the cause or the recovery time, the message should say that, and give a time for the next update. A vague message that promises a quick fix can do more harm than a candid message that admits uncertainty.

Updates should follow a steady rhythm that customers can rely on, even when there is little new to report. A short message that says the firm is still working on the problem, that the position has not changed, and that the next update will come at a stated time, is more useful than silence. When facts do change, the update should say what changed, not merely repeat the previous message with a new timestamp. If an earlier statement proves wrong, the correction should be explicit, because customers who notice the discrepancy without an explanation will trust later messages less. The same applies to recovery. A message that says a service has returned should be sent only when the return has been checked for the affected groups, not merely when a system indicator turns green.

The tone that works best is calm, specific, and free of jargon. Customers in the middle of a disruption are often anxious or frustrated, and corporate language that minimises the problem will usually increase that frustration. Apologising for the disruption, without speculating about blame or cause, is generally appropriate and is rarely the part of the message that causes trouble. What causes trouble is language that sounds like it was written to protect the firm, such as describing a total outage as a temporary inconvenience, or language that promises an outcome the firm cannot guarantee. Plain words, short sentences, and a clear statement of what happens next will serve most firms better than a polished paragraph that says very little.

The channel should be the one customers already use for that service, supplemented by the firm's usual status or service channels where those exist. A message posted only on a channel that affected customers cannot reach, because the incident itself has taken it down, is no message at all. Firms should therefore plan for the possibility that their normal channel is part of the outage, and have an alternative ready. Accessibility also matters, in the sense that messages should be readable by customers who use assistive technology and understandable by customers whose first language may differ from the firm's. Testing a few draft messages with non technical readers before an incident can reveal jargon and ambiguity that the incident team would otherwise miss.

After the service returns, customers deserve a closing message that confirms the return, explains in plain terms what happened, and says what the firm is doing to reduce the chance of recurrence. That message does not need to contain the full technical root cause, and it should not speculate where the analysis is incomplete. It should, however, be honest about what is known and what remains under review. Where customers suffered a concrete consequence, such as a delayed payment, the closing message should say what will happen about that consequence, rather than leaving customers to ask. A thoughtful closing message can restore trust that the incident itself damaged, while silence after recovery can leave the impression that the firm moved on before its customers did.