When AI isn't the answer

A team came to us last spring wanting to add a large language model to their support workflow. Tickets were piling up; AI felt like the obvious lever. We spent a day with their data before writing a line of code.

The bottleneck wasn't reading tickets. It was that three of the five most common requests had no self-serve path at all, so customers opened a ticket for things a help page could have answered. The highest-leverage fix was a handful of documentation pages and one settings toggle. No model required.

Why we lead with "do you need this?"

AI is genuinely transformative in the right place, and a distraction in the wrong one. Telling those apart is most of the value of an advisor. We ask a few questions before anyone reaches for a model:

• Is the problem actually understanding language, or is it a missing workflow wearing a language costume?
• What's the cost of a wrong answer, and who catches it? That single question rules a lot of use cases in or out.
• Could a simpler system — rules, search, a better form — get you 80% of the value at 5% of the risk?

The advice is the product. If the honest answer is "don't build this," that's the answer — and it's usually the cheapest one we'll ever give you.

What this isn't

It isn't AI-skepticism. We build with these models every week, and when the fit is real we'll push hard to do it well. It's just that we'd rather earn a long relationship by being right than win a big invoice by being agreeable.

That support team did eventually ship an AI feature — six weeks later, aimed at a problem that actually needed one, on top of a workflow that finally made sense. It worked because it wasn't trying to paper over something simpler.