The request behind the request is rarely a model

A head of support at a B2B SaaS company came to a planning meeting with a clear ask. She wanted an AI chatbot on the help center. Leadership had approved it. The budget was there. The only thing left, in her mind, was to pick a vendor and ship it.

Someone in the room asked a question that slowed everything down. Why a chatbot? Not to challenge her, just to understand. What is the chatbot supposed to fix?

She had a good answer, and it had nothing to do with chat. Her team was drowning in the same handful of tickets. The same password-reset confusion. The same billing question about proration. The same “where do I find my API key.” Her agents answered these all day, and every answer was a small tax on people she would rather have solving hard problems. The chatbot was her plan for making those tickets go away.

That is the request behind the request. She asked for a chatbot. What she wanted was fewer repeat tickets. Those are not the same thing, and the gap between them is where most AI projects quietly go wrong.

The stated ask is a solution, not a need

People rarely bring you a problem. They bring you their best guess at a solution, already wrapped in a technology they read about. “We need an AI chatbot” is a solution. “We need a recommendation engine” is a solution. The job of discovery is to unwrap it and find the need underneath, because the need often points somewhere the solution does not.

When we listed her top repeat tickets and looked at each one, the picture got interesting. The proration billing question was not a knowledge problem. The answer was already in the help center. People could not find it because the article was buried and the invoice did not link to it. A chatbot would have answered that question well, but so would a link on the invoice, and the link would never hallucinate a wrong number about someone’s money.

The password confusion was a product problem. The reset flow sent people to a page that looked broken on mobile. No chatbot fixes a broken page. It just apologizes for it more fluently.

Only a couple of the repeat tickets were genuinely open-ended enough that an AI answer would have helped. And for those, the honest scope was narrow. Answer these specific question types, from these specific docs, and hand off to a human the moment it drifts.

A product manager at a marketplace once described the same trap from her side. Her sales team asked for “AI-powered search.” What they wanted was for a few high-value sellers to stop churning because buyers could not find their listings. That was a merchandising and ranking problem for a specific segment. The phrase “AI-powered search” would have sent a team off to build something ten times larger than the actual need.

Discovery is subtraction, not addition

The instinct when someone asks for AI is to figure out how to build the thing they named. Better discovery does the opposite. It keeps asking what the thing is for until the real job is visible, and then it asks whether AI is the cheapest way to do that job. Often part of the job is not AI at all. It is a link, a fixed page, a better default. McKinsey’s 2025 work found that roughly 70 percent of enterprise AI use cases are served well enough by off-the-shelf tools, and a chunk of the rest turn out not to need a model when you look closely.

The support lead did not build the chatbot she walked in asking for. She fixed the invoice link, repaired the reset page, and pointed a small AI assistant at the two ticket types that were actually open-ended. The repeat volume fell because she solved the job, not the request.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week engagement priced at $2,500, we treat the first request as a symptom, not a spec. We trace it back to the job the business is actually trying to get done, then sort that job into the parts a model should handle and the parts a link or a fix handles better and cheaper. Clients sometimes arrive certain they need to build, and leave having scoped something a third the size that does more of what they wanted.

When someone asks you for a model, do not start designing the model. Ask what would have to be true for them to stop wanting it, and build that instead.