Chatbot

A chatbot is an interface through which people talk to a system in conversation form. The word says nothing about the technology behind it and nothing about the quality. It describes the shape of the interaction, not the capability.

What kinds of chatbot are there?

Three generations are running side by side today, which explains most of the confusion.

Rule-based: a decision tree with buttons. Reliable inside its paths, helpless outside them. These are the bots behind the widespread experience that chatbots are useless.

Intent-based: trained categories with pre-written answers. Recognises known requests, fails on unknown ones, and needs continual maintenance of the categories.

Model-based: a large language model composes the answer freely. Far better linguistically, but without a connection to your data, also far freer with the facts.

What makes a chatbot useful

Not the model, the access. A bot that knows the order status is useful. One that responds to order-status questions with polite generalities is more irritating than none at all.

What is useful is the combination of three things. Knowledge from your documents, connected through RAG, so answers can be verified. Access to systems, where answers have to be case-specific. And a route to a human that opens early rather than as a final dead end.

That handover point drives how the bot is perceived. One that escalates promptly when uncertain is experienced as helpful. One that insists on answering at all costs produces the experience that gave the word its reputation.

Chatbot or agent?

The terms get mixed up, vendors included. A chatbot answers within a conversation. An AI agent completes a task, often with no chat at all, triggered by an event such as an incoming email, and leaves a result behind in a system.

In practice: if people want to ask and read, you need a chat interface. If work needs doing, you need an agent, and the interface becomes a side issue.

Anyone sceptical after a disappointing chatbot rollout usually had the right experience and drew the wrong rule from it. What failed was rarely the language ability. It was almost always the missing access to the systems where the answer actually lives.

One workable scope and one unworkable one

An example makes the difference concrete.

Unworkable: "a chatbot for our website that answers customer questions." The scope is unbounded, there is no definition of success, and evaluation ends in matters of taste. Projects like this are almost always remembered as a disappointment, because nobody said in advance what good enough would be.

Workable: "an assistant in the customer portal that answers questions about delivery status, invoices and opening hours, has access to the order system for that, and hands everything else to the service team." The scope is named, the access is settled, the handover is part of the requirement, and success can be counted.

The second scope also produces an honest metric: the share of conversations closed without a handover, together with satisfaction in exactly those conversations. Either number alone can be massaged. Both together cannot.

In practice this is the same scoping discipline as an AI pilot: one process, one integration, one number.