A service goes down at ten in the morning. The team knows within four minutes and begins working on it.
Nothing is said publicly for ninety minutes, because nobody wants to announce a problem before knowing the cause. During that time every affected customer contacts support, which is already stretched by people working on the incident.
The incident lasts two hours. The reputational damage comes almost entirely from the ninety minutes of silence, during which customers concluded that nobody had noticed.
Step 1: say something within minutes
You do not need a cause. Saying that you are aware of a problem affecting something and are investigating is enough and is the entire difference.
Step 2: state what is affected and what is not
So customers can tell whether their situation is included, which is the question behind most of the contact volume.
Step 3: state when the next update will come
Even if it is in thirty minutes with no further information. A stated next update prevents continuous chasing.
Step 4: keep to the update schedule
Including when there is nothing new, since a missed update is read as a deteriorating situation.
Step 5: use a route customers can find
A status page linked from the product and the site, rather than a post somewhere most customers do not look.
Step 6: make support aware before customers are
So nobody answering is discovering the incident from a customer, which happens constantly and is entirely avoidable.
Step 7: give support an agreed form of words
So twelve people are not improvising twelve different descriptions of the same problem.
Step 8: answer the am I affected question specifically
Which is the volume driver, and which is the ground in status and outage questions without a flooded inbox.
Step 9: say what customers should do
Wait, retry later, or take an alternative action, since people will do something and it may as well be the right thing.
Step 10: confirm resolution clearly
And say what customers should check on their side, since some problems leave consequences that resolution does not clear.
Step 11: explain what happened afterwards
Briefly and honestly, which builds more trust than the incident cost, and which most organisations skip.
Step 12: handle the compensation question proactively
Where something is owed, offering it is considerably better received than making people ask.
Step 13: record the contact volume the incident generated
Which is the operational cost, and is the measurement in measuring where operational time actually goes.
Step 14: prepare the templates before you need them
Incident messages written calmly in advance are considerably better than ones written at speed by somebody who is also trying to fix the problem, and they are the reason organisations communicate quickly at all.
Decide who is allowed to publish an update
Agreed in advance, since incidents stall on approval while somebody senior is in a meeting, and a named person with standing authority is what makes fast communication possible at all.
Step 15: answer the am I affected question automatically
An assistant that states what is affected, answers whether a particular customer's situation is included, gives the next update time and confirms resolution absorbs the contact spike that otherwise lands on the people fixing the problem. Set it up through install the widget and train your bot. The cost of handling all of it manually is set out in the opportunity cost of manual customer support. The sector view sits under small business.