Customer support incident communication starts to fall apart the moment three agents answer the same fault with three different sentences. One writes "it's temporary", another "we'll have it fixed by noon", a third asks for a screenshot. Customers compare those replies, and every broken promise comes back as another message. The problem is not the number of tickets; it is the lack of a single source of facts.
This guide covers a sudden outage or fault that affects many people at the same time: login fails, card payments error out, a page will not load. It does not cover announced maintenance or the longer hunt for the cause of recurring cases; for that, read the guide to repeat support tickets. Here you decide what the team says, who changes it and when the customer will hear something new.
Confirm the scope before the first reply goes out
Before anyone replies, pin down the minimum: what is broken, since when the team has seen it, who is affected and what is still unknown. "Some customers cannot log in to the mobile app; the browser version works" is a usable scope. "We have a system problem" helps neither the customer nor the agent. If you do not know the scope yet, say so plainly instead of guessing.
Name one person who owns the wording of the update. They do not have to fix the fault; their job is to collect confirmed information from the technical people and pass it to the support team. Agents keep answering customers, but they do not add their own guesses about the cause or the fix time. That way every change to the message has an author and a timestamp.
The Google SRE book describes a separate communications role in incident management, responsible for sending periodic updates to the response team and stakeholders. It is written for engineering teams; mapping that role onto a small support team is our adaptation. Google SRE Book, Managing Incidents.
The fact sheet: one source for every reply
A fact sheet is a short note that every agent works from. It contains only confirmed information and shows when it was last changed. It is not a technical report: internal detail stays out unless the customer needs it to make a decision. The table below shows the fields for a fictional online shop where card payments fail with an error.
Scroll the table sideways to see all columns.
| Field | Example entry | What to leave out |
|---|---|---|
| Symptom | Card payment ends with an error message | Guesses about the cause |
| Scope | Cards affected; bank transfer works | "All customers" unless verified |
| Workaround | Orders can be paid by bank transfer | A workaround nobody has tested |
| Owner | Support shift lead | Several people at once |
| Next update | At 2:30 pm, even if nothing changes | A fix time with no basis |
The most important field is the time of the next update. You are promising information, not a fix, so you can keep that promise even while the cause is still unknown. When the time comes, the owner updates the sheet and sets the next time. No new findings is also a fact worth passing on: "we are still investigating, and the workaround still works".
The first reply to everyone who gets in touch
Each customer writes about their own case, so the reply combines the shared fact with their situation. First confirm that the problem is known, then give the scope and the workaround, and finish with the time of the next update. If a customer describes something other than the symptom on the sheet, do not file them under the incident automatically; ask one question that settles it.
"Thanks for letting us know. Since about 12:40 pm, card payments have been failing with an error; bank transfers work normally. If you want to finish your order now, choose bank transfer. We cannot give a fix time yet because the cause is still being checked. We will send the next update in this conversation by 2:30 pm, even if nothing has changed."
Save the template as a quick reply and update it together with the sheet, not in a copy on one agent's laptop. The guide to support reply templates explains how to build such skeletons. For a longer outage, add a short help article with the same description; the article on a website knowledge base and FAQ covers how to write it.
An update rhythm that does not promise a fix time
Customers do not need the technical detail, but they want to know what stage things are at. Name the stages in plain words and use them consistently in every reply. Move to the next stage only when the owner of the sheet confirms it. Set the interval between updates according to how serious the problem is and record it on the sheet, instead of improvising it in each conversation.
- Investigating.The problem is known and the scope partly confirmed. Share a workaround if one exists, plus the time of the next update.
- Cause identified.The team knows what happened and is working on a fix. Give a timeframe only if the person fixing it has confirmed one.
- Fix deployed, monitoring.The change is live, but the team is checking that the problem does not come back. Ask the customer to try again and report back.
- Resolved.The symptom is gone within the verified scope. Every linked case gets its own confirmation and next step.
Atlassian's Incident Insights documentation uses four incident statuses: investigating, identified, monitoring after a fix, and resolved. The source describes the status of its own services; it does not say how often to update customers. Atlassian Support.
The monitoring stage protects you from declaring victory too early. If the fix was verified in only one variant, say which one. The same rule applies to a client project status update: instead of guessing a date, you name the next checkpoint and the condition the rest of the plan depends on.
Linked cases, individual replies
A shared cause does not mean a shared conversation. Each customer has their own history: one lost an order, another just wants to know whether to try again, a third may have been charged twice. Do not merge these cases or send one mass message that ignores the differences. Label them together, but answer each person individually, starting from the facts on the sheet.
In Meetlead customer support you can label the cases with one tag, keep the fact sheet in an internal note, prepare a quick reply and publish a help article in the widget knowledge base. You update the quick reply and the article by hand, and each reply is sent by an agent in the customer's own conversation. The guide to tagging conversations and tickets explains how to name such a tag so it does not get lost among other categories.
The shared tag is also useful after the outage. It shows how many people got in touch, through which channels, and how many are still waiting for confirmation. Do not read that number as the full scale of the problem: many affected people simply never wrote in. If someone received wrong information earlier, correct it separately, following the guide on correcting a wrong answer.
Closing the incident: check every case on its own
The final update says what was fixed, since when it works and what the customer should do if the problem persists. Avoid a blanket "everything works again" when the fix was verified in a limited scope. Treat customers who suffered a consequence separately, for example an unpaid order or a double charge. Those cases need a decision, not just a resolution notice.
- Every case with the incident tag has a final reply or an owner and a deadline.
- Customers affected by consequences have their own next step, not just a fix notice.
- The fact sheet shows a final status and the closing time.
- The incident quick reply and help article are withdrawn or updated.
- The team noted what information customers were missing in the first hour.
After closing, review the tagged conversations and compare the first replies with the sheet. If agents promised fix times or described different scopes, fix the template and the order of steps, not just individual conversations. Keep the old tag; without it you cannot check at the next outage whether communication was faster and more consistent.
Questions that come up during an incident
Should you give customers an estimated fix time? Only when the person fixing the fault has confirmed it and understands what it depends on. Otherwise, give the time of the next update and keep to it. A missed fix time usually generates more messages than an honest "we don't know yet". When the estimate changes, say what changed it.
What do you tell a customer whose problem only resembles the incident? Do not add them to the shared case without checking. Ask about one deciding detail, such as the channel, the device or the error message. If the symptom is different, handle the case separately and do not offer the workaround from the sheet. Wrongly linking someone to the incident leaves them waiting for a fix that does not touch their problem.
