Outage and delay updates: reach every affected customer in their own chat with one message
When something breaks, dozens of customers write in on every channel at once. Copy 4 message templates, pick an update cadence by severity and see how a SaaS team and an online store get every affected customer updated.
Deskwoot Team
10 min read
Contents
At 09:40 the login breaks, and by 10:30, 38 customers have written in on 3 channels. Every reply sounds different, and nobody can say who already heard back. Once the fix ships, someone has to find all of them again.
A carrier delay in an online store goes the same way, only slower. You get 4 templates, an update cadence by severity and 2 worked cases for any help desk.
What every outage message needs
Atlassian's Statuspage team sums up the first message in one line: "Quickly acknowledge the issue, briefly summarize the known impact, promise further updates" (Atlassian).
Hyperping, which sells status pages, asks for 6 fields in every notice (Hyperping):
- what is broken
- who is affected
- since when
- the workaround
- the next update time
- where to follow along
Name the next update time, then keep it
The next update time does the most work. A customer who reads "next update by 11:00 CET" has no reason to keep refreshing or to write "any news?".
So keep the promise. Hyperping's rule is to "never let a promised update time pass", because "a missed update time reads as silence". If 11:00 comes and you have nothing new, send "Still working on it, next update by 11:30."
The same goes for an estimate of when the fix lands. Cronitor's guide puts it plainly: "People plan around the time you published", so post again as soon as that time slips (Cronitor).
Be plain about the cause, and own it
Name the cause in plain words, or say you do not know it yet. A guess you take back later costs trust.
Own the problem when someone else caused it, too. Atlassian again: "in your customers' eyes, it's a problem with your service." That includes your parcel carrier.
How often to update, by severity
The first 2 rows of the table follow Atlassian, which suggests an update every 30 minutes as a default, and Hyperping, which gives these numbers:
- the first notice within 15 to 30 minutes of confirming the outage
- updates every 30 to 60 minutes
- every 15 minutes when a full outage hits a service that earns you money
- the resolved notice within 30 minutes of the fix
The partial outage row sits at the slow end of Hyperping's range. The last 2 rows are our own rule of thumb for slower problems.
| Severity | Example | First message | Updates | Last message |
|---|---|---|---|---|
| Full outage | Nobody can log in, checkout is down | Within 15 to 30 minutes of confirming it | Every 30 minutes, every 15 if it stops sales | Within 30 minutes of the fix |
| Partial outage | One feature fails, or only some customers are hit | Within 30 minutes of confirming it | Every 60 minutes, and whenever the estimate moves | Within 30 minutes of the fix |
| Bug with a workaround | PDF export fails, CSV export still works | The same day, with the workaround | When the status changes, at least once a day | When the fix ships |
| Shipping delay | A carrier stops collecting, a depot stalls | The day you find out | Once a day while parcels are stuck, and whenever the carrier has news | When parcels move, then again for any that stay lost |
Whatever the row, everyone who got the first message also gets the last one, even once the pressure is off.
4 templates you can copy
Write them for a chat window, since that is where many of these updates land. Keep each one short, put the time zone next to every time and drop the "Dear valued customer" opening.
Words in [brackets] are yours to fill in.
1. First notice
Hi [first name], thanks for letting us know. [Login] is not working for [some / all] customers since [09:40 CET], and we are on it.
[Until it is back, you can ...] We do not know the cause yet. Our next update comes by [10:25 CET] in this chat, even if there is no news.
For a delivery delay:
Hi [first name], your order [number] is held up. [Carrier] has not collected parcels from our warehouse since [Tuesday] because of [a system failure at their depot].
Your order is packed and ready, and we expect it to leave by [Friday]. We will write again by [tomorrow, 17:00] either way. If you would rather not wait, reply "cancel" and we refund you in full.
2. Progress update with the next update time
Update on [the login problem], [10:25 CET]: we found the cause. [A database change from this morning blocks logins.]
We are [rolling it back] now and expect [logins] to work again around [11:00 CET]. That estimate can still move. Next update by [10:55 CET].
3. Fix shipped, or parcels moving
[Logins] work again since [11:05 CET]. If you still see [the error], please [log out and back in] and reply here if that does not help. [Bookings made between 09:40 and 11:05 did not save, so please enter them again.]
For a delivery delay:
Good news: [carrier] collected the held parcels on [Friday]. Your order [number] is on its way, tracking: [link].
It should arrive by [Tuesday]. Tracking can take up to a day to show the first scan.
4. Final message
[The login problem] is fixed and we are closing this conversation. It lasted from [09:40] to [11:05 CET] and was caused by [one sentence]. To stop it from happening again, we [one concrete change].
Sorry for the trouble, and thanks for your patience. If anything still looks off, just reply here.
Stay concrete here. "We have taken steps to prevent this" says nothing. "We now test database changes on a copy of live data first" tells the customer you learned something.
Write them before you need them
Write your 4 templates now, while nothing is broken, and agree who sends them and how often. When the next outage or carrier mess hits, the person on duty only has to fill in the brackets.
Case 1: a SaaS outage
Take a booking tool used by 1,200 small businesses. A database change goes out at 09:30, and from 09:40 nobody can log in. Support confirms it at 09:46.
How the updates go out
- 09:55: first notice (template 1), next update by 10:25.
- 10:25: template 2. Cause found, rollback started, logins expected back around 11:00, next update by 10:55.
- 10:55: the rollback is still running, so the team sends "Still working on it, next update by 11:15". No news, and the promise holds anyway.
- 11:10: template 3, with the line about bookings that did not save.
- 15:00: after 4 hours without new errors, template 4 names the cause and the change.
Where people get missed
By 10:30, 38 customers had written in: 21 in the chat on the website, 12 by email and 5 on WhatsApp. By 11:05 the count was 52.
The 14 who wrote after 10:30 need the current status, so keep one current text the whole team copies from. By hand, this outage means more than 200 sends across 3 channels, and that is where people get missed.
Case 2: a carrier problem holds up 200 orders
An online store ships about 70 orders a day. On a Tuesday in early December, the carrier's regional depot has a system failure and stops collecting. Twice the carrier promises a pickup for the next day.
By Thursday it is clear that nothing will move soon, and 200 packed orders sit in the warehouse. Of those customers, 64 have already written in: 30 on WhatsApp, 25 by email and 9 in the chat on the website.
The timing makes it worse. Shopify's enterprise blog, quoting the support outsourcer Influx, says stores see "a 79% average spike in support tickets in the first week of December" (Shopify).
That is vendor data, but if your December looks like that, the delay lands on a full queue.
When a UK seller had over 500 Amazon orders stuck behind a delayed container ship, he later wrote in the Amazon seller forum that keeping on top of the customer questions was the hardest part.
The plan for the 200 orders
- Write to all 200 that Thursday, by email from your shop system, before the other 136 notice and start asking. Use the delivery version of template 1.
- Answer the 64 who wrote in, in the channel they used, with the same text.
- Update once a day. On the day the parcels move, send template 3 with the tracking link, and a few days later check which parcels still have not arrived.
For the everyday version of these questions, see our guide to "where is my order?" messages.
One catch on WhatsApp
Meta allows free text on WhatsApp only within 24 hours of the customer's last message. Outside that window, "businesses can only send template messages" (Meta).
So by Thursday, the store can reach the WhatsApp customers who wrote on Tuesday only with an approved template. Get one approved for delays before you need it.
What the law expects when orders are late
In the US
The FTC's Mail, Internet, or Telephone Order Merchandise Rule covers orders that have not shipped yet. If you cannot ship within the time you stated (30 days if you stated none), you must (FTC business guide):
- tell the customer before that time runs out
- give a revised date, or say you cannot
- offer to cancel with "a full and prompt refund"
In the EU
Article 20 of the Consumer Rights Directive 2011/83/EU says the risk of loss or damage passes to the consumer only when they, or someone they named other than the carrier, take physical possession of the goods (text of the directive).
So a parcel the carrier loses is yours to replace or refund, unless the customer hired a carrier you did not offer. Germany has the same rule in § 475 (2) BGB.
Brazil and other countries have their own rules. This is general information, not legal advice.
One update into every chat with a Deskwoot tracker
Deskwoot is our own help desk. A tracker in it is a ticket without a customer, for one problem many customers share, and it turns the more than 200 sends of Case 1 into one send per update.
- Create the tracker, for example "Login fails since 09:40".
- Link the affected chats and tickets. The tracker's search finds open and pending ones by name, message text or number.
- Write the update and click Preview update. It counts who gets it and lists under Not reached every chat it cannot reach, with the reason.
- Send. Each customer gets the text once, in their own chat on that chat's channel (an email goes out in its thread).
- When it is fixed, Resolve with all linked closes the tracker and everything linked to it, with template 4 as an optional last message.
The Affected customers table shows for each customer whether the last update was delivered, read or not delivered, with the reason. If sending breaks off halfway, a second send reaches only the customers still missing.
A tracker update is never a WhatsApp template, so chats past the 24 hours land under Not reached. Send each an approved template (how it works, for numbers on the WhatsApp Cloud API), and once the customer answers, the next update reaches them.
Trackers are part of the Enterprise plan, $12 per agent a month or $9.60 billed yearly (pricing), and one update reaches up to 500 customers.
Try it on a test outage
Sign up, and your new workspace gets 7 days of Enterprise free, without a card, for up to 30 seats including yours. Link 2 or 3 test chats to a tracker called "Test outage" and send them an update to see the preview and the table.
When the 7 days end, nothing is charged: you pick a paid plan or keep working on the free Hacker plan for 1 agent.
Also available in:DeutschEspañolFrançaisPortuguês (Brasil)
