← all posts
00opinion

When NOT to build an AI chatbot (and what to build instead)

Chatbots are the default AI build for businesses, and the default is often wrong. Here's when a chatbot is the right call, when it isn't, and what the better alternative looks like.

May 22, 2026~6 min readby Amine Hn

When a business decides to "do AI," the first build they reach for is almost always a chatbot. It's the most visible AI surface — there's a widget, a name, sometimes an avatar, and a CTA on the homepage. Building one feels like progress. The board sees it. The team gets to demo something.

The problem is that chatbots are the right answer for a narrower set of problems than the default suggests, and getting this wrong is expensive — both in build cost and in the brand cost of a half-working chatbot sitting on your homepage. This post is about when the chatbot is the right call, when it isn't, and what to build instead.

When a chatbot is the right answer

There are three deployment shapes where chatbots reliably earn their keep:

Inside the product, behind authentication, with account context. A logged-in user can ask the chatbot about their account state — billing, plan, usage — and the agent has the data to answer accurately. This is where you see 50-65% tier-1 deflection in the wild. It works because (a) the user is already in your product, (b) authentication means the agent knows who they are, and (c) the alternative is opening a support ticket, which the user wants to avoid as much as you do.

Internal docs Q&A. A chatbot trained on your Notion, Confluence, Google Drive — answering employee questions about policies, procedures, who-owns-what. Off-the-shelf options (Glean, Mendable) cover most cases; custom builds make sense when you have unusual data or compliance requirements.

Lead qualification on inbound traffic. A chatbot on the pricing or contact page that asks 3-4 qualifying questions before routing to sales. Best when inbound lead volume is too high for sales to triage manually, and where the questions are structured enough to capture meaningful intent.

That's it. Three shapes. If your use case doesn't map cleanly to one of those, the chatbot probably isn't the right build.

When a chatbot is the wrong answer

The chatbot is the wrong answer when:

The customer doesn't naturally engage in chat for this need. Some workflows just don't fit a chat interface. Appointment scheduling for a healthcare practice — patients call. They don't open the website to chat. Building a chatbot for an appointment-scheduling problem in a category where customers don't naturally engage is building a tool nobody uses. A voice agent that calls them is the right answer; the chatbot just sits idle.

The workflow could run silently in the background. A lot of "we need a chatbot" projects are actually intake or routing problems. The customer fills out a form, sends an email, makes a call. None of those need to become a chat conversation. They need to be processed — categorized, enriched, routed, replied to. A workflow agent does this faster and without requiring the customer to engage with a new interface.

The 'support questions' it would answer are actually product questions. Sometimes the volume of tier-1 tickets reveals a UX problem. People keep asking how to do X because X is hidden or confusing. The right build is to fix the UX, not to build a chatbot that explains the UX over and over. Always ask: are these questions about HOW to use my product, or are they revealing that my product is hard to use?

The org isn't ready to maintain it. A chatbot at launch is mediocre. A chatbot four weeks post-launch, with eval data and edge-case fixes folded in, is excellent. If nobody on your team is going to look at the chatbot's conversations weekly, the chatbot will not get better — it'll get worse as your docs drift. This is the silent killer of chatbot projects. Don't build one if no one is going to own it.

What to build instead

In most of these "not-actually-a-chatbot-problem" cases, the better build is a workflow agent — an AI system that runs in the background, taking action on documents, emails, calls, or data, without requiring a customer to engage with a chat interface.

Concrete examples we've shipped where a chatbot was the wrong call:

Email triage and routing. A team that was considering a chatbot for "support that customers email about" instead got a workflow agent that categorizes inbound emails, drafts replies for tier-1 cases (queued for one-click human approval), and routes the rest. Customer experience: same as before, just faster replies. Team experience: 70% of inbound emails handled with one click of human review.

Appointment confirmation and rescheduling. A dental group considering a website chatbot for booking instead got an outbound voice agent that calls patients to confirm appointments, fill cancellations, and book waitlist patients into open slots. The customer was never going to use a website chatbot — they were on their phone, in their car. The voice agent met them where they were.

Invoice intake and categorization. A finance team considering a chatbot for "vendor questions about invoices" instead got a workflow agent that processes incoming invoice PDFs, extracts line items, categorizes them against the chart of accounts, and queues exceptions for human review. The "chatbot" question was a misframing of an intake problem.

Sales prospecting at scale. A recruiting firm considering a chatbot for inbound questions instead got an outbound workflow that drafts personalized prospecting emails for the recruiter's review. Same underlying capability (LLM doing language tasks), much higher-leverage deployment.

The decision rule

A simple test before you commit to a chatbot build:

  1. Is there a customer-initiated chat interaction where the customer would benefit from a fast answer? If no, you don't need a chatbot.
  2. Does the agent need account context to be useful? If yes, you need a logged-in-only chatbot (good fit). If no, you might be better off with a workflow agent.
  3. Will someone on your team review chatbot conversations weekly for the first three months? If no, don't build one yet.
  4. Are you trying to solve a "customers ask too many questions" problem or a "we receive too much work" problem? The former might be a chatbot. The latter is almost certainly a workflow agent.

If three of those four point away from a chatbot, build something else.

Why this matters for SEO and brand

There's a subtler reason chatbots are over-built: they're the most visible AI artifact, and visibility is what most boards reward. "We launched AI" looks like a chatbot widget on the homepage. The marketing team loves it.

But a half-working chatbot on the homepage is worse than no chatbot at all. It's brand cost — the customer engages, gets a confidently-wrong answer, walks away with a lower opinion of your product. The silent workflow agent has none of this brand risk because the customer never sees it. The only thing they notice is that the response time got faster or the experience got smoother.

Build the chatbot when you actually need a chatbot. Build the workflow agent when you actually need a workflow agent. The two are not interchangeable, and they're not the same project.

If you're trying to figure out which one your business actually needs, send us the operation and we'll come back with a written audit recommending one, the other, or neither.

·FAQ

Frequently asked.

When is an AI chatbot the right choice?
When you have a high-volume, repetitive support or sales conversation pattern where the customer initiates and an LLM-grounded retrieval over your docs would resolve the request. Best fit: inside-the-product tier-1 support, internal docs Q&A, lead qualification on inbound forms. Worst fit: anything where the customer doesn't naturally engage in chat, or where the workflow runs better as silent automation behind the scenes.
What should we build if a chatbot isn't right?
Almost always, the answer is a workflow agent that runs in the background — taking action on documents, emails, calls, or data without needing a customer to engage with a chat interface. Examples: an inbox triage agent that routes incoming emails, an invoice categorizer that processes attachments overnight, an appointment confirmation voice agent that calls out instead of waiting for inbound chat. These get adopted faster because they don't require behavior change from the customer.
What's the most common chatbot mistake?
Building one when the actual problem doesn't involve customers wanting to chat. Most 'we need a chatbot' projects we audit could ship 70-90% of the value as a workflow agent that the customer never sees — silently processing the same intake the chatbot would have asked about, but faster and without the friction of a chat interface. Always ask: does this workflow need the customer to engage, or just the customer's data?
06The discovery offer

Send us your most expensive operation.
We'll have an audit on your desk in five days.

One PDF. No deck. No obligation. We'll tell you whether AI is the right answer for it — and if it is, we'll quote the build the same week.