Last week I lost 23 minutes stuck in a support chatbot. I repeated my problem three different ways, followed the script it kept pushing on me, got an FAQ link that had nothing to do with anything, and in the end I was right back where I started. I called the phone number, reached a human agent and solved it in less than 1 minute. The solution was simple. It always was.
This text is not about how AI is bad. The AI I build every day solves real operational problems. It's about a trap I see company after company fall into: putting the AI in the wrong place, solving the wrong problem, and calling that innovation. What cost me 22 minutes wasn't the technology. It was the decision of whoever designed the support flow starting from the complex, when the customer only needed the simple.
1. What really happened in those 23 minutes
The chatbot wasn't broken. It did exactly what it was told to do: keep me inside a closed flow, offer the three or four canned answers someone had registered, and delay the moment of passing me to a person for as long as possible. Every time I strayed from the script, it brought me back to the start. Polite, fast, and completely useless for my case.
The problem is that my case wasn't one of the four anticipated ones. And this is where the design flaw lives: the support was designed for the cases that fit in the box, and treated everything else as if it didn't exist. When I called, the human did the one thing the robot wasn't allowed to do: they listened to me without a script, understood it was a silly exception, and solved it on the spot.
The math is cruel. The company invested in technology to reduce support costs and, in my case, achieved the opposite: it wasted my time, wasted the call I ended up making anyway, and almost made me give up. The chatbot saved nothing. It just pushed the cost forward and left an annoyed customer along the way.
2. Why processes always start from the complex
There's a reasoning habit in people who design processes: the urge to anticipate everything. Map every scenario, every exception, every possible path, and build a huge machine that handles them all. It sounds responsible. In practice, it becomes a maze that serves the most common case poorly in order to theoretically cover the rare one.
The simple is dismissed because it seems like too little. "Putting a button that connects straight to a human" doesn't make for a meeting, doesn't make for a slide, doesn't look like digital transformation. Meanwhile, "deploying a virtual assistant with artificial intelligence" makes for an internal headline. So the company buys the complex, and the customer, who just wanted the one-line answer, pays the bill in lost minutes.
Notice the inversion. The customer had a simple problem. The company answered with a complex solution. And the complexity wasn't serving the customer, it was serving a modernization narrative. Every time a process starts from the complex by default, someone is optimizing for the photo, not for the result.
3. The mistake wasn't using AI. It was using AI for the wrong task
It's worth separating this carefully, because it's easy to read this case and conclude "so AI in support is no good." Wrong conclusion. The mistake wasn't the AI existing. It was placing it as a wall between the customer and the solution, instead of a bridge.
A closed-script chatbot is the laziest way to use AI: it just repeats answers a human registered and blocks anything off script. That isn't intelligence, it's a question tree dressed up as a conversation. Serious AI does the opposite of what happened to me: it understands what the person is really asking for, even when they don't use the right words, solves what can be solved, and recognizes when to call a human instead of hiding that button.
The question that separates good use from bad use is a single one: is this AI here to solve the customer's problem or to avoid the cost of solving it? When the answer is "avoid cost," you build exactly what trapped me for 23 minutes. When the answer is "solve," you build something that, yes, responds in seconds, but responds for real, and knows when to get out of the way.
4. How we design this at Steply
When an operation comes in asking for "I want AI-powered support," the first thing we do isn't choose the technology. It's ask what the shortest path is between the customer's question and the right answer. Sometimes the answer is an AI agent that genuinely solves it. Sometimes it's a silly improvement to the form that eliminates half the questions before they turn into tickets. The criterion is always the same: whatever reduces friction for the person on the other side.
AI comes in when it genuinely shortens the path, not when it becomes yet another pretty obstacle. And it comes in with two non-negotiable rules: it has to know when to pass to a human, and it can never trap the person in a loop. Support that doesn't know how to hand off is support that will cost me 23 minutes and still force me to call.
In the end, the right technology almost always looks simple to whoever uses it. That's the mark of a well-designed process: the complexity stays on the inside, hidden, working, and the outside experience is light. When the complexity leaks out to the customer, in the form of a rigid script and lost minutes, it's because it was placed on the wrong side.
The reframe that sticks
The human agent solved my case in 1 minute not because they were smarter than the machine. They solved it because they had permission to start from the simple: listen, understand, act. The chatbot was forbidden from that by design. The lesson isn't "go back to the phone," it's more uncomfortable: before adding technology, ask whether you're not just repackaging the complex and pushing it onto the customer.
If your company is about to put AI into support, or into any process, that's the test. Start with the simplest solution that solves the most common case. Only add complexity when it pays for its own cost in results for the person on the other side. Well-used AI makes the hard look simple. Badly-used AI turns the simple into 23 minutes.