We have audited a lot of chatbots. Some were built in-house by engineering teams that knew what they were doing. Some were built by agencies that did not. The failures cluster predictably around the same three problems -- and none of them are the problems founders expect.

"Our chatbot worked great in the demo. After launch, users stopped engaging within two weeks."

We hear this constantly. Here is why it happens.

Failure #1: The Scope Problem

Most chatbots are given too broad a mandate. "Answer any question about our product" sounds like a feature. In practice, it is a liability. An LLM asked to answer anything will eventually answer things it should not -- and confidently.

The fix is explicit scope constraints at two levels:

System prompt constraints

Define what the chatbot is and is not allowed to discuss. This is not censorship -- it is product design. A support chatbot that stays focused on support queries delivers a better experience than one that wanders into pricing philosophy and refund policy debates. 

You are a support assistant for Acme SaaS.
Your job is to help users with:
- Account setup and configuration
- Billing questions
- Bug reports and workarounds

If asked about topics outside this scope, say:
"That's outside what I can help with -- let me connect
you to our team." Then trigger a handoff to a human agent.

Retrieval scope constraints

If your chatbot uses RAG, limit the knowledge base to vetted, current content. A single outdated help article producing a wrong answer erodes user trust faster than ten correct answers rebuild it.

Failure #2: No Graceful Degradation

What happens when the chatbot does not know the answer? In most implementations: it makes something up. This is the hallucination problem, but it is also a product design problem.

Every chatbot needs a defined failure path:

  • Low-confidence answer: Surface the answer with a confidence indicator and an offer to connect to a human.
  • Out-of-scope query: Acknowledge the limitation, offer an alternative path (email, calendar link, human chat).
  • System error: Never show a raw error to a user. Log it, show a friendly fallback, notify your team.

Graceful degradation is not a nice-to-have. It is what determines whether a chatbot earns user trust or destroys it.

Failure #3: No Feedback Loop

A chatbot shipped without instrumentation is a chatbot you cannot improve. The teams that build great chatbots are the ones obsessive about measuring what "great" actually means for their users.

Minimum instrumentation for a production chatbot:

  • Thumbs up / thumbs down on every response -- the simplest signal with the highest response rate.
  • Unanswered query logging -- every time the chatbot says "I don't know," log the query. These are your content gaps.
  • Handoff rate -- what percentage of conversations escalate to a human? This is your precision metric.
  • Session completion rate -- did the user get what they came for, or did they leave mid-conversation?

Review these weekly for the first 90 days post-launch. The patterns will tell you exactly what to fix next.

The Chatbot That Works

The best chatbots we have shipped share three characteristics: they know exactly what they are for, they fail gracefully when they reach their limits, and they generate a data stream that makes them measurably better every month.

The chatbot that delights users is not the one with the most sophisticated model. It is the one with the most considered product design around the model.