the experience was a faiThe AI market is moving at a pace I haven't seen before.

Vendors are packaging agentic use cases faster than customers can evaluate them. Customers are signing off on AI roadmaps driven more by competitive anxiety than clarity of purpose. And somewhere in that mutual rush—in the demos, the decks, the proofs of concept—one stakeholder has gone completely missing.

The customer's customer.

I call this the customer's customer problem—and it is the most common design failure in enterprise AI today. We are so focused on selling to the buyer and impressing the decision-maker that we forget to ask who the buyer's organization actually serves. And it is that person—the end user, the employee, the human on the other side of the workflow—whose experience will ultimately determine whether the AI investment was worth it.

We're solving the wrong problem

Walk into most enterprise AI conversations today and the use case framing sounds something like this: "We'll deploy an AI agent to auto-resolve L1 tickets, reduce MTTR and free up your service desk team."

It's a compelling pitch. The metrics are real. The technology works.

But here's the question nobody is asking: Why are those L1 tickets being raised in the first place?

The buyer in the room is the IT leader or the CIO. The problem being solved is their problem—agent utilization, ticket volume, cost per resolution. These are legitimate problems. But they are one level removed from the person whose experience actually determines whether the investment was worth it.

That person is the employee trying to get their laptop fixed before a client call. The new joiner who can't access three systems on their first day. The finance analyst whose approval workflow has been stuck for 48 hours.

These are the customer's customers. And most agentic use cases being sold today are not designed around them.

What happens when you go one level deeper

Let me paint a picture you've probably lived yourself.

An employee's laptop crashes an hour before a client presentation. Stressed and short on time, they open the IT self-service chatbot and type: "my laptop isn't working." The bot responds: "Please select a category." They pick Hardware. It returns a list of seven knowledge base articles. None of them apply. They rephrase. The bot loops back to the same articles. They try again, this time more specific—and the bot asks them to raise a ticket.

Three minutes in, they give up. They pick up the phone, wait on hold and explain everything from scratch to a human agent—arriving at their client call flustered and five minutes late.

The AI agent technically functioned. It classified the query. It returned results. By every backend metric, it performed. But the experience was a failure—because nobody designed it around what that employee actually needed in that moment.

This is the gap between building AI and designing it. And it shows up everywhere.

There's a meaningful difference between two versions of the same use case.

Version A: An AI agent that intercepts incoming queries, classifies them, attempts auto-resolution using knowledge base articles and escalates when confidence is low. Faster resolution. Lower cost. Measurable.

Version B: An AI agent designed after actually watching employees interact with the chatbot—noticing they abandon conversations within 90 seconds when responses feel generic and that peak frustration happens on Monday mornings and the day after system updates. This agent is built to understand context, recover gracefully when the first response doesn't land and offer a warm human handoff before the user gives up. It doesn't just resolve, it earns trust.

Version A is built around the buyer's metric. Version B is built around the end user's emotional reality. Both use the same underlying technology. The difference is entirely in how the use case was designed.

Version B is what happens when you apply design thinking. And the chatbot story is the perfect lens to show exactly how.

This is exactly what design thinking is for

Design thinking isn't a new idea. But applied to Agentic AI use case development—using the chatbot experience as our thread—it becomes a discipline that most of the market is skipping entirely.

Here's what it looks like in practice:

Empathize—with the user, not the system. You don't just interview the IT manager about ticket volumes. You sit with the employee. You watch them type into the chatbot in natural language—"my VPN keeps dropping"—and you observe them hit a wall when the bot asks them to select from a category list they don't relate to. You notice they abandon the conversation within 90 seconds. You learn that peak frustration happens on Monday mornings and after every system update. None of this appears in any dashboard. You only find it by watching real people in real moments.

Define—the real problem statement. The problem isn't "we need a better chatbot." After empathizing, the real problem statement becomes: "Employees under time pressure need instant, conversational resolution—not a digital version of a paper form." That one reframe changes everything. It shifts the design from a query-classification system to a stress-aware, context-sensitive experience. Now the agent has a job worth doing.

Ideate—the right level of autonomy. Not every problem needs a fully autonomous agent. Here, the Ideate stage might reveal that full resolution isn't even the priority but speed to human is. The right design could be an agent that detects frustration signals early (repeated rephrasing, short responses, silence), acknowledges them conversationally and offers a warm handoff to a human agent before the user gives up and picks up the phone. That's a design decision. Without ideation, you'd never make it deliberately.

Prototype—map the conversation, not just the logic. Before you configure a single flow, map the experience from the user's emotional state—not the system's decision tree. What does the agent say when the first response doesn't land? How does it recover without sounding robotic? What's the handoff moment and does it feel seamless or like a failure? Test it with real employees before go-live. A paper prototype of the conversation flow will surface more design flaws than three sprints of development.

Test—measure what the user felt, not just what the system did. Most agent evaluation stops at resolution rate: Did it answer the query? Design thinking asks the harder question: Did the user feel heard? Did they abandon mid-conversation? Did they still pick up the phone afterwards? If people are still calling the helpdesk, the agent hasn't succeeded—regardless of what the backend metrics say. Abandonment rate, sentiment signals and post-interaction channel behavior are the real scorecards.

What happens when you skip this

Skip design thinking and you get a predictable outcome: high initial enthusiasm, moderate adoption and disappointing ROI that nobody wants to talk about publicly. The organizations buying AI on FOMO will have a reckoning in 12 to 18 months—not because the technology failed, but because the use cases were never designed around the people who had to live with them.

The chatbot that loops. The agent that escalates too late. The workflow that saves the IT team time but infuriates the employee on the other end. These are not technology failures. They are design failures. And they are entirely avoidable.

Slowing down to design is not a competitive disadvantage right now. It is the competitive advantage. The organizations that get this right will have the reference stories. Everyone else will have the lessons learned.

One question that changes everything

You don't have to overhaul your entire sales or delivery process to apply this thinking. You just have to add one question to every agentic use case conversation:

Who is your customer's customer—and what do they actually need?

That question will stop a feature conversation in its tracks. It'll redirect the room from what AI can do to what the end user actually needs to feel. It'll surface the design work that nobody budgeted for—and that nobody can afford to skip.

The vendors who win the next two years will not be the ones who moved fastest. They will be the ones whose use cases worked—because someone paused long enough to ask that question before anyone wrote a single line of automation logic.

Design before you deploy. Your customer's customer is counting on it.