Before you solve a customer issue, make sure you understand what is actually happening, a lesson that applies from frontline customer support to Solution Engineering.
I started my career in customer support. Today, I work as a Solution Engineer.
The roles are quite different, but one thing has stayed with me throughout both:
Before you try to fix a problem, make sure you understand what the problem actually is.
It sounds simple. In practice, it is surprisingly easy to skip.
When a customer reports an issue, there is often immediate pressure to find an answer. Support teams want to respond quickly, customers want a resolution, and engineers need enough information to start investigating.
That urgency can sometimes push us toward a solution before we have properly understood the problem. When that happens, we can end up spending a lot of time solving the wrong thing.
Over the years, I have come to believe that the best support engineers are not necessarily the ones who solve tickets the fastest.
They are the ones who figure out what is actually going on the fastest.
One of the biggest lessons I learned in support was that customers usually describe the symptom, not the underlying problem.
A customer might say:
"The AI Agent isn't working."
That sounds like an AI problem.
But it could mean almost anything.
Maybe an intent is misconfigured. Maybe two pieces of training data are conflicting. Maybe an API key is no longer valid. Maybe a knowledge source is missing. Maybe the prompt is not producing the behavior the customer expects. Maybe the selected LLM simply isn't the right fit for the use case.
And sometimes, the customer has configured everything correctly.
There could be a platform bug, a service degradation, an integration failure, a regression after a release, unexpected behavior from an LLM, or even a UI issue that makes a healthy system appear broken.
I saw this repeatedly while supporting customers using Kommunicate. A conversation that started with "the AI isn't working" could eventually turn out to be a configuration issue, a product bug, an integration problem, or simply a gap in the user experience.
That is why I believe diagnosis should come before troubleshooting.
Before asking, "How do we fix this?", I want to know:
It could be the customer's configuration, the platform, a third-party dependency, or even a mismatch between what the product does and what the customer expects.
Until we know that, we are mostly guessing.
There is always pressure in support to respond quickly.
I felt it too.
But over time, I found that spending a little more time gathering context usually saved much more time later.
Depending on the issue, I would ask things like:
These questions are not complicated. But they often reveal something important that the original complaint does not.
AI can help with this part too.
Today, an AI Agent can collect basic information, ask follow-up questions, and prompt customers to share relevant screenshots or recordings before a conversation reaches a human support agent. That can make the investigation much more efficient.
AI can also help interpret some of this context. But when a problem involves multiple systems, business logic, integrations, or behavior that is difficult to reproduce, human judgment can still be important for connecting the dots.
The goal is not simply to collect more information. It is to understand what that information tells us about the problem.
One customer once reached out with a problem that initially sounded straightforward:
"My AI Agent isn't replying."
The agent had been working previously, so the natural assumption was that something had changed on the platform side.
We could have started changing the agent configuration or asking the customer to rebuild things.
Instead, we looked at what was actually happening.
The logs gave us the answer.
The customer was using a Gemini API key for the AI Agent. The configured key was no longer valid, while the old configuration was still present in Kommunicate.
From the customer's point of view, the problem was simply that the AI Agent had stopped responding.
The actual problem was the API credential being used to connect their configuration to the external LLM provider.
Once the API key was updated, the agent started responding again.
The interesting part was not the API key itself. That was an easy fix once we knew where to look.
What stayed with me was the difference between the reported problem and the actual problem.
If we had immediately assumed that Kommunicate was broken, we could have spent a lot of time investigating the wrong system.
Of course, the opposite can happen too. We might initially suspect a customer configuration and later discover a genuine product bug.
That is why I try not to decide who or what is responsible too early.
The customer's first complaint should be treated as the starting point of an investigation, not the final diagnosis.
From the customer's perspective, the priority is understanding what went wrong and getting the expected experience working again, whether the cause lies in their configuration, our platform, or a third-party service.
They want someone to figure out what is wrong.
Once you understand the problem, the next challenge is communicating it clearly.
A weak escalation might say:
"Customer says the AI Agent isn't working. Please check."
That simply creates another investigation for engineering.
A useful escalation should give engineering enough context to start working immediately.
When I raised issues internally, I tried to include:
This makes a big difference.
Engineering spends less time asking for basic information and more time investigating the actual issue.
In other words, a good escalation is not just about passing a problem to another team.
It is about passing along your understanding of the problem.
Moving into Solution Engineering made another thing much clearer to me.
Sometimes the product works exactly as it was designed, but the experience still feels broken to the customer.
That is usually where UX comes in.
For example:
Technically, the backend might be working perfectly.
The customer still experiences a problem.
That distinction matters because the solution may not require an engineering fix at all. It might require a better message, a clearer state, a small UI change, or better product guidance.
This is why I think support, product, design, and engineering need to stay connected.
When designing a feature, it is worth thinking beyond the happy path:
What happens when the user clicks?
What happens while they wait?
What happens if something fails?
And perhaps most importantly, can the user recover without having to contact support?
A lot of support tickets can be prevented before they ever reach the support queue.
Early in my career, I thought success in support meant closing tickets.
The more tickets you closed, the more productive you were.
I see it differently now.
If the same problem keeps coming back, closing each ticket individually is not really solving the problem.
It is treating the symptom.
A recurring issue should make us ask:
Why do customers keep reaching this point?
Maybe there is a bug.
Maybe the documentation is unclear.
Maybe onboarding is missing something.
Maybe the UI is confusing.
Maybe the product is behaving correctly, but customers expect something different.
Support has a unique position here because we hear these frustrations directly.
A single ticket might be an isolated problem.
Ten similar tickets are probably telling you something about the product.
If those patterns stay inside the support queue, the organization loses valuable information.
But when support brings those patterns to product, design, Solution Engineering, and engineering, the conversations become much more valuable.
The goal is no longer just to solve an individual customer's problem.
It becomes figuring out how to make sure fewer customers encounter the same problem in the first place.
That, to me, is when support starts becoming part of the product improvement process rather than simply a reactive function.
There are a few habits from my support days that I still carry into my work today:
None of these are complicated techniques.
They are mostly habits.
After five years in customer support and now working in Solution Engineering, I have started to look at customer problems differently.
Earlier in my career, I often thought the goal was to find the answer as quickly as possible.
With experience, I realized that finding the answer is sometimes the easy part.
The harder part is figuring out which question to answer in the first place.
A customer might tell you that an AI Agent is broken. An engineer might see an error in the logs. A product team might see a UX issue.
All of them may be looking at the same situation from different angles.
Support sits close to the customer experience. That gives us an opportunity to connect those pieces before the problem gets passed from one team to another.
That is probably the biggest lesson I have carried from support into Solution Engineering.
Don't just listen to what the problem sounds like. Understand what is actually happening.
Because sometimes the biggest breakthrough is not finding a better solution.
It is realizing that you were solving the wrong problem.
You don’t need to bet your entire support operation on AI.
Start with the conversations that are safe to automate using an AI agent.
Expand as confidence grows.
.svg)
.svg)
.svg)
.svg){kind=small}