Service Outage Live Chat Response Templates
Six live chat responses for a real outage: first notice, no ETA, ETA given, angry customers, all clear, and SLA credit asks -- written for incident hour. Use the variants as-is, edit the placeholders, or download the editable Word doc.
- Format
- Editable Word .docx
- Length
- 6 variants · copy-paste
- Price
- 100% free
- Setup
- Copy or download
Get the editable Word doc in one click.
★★★★★4.9·Free · No signup · Instant download
Service Outage Live Chat Response Templates
Response
Hi customer name -- you are right, and thanks for flagging it. We have confirmed an issue with affected feature and our engineering team is on it right now.
working feature is unaffected, so you can keep working there in the meantime.
I will come back to you by next update with a real update, even if it is just to say we are still working. You can also follow along at status page.
Why it works
It confirms rather than deflects, scopes the blast radius so the customer knows what they can still do, and commits to a specific next update -- which is what stops someone asking every ten minutes.
6 ready-to-use variants
Copy allFirst outage notice
When to use: Use it the moment an incident is confirmed and chats start arriving.
Response
Hi customer name -- you are right, and thanks for flagging it. We have confirmed an issue with affected feature and our engineering team is on it right now.
working feature is unaffected, so you can keep working there in the meantime.
I will come back to you by next update with a real update, even if it is just to say we are still working. You can also follow along at status page.
Why it works
It confirms rather than deflects, scopes the blast radius so the customer knows what they can still do, and commits to a specific next update -- which is what stops someone asking every ten minutes.
No ETA yet
When to use: Use it when the team is still diagnosing and any estimate would be a guess.
Response
customer name, I want to be straight with you: I do not have an ETA yet, and I would rather say that than give you a number I cannot stand behind.
Here is where we actually are -- the team is current stage on affected feature. Once they know the cause, an estimate follows quickly. Right now they do not.
What I can promise is a time. I will message you by next update with whatever we know then. In the meantime, workaround is the closest thing to a stopgap I can offer you.
Why it works
Customers forgive an unknown ETA far more readily than a broken one. Naming the diagnostic stage shows real motion, and a guaranteed update time replaces the certainty you cannot give.
ETA given
When to use: Use it only once the incident owner has confirmed the estimate -- never before.
Response
customer name, I have an actual estimate for you now. The team traced it to root cause and expects affected feature back by eta.
Two things worth knowing before then. First, recovery note -- so you do not need to redo work on the assumption it vanished. Second, if that window slips, I will tell you before it passes rather than after.
You do not need to sit in this chat waiting. I will message you here the moment it is confirmed fixed.
Why it works
It pairs the estimate with a cause and a recovery answer, which is what the customer actually needs to plan. Promising to flag a slip early is the detail that makes the ETA credible instead of hopeful.
Angry customer mid-outage
When to use: Use it when the chat turns from asking about status to venting real consequences.
Response
customer name, I am not going to talk you out of being angry -- impact described is a real cost and it is our fault it happened.
So here is what I can actually do rather than apologise again. I have put your name on the incident with owner name owning it personally, which means your account is on the list we check before we call this resolved, not after.
I will update you by next update on affected feature whether or not there is progress. And once we are out of this, I want to talk about making it right -- but I would rather fix your service first than negotiate while you are still down.
Why it works
It absorbs the anger without defensiveness, converts sympathy into a named owner, and defers the compensation conversation without dodging it.
Resolved, all clear
When to use: Use it after monitoring confirms a stable fix, not at the first green dashboard.
Response
Good news, customer name -- affected feature is back. We have been watching it for long enough now to be confident it is genuinely stable, not just briefly quiet.
The incident ran for duration in total. On your side: action needed. Could you give it a try and tell me it looks right to you? Our dashboards say healthy, but you are the one who will notice if something is still off.
We are writing this one up properly -- postmortem note -- because you deserve to know what broke and what we changed so it does not repeat.
Why it works
It waits for stability before claiming victory, hands the customer a verification role, and promises a postmortem, which is what turns an outage into evidence of a serious team.
SLA credit or compensation ask
When to use: Use it as soon as compensation comes up, during or right after the incident.
Response
Fair question, customer name, and you should not have to fight for this one.
Confirmed downtime was duration. Under sla terms, that puts you in scope for a service credit -- I have checked rather than asked you to. credit process, and you should see it on your account within timeframe.
I am logging the claim from my side now so nothing depends on you remembering to chase it.
If the downtime cost you more than the credit covers, say so and I will get it in front of someone who can actually make that call. I am not going to pretend the standard credit is always the whole story.
Why it works
It applies the entitlement proactively, removes the paperwork burden, and opens a door for larger claims without over-promising.
How to use this template
- Pick the closest variant. Choose based on the situation, not only the channel.
- Replace every placeholder. If you cannot fill a field, ask one clarifying question first.
- Save the final version into UNmiss, your CRM, or your help desk so the team stays consistent.
- Review results weekly. Drop variants that create confusion and improve the ones that work.
Frequently asked questions
Can I use these templates commercially?
Yes. Copy, edit, and use them in your business, client work, CRM, help desk, or UNmiss workspace.
Why are there six variants?
One generic template rarely fits every situation. Six variants give your team practical choices without a messy library.
Should I paste these into UNmiss?
Yes. Save the best variants as canned replies, knowledge base entries, routing rules, or CRM notes so your AI agent and team stay consistent.
How often should we update customers during an outage?
Commit to a specific interval and hold it -- every thirty minutes for a severe outage, hourly for a degraded service. The update matters even when there is no news. Silence is what turns a technical problem into a trust problem.
Should agents give an ETA if engineering has not confirmed one?
Never. A missed ETA costs more credibility than admitting you do not have one. Give the diagnostic stage and a guaranteed time for the next update instead -- that gives the customer something real to plan around without inventing a promise.
What should we say to a customer threatening to leave mid-outage?
Acknowledge the business impact before defending anything, and do not negotiate contracts during the incident. Get them a named owner and a follow-up conversation once service is restored, when both sides can talk about remedies with facts instead of adrenaline.
Do we have to offer credits during every outage?
Only where an SLA or contract requires it, but always tell customers how to claim what they are entitled to. Making people hunt for a credit they have earned generates far more resentment than the downtime itself did.