The vendor status page says "Investigating." Your inbox already has fourteen messages. Someone on your team has just typed "it's on their end" in the internal chat. All of that is factually correct and almost completely useless to anyone who cannot work right now.
Here is the distinction I keep coming back to: the outage is the vendor's fault, but the customer experience during that outage is yours. Those are two separate problems, and only one of them was ever in your control. Most teams treat them as the same problem and end up doing nothing useful about either.
The part nobody wants to own
When something in your stack goes down, two things happen simultaneously. Your users open a support ticket (or just call your number directly). And someone on your team types that it is on the vendor's end. Both observations are true. Neither one helps the person who cannot log in, submit a form, or process an order this morning.
The user does not have a vendor relationship. They have a relationship with you. When the thing they pay for or depend on stops working, you are the face of that failure in their day. That is not unfair or irrational on their part. It is just how accountability works from the outside looking in.
I have seen teams handle this badly, not through malice but through a genuine belief that communicating about something outside their technical control is somehow inappropriate. The reasoning sounds logical at the time: "We should not say anything until we know the cause." What actually happens is that users call 40 minutes later, angrier, having assumed the worst and having gotten no signal that anyone was aware of the problem.
What a good response actually looks like
The most trust I have ever seen a support team build happened during an incident they could not fix. A CRM platform went down on a Monday morning. Within about 12 minutes, the team had sent a proactive update to affected customers. It said something like: "We are aware of an issue affecting [platform]. This is a third-party incident that we cannot resolve on our end, but our team is monitoring it closely. We will send updates every 30 minutes until service is restored. You do not need to contact us to flag this, we already have it."
Nothing misleading. No false comfort. No promise they could not keep. Just the information the user needed to know that someone was watching, and that they could stop worrying and get on with the parts of their day that still worked.
Meanwhile, another team I know spent the same type of incident arguing internally about whose fault it was and whether to send a communication at all. By the time they reached a decision, there were around 60 support tickets in the queue and a public review had appeared criticising their responsiveness. The vendor had fixed the issue before the team sent their first update.
The vendor had the incident. The team had the relationship. Only one of those things was negotiable during the outage window.
Three things worth building before the next outage
This is the part most operations teams skip. The prep work feels hypothetical until it is not, and then it is too late for prep.
Status monitoring that alerts you before your users do. A simple Power Automate flow (or equivalent) that polls your critical vendors' status pages and pushes to a shared channel takes a few hours to build once. I keep these running for the tools that would cause the most user pain if they went down: the CRM, the support platform, the email routing layer, M365. When a vendor's status page shifts from "Operational" to anything else, I get a notification in my monitoring channel. My users do not need to be the ones to tell me something is wrong. That shift alone changes the conversation from reactive to at least informed.
A pre-written communication template. The middle of an incident is the worst possible time to start writing from scratch. Having a draft that reads something like: "[Tool] is currently experiencing an issue affecting [function]. We are aware and monitoring. Estimated impact: [describe]. We will update by [time]." means you can send a real human update in under five minutes. Every blank in that template is information you already have, not information you are still chasing. This sounds trivial. Teams that have one and teams that do not behave completely differently during the first 15 minutes of an outage.
An impact matrix for your critical tools. A single page that maps each tool to: which users or functions are affected if it goes down, what the fallback option is, and who owns the communication. You do not need to maintain this constantly. Build it once, review it quarterly, and keep it somewhere findable on a Monday morning. I have watched people spend 20 minutes during an active incident trying to figure out which customers were affected, when a two-minute document would have answered that instantly.
The honest case against this position
There is a reasonable pushback, and I want to give it a fair hearing.
If you own the communication around every vendor outage, you may be training your users to expect you to have answers about things you cannot actually fix. You may be covering for a vendor who deserves to be called out more directly. You may be creating the impression that your SLA includes uptime guarantees that your contract does not actually include. These are real tensions, not invented ones.
I think the honest response to that is honest communication. Saying "this is a third-party issue we cannot resolve, but we will keep you updated" does not hide the vendor's responsibility. It just means you are being useful in a moment when being unhelpful would be the easy option. Users are generally capable of understanding that not everything is within your control. What they are not forgiving about is finding out you knew and said nothing.
The other legitimate objection is the prep work itself. Building status monitoring, writing templates, and maintaining an impact matrix takes time, and that time competes with everything else in a normal week. That is genuinely true. I would only say that the first bad incident where you have none of those things in place tends to be a persuasive argument for building them, at considerable cost in goodwill that you could have spent differently.
Where I land
The outage is the vendor's fault. The 60 tickets and the public review are yours. Those were always two different problems. The vendor's problem was outside your control. Yours was not.
I have been on both sides of this. The teams that prep for it handle vendor outages as a communication challenge, which they can actually solve. The teams that do not treat them as a technical problem someone else caused, which they cannot. The second framing is accurate and useless in equal measure.
This is not a popular argument because it extends your accountability into territory where you did not cause the underlying failure. But the users sitting on the other end of your support queue are not interested in where the failure originated. They are interested in whether you knew and what you did about it.
If you disagree with this, I would genuinely like to hear the counter-argument. My contact is at felixmaru.com.
Comments