What Support Can't Do (And Why That's Not Their Fault)

A client pinged me last week with a stack trace and a question. The error was unfamiliar to them. They had already done what most engineers do first: opened a ticket with the vendor.

I asked them to show me the vendor's response. They pasted it back. It was, by every reasonable measure, a good support reply. The engineer had identified the error, explained what triggered it, suggested two workarounds, and linked the documentation.

And it was completely useless to my client.

## What Support Is Actually For

Here's the part nobody likes to say out loud: vendor support is a transactional organization. You give them an error message. They tell you what the error means, how to avoid it, or how to fix it. That's the job. They are good at it. Most of them are very good at it.

What they are not set up to do is understand your application. They don't know what your business is trying to accomplish. They don't know which of your workflows actually matter and which ones you can quietly let rot. They don't know that the error you're asking about is the symptom of a much larger problem you haven't noticed yet.

That isn't a criticism. It's a structural fact. Support engineers handle hundreds of tickets across hundreds of customers. They have to answer in general terms, because they cannot know your specifics.

## The AI Shift Made It Worse

It used to be that calling support was at least a defensible use of time. The vendor's tribal knowledge often beat what you could find on your own.

That edge is gone.

Now, if you have an error message, you can paste it into an AI assistant, search GitHub issues, scroll Reddit, or read Stack Overflow. Within five minutes you'll usually have a better explanation than the ticket will give you in two days. The well-sourced public internet plus a good model will out-explain a tier-1 support engineer on most technical questions.

So if the value of support was "explain what this error means," the value just collapsed. What's left is the part support was never designed to do: tell you what to do about it for your business.

## Where Support Quietly Breaks Down

Here's the pattern I keep seeing. A client hits an error. They open a ticket. Support replies with a clean technical explanation. The client reads it, nods, and then has no idea what to do next - because the real question wasn't "what does this error mean." The real question was one of these:

- "Is this affecting any of my actual users right now?" - "Can I work around this without taking the system down?" - "Is this going to happen again, and what do I change so it doesn't?" - "Should I be escalating this to someone internally before it gets worse?" - "Is this even the right system to be using for what we're trying to do?"

None of those questions have a vendor-shaped answer. The vendor doesn't know your users, your tolerance for downtime, your change windows, your internal politics, or your roadmap. They can only answer the question you literally asked.

And most people, when they first hit an error, don't know which question they should be asking.

## The Cost of Mistranslation

This is where the money burns. The client reads the vendor's reply, decides the vendor "doesn't get it," escalates internally, escalates externally, opens a higher-tier contract, asks for a customer success manager, schedules a quarterly business review, files a feature request. Three months later, the original error is still happening, and now there's also a relationship problem.

I've watched this cycle play out across multiple companies. It's not anyone's fault. Everyone is doing their job. The system is just designed to fail at the specific thing the client actually needed.

## What a Working Relationship Actually Buys You

A consultant, especially one you keep around, changes the question before you send it to the vendor.

When my client brought me that stack trace, I didn't ask the vendor. I asked:

- What was the client trying to do when this happened? - Is this a new code path or one that's been stable for months? - Did anything change in the data, the traffic, or the deployment right before it started? - What's the blast radius if this is wrong?

Within twenty minutes I had a theory. The vendor's first reply had nothing to do with what the client actually needed. It was technically correct and operationally irrelevant.

That's what a working relationship buys you. Not information - information is free now. It buys you someone who knows your business well enough to ask the right question, frame it correctly when it does go to the vendor, and translate the answer back into a decision you can actually make.

## The Uncomfortable Truth

If your only relationship with a vendor is through support tickets, you are paying for the wrong thing. You are paying for error-message translation in a world where error-message translation is free. You are not paying for outcome ownership, and outcome ownership is the only thing that actually moves the needle.

This is not an argument against support. Support is fine. Support is necessary. Support is the floor.

It's an argument for treating support as the floor, not the ceiling. The work that actually protects your business is the work that happens between the tickets - and that work has no vendor-shaped home.

## My Takeaway

When something breaks, the first instinct is to file a ticket. That's fine. Do it. You'll get a useful reply, and the reply will tell you what the error means.

Then ask yourself: does knowing what it means get me closer to a decision? If the answer is no - and it usually is - you don't have a support problem. You have a translation problem. And that's a different job, done by a different kind of person, in a different kind of relationship.

That's the gap I work in.

*Hitting the same kind of vendor reply over and over? The fix isn't a bigger support contract. Let's talk about what a working relationship would actually look like.*