Why a short, regular update beats a long, late one
When a checkout page fails, the people who care most are the ones trying to pay. They do not need the whole story at once. They need to know you are aware of the problem and roughly when they will hear more. A short update sent at 14:10 does more good than a full explanation at 16:00.
Regular updates also cut down on questions. If your last message said you would post again at 14:40, customers have less reason to email you at 14:20 to ask what is happening. Your team benefits too. There is one place to look and one text to copy.
Keep each update short enough to read on a phone. Five lines is usually enough.
The five lines: what is affected, since when, what you know, what you are doing, when you will update next
Copy this into your editor and fill in the gaps:
- What is affected: [the part of the product, in customer words]
- Since when: [time and time zone, for example 13:52 GMT]
- What we know: [one or two facts you have confirmed]
- What we are doing: [the next concrete step]
- Next update: [a time, not a vague promise]
Each line answers a question a customer will ask. The first tells them whether the problem affects them. The second tells them whether it is new or has been going on for a while. The third stops them guessing. The fourth shows that someone is working on it. The fifth tells them when to look again.
Write times in full with the time zone. Use plain nouns such as checkout, login or dashboard. Skip abbreviations your customers may not know.
A worked example for a failing checkout page, written in plain words
Here is the template filled in for a shop whose checkout page returns an error when customers press Pay.
What is affected: Some customers cannot complete payment at checkout.
Since when: 13:52 GMT.
What we know: Card payments fail with an error after the Pay button is pressed. Orders are not being taken for those payments.
What we are doing: We are checking the payment step and the most recent change to the checkout page.
Next update: 14:20 GMT, even if we have not found the cause yet.
Notice what is missing. There is no guess about the cause, no name of a supplier, and no list of internal systems. The customer knows whether they are affected, what to expect, and when to check back. If the workaround is simple, such as trying again later, add it as a sixth short line. Do not add it if it is not true.
How the wording changes between investigating, identified, monitoring and resolved
Most incidents move through four stages. The five lines stay the same. The content changes.
Investigating. Say what you can see, not what you think is behind it. The example above is an investigating update. Its job is to show that the problem is known.
Identified. You now know the cause. Name it in plain words, such as 'a fault in the payment step after a recent change'. Say whether you have a fix in progress and, if you can, when the next update will confirm it.
Monitoring. A fix is in place and you are watching it. Say what you have changed, and what customers should check. For example: 'Card payments are completing again. We are watching payments for the next hour before we close this.'
Resolved. Say that the problem has ended, when it started and when it stopped, and whether anyone needs to act. A customer whose order failed may need to place it again. Tell them that directly. Then stop posting, and say when the incident report will be shared if you plan to share one.
If an update changes from one stage to the next, say so in the first line. Readers should be able to see at a glance that something has moved.
What to leave out: guesses, blame and technical detail customers cannot act on
Leave out guesses. A line such as 'probably a database problem' sends people off in the wrong direction, and you will have to correct it later.
Leave out blame. 'A third party failed' may be true, but it does not help the customer who cannot pay, and it tends to read as an excuse.
Leave out stack traces, server names and internal ticket numbers. Customers cannot act on them, and they fill space that should hold the things they can act on.
If you do not know the cause yet, say so. 'We do not know the cause yet' is a complete and honest sentence. Pair it with a time for your next update, and keep that time.
Posting the same text to your status page and sending it to your team
Write each update once. Post it to your status page, then send the same words to your team. Customers and colleagues then read the same facts. This avoids the common problem where support says one thing in a chat window and the status page says another.
It also helps the person who is fixing the problem. They are not writing separate messages for different audiences while they debug. They write one short update, check it against what they know, and go back to the work.
Tweed Tyne runs its own work on AperioFlow, and the monitors and status page are part of how it keeps people informed. If you are a solo developer, a freelancer who runs client sites or a small team of up to 10 people, the same approach works for you.
If you want to try this before you need it, start free at https://app.aperioflow.co.uk/#/signup. The free plan includes 10 monitors, so you can set up a status page and see how an update reads to your customers while nothing is broken.