An outage the client blames on you but did not cause

1 day ago
3 min read

Introduction

A client's office cannot work. Email is down, or a line-of-business application is unavailable, or the internet has failed entirely. You are the IT provider, so you are the one being rung, and the tone of the call makes it clear that this is understood to be your fault.

Frequently it is not. A cloud provider has an incident, a telecoms carrier has a fault, a software vendor has pushed a broken update. But from the client's chair the distinction is invisible: they pay you to make the technology work and today it does not. That is a fair way to see it.

1. An outage the client blames on you needs handling before it needs attributing

Attribution is the least urgent part. It can wait until lunchtime.

Do not lead with "it is not us"

Even when true, it lands as an excuse. Lead with what you are doing, and cover attribution afterwards when things are working. Order matters here.

Focus on continuity

Mobile data, a spare line, webmail, an offline process, working from another location. Any of them helps. Getting a business partially functioning is worth more than a correct diagnosis. Improvise if you have to.

2. Communicate constantly and to the right person

Silence is what converts an incident into a complaint. Talk more than feels necessary.

Update every thirty minutes

Even with nothing new. A client who hears from you regularly stops feeling abandoned and stops phoning. Keep each one short.

Give the client something to tell their staff

They have twenty people asking. One sentence they can forward is disproportionately valuable. Write it for them.

3. Establish what happened, with evidence

Do it properly and afterwards. Not in the middle of the incident.

Get the third-party status confirmation

A vendor incident page, a carrier fault reference, a provider post-mortem. Keep copies of all three. Evidence closes the attribution question in a sentence. Attach the reference.

Check whether your own configuration contributed

Sometimes an external fault only caused an outage because there was no redundancy. That part is yours to own. Say it before they find it.

4. Turn it into a resilience conversation

This is the useful outcome. Every outage should produce one.

Show what would have reduced the impact

A backup line with automatic failover, a secondary provider, cached working copies, an offline procedure. Price each one. Quantify what the morning cost them. Use their own numbers.

Present it as a choice, not a sale

Here is the exposure, here is the cost of removing it, here is my recommendation. Clients accept resilience spending most readily immediately after an outage. Send it within the week.

5. Manage the account relationship afterwards

Outages are when contracts get reviewed. Get ahead of that.

Send a written incident summary

Cause, duration, actions taken, evidence, recommendations. Send it within two days. It converts a bad morning into a demonstration of competence. One page is enough.

Speak to the decision maker directly

Not only whoever raised the ticket. The person who signs the contract has heard about this and should hear your account of it too. Ring them.

Conclusion

Attribution is the least urgent thing, so never lead with "it is not us" even when that is true — it lands as an excuse. Lead with continuity: mobile data, a spare line, webmail, an offline process, anything that gets the business partially working.

Update every thirty minutes regardless of news, and give the client one sentence they can forward to their own staff. Establish the cause afterwards with actual evidence — a vendor incident page or a carrier fault reference — and honestly check whether missing redundancy on your side turned an external fault into an outage. Then use it as a resilience conversation, send a written summary, and speak to whoever signs the contract.