Chatbot for business: when it works, when it fails

Almost everything you will read about business chatbots is written by someone who sells chatbots. We do not sell licences for anything, so we can afford to say what usually goes unsaid: of the three kinds of chatbot people ask us for, the most requested one performs worst, and the one with the best return is the one almost nobody asks for.

In our guide to AI process automation we list it outright as a mistake: starting with the chatbot is the flashiest move and usually the lowest return. That does not mean it never pays. It means you need to know which of the three you are building, and what for.

The three kinds, and why they get confused

When someone says “we want a chatbot”, they could mean three very different things, with costs and success rates that have nothing in common.

The customer service one. Public-facing, answering questions from people who are already customers. Medium risk, medium return.

The sales one. Public-facing, capturing and qualifying visitors who do not know you. The most requested, and the worst performing.

The internal one. Facing your own team, answering questions about your documentation: procedures, pricing, terms, project history. The least requested, and by far the best return.

The confusion is expensive because all three are built similarly but fail for different reasons.

Real scenarios we run into

First-line customer service

This works when you have a high volume of repeated questions and a source of truth you can maintain: shipping terms, order status, how to reset a password, what the warranty covers.

What decides the project is not the model — it is the handoff to a human. A chatbot that resolves 60% and passes the remaining 40% along with the full context already gathered — who they are, what they asked, what they tried — is an outright success. One that resolves 80% and leaves the other 20% trapped in a loop with no exit is a customer-service disaster, even though the big number looks better in the report.

Where it breaks: the confident wrong answer. The model invents a warranty condition that does not exist, the customer takes it at face value, and you have a contractual problem. That is why a service chatbot is built on your real documentation, with an explicit instruction to say “I do not know, let me pass you to someone” rather than improvise. It sounds obvious, and it is what almost nobody configures.

The sales one: most requested, worst outcome

The typical brief is “have it talk to the visitor, understand what they need and qualify them for me”. It sounds good. In practice it hits two realities.

The first is that a visitor who does not know you does not want to chat. They want to see what you do, what it costs and who you are. A widget that pops up after three seconds asking “how can I help?” adds friction to someone who was reading quite happily.

The second is that conversational qualification works badly when nobody has written down what a good lead is. If the criteria live in the sales director’s head, the model will not guess them. Before building the chatbot you have to write that definition down — and once written, you often realise a well-designed four-field form does the same job, with no risk and a tenth of the effort.

Our honest recommendation for most B2B sites: improve the form and the page, and leave the sales chatbot until you have enough volume for the conversation to add something.

The internal one over your documentation: the one that pays

This is the one almost nobody asks for, and the one that gives hours back from month one.

You have procedures, pricing, contract terms, minutes, technical documentation and project history spread across network drives, cloud storage and email. Every time someone new needs to know “what margin do we apply to this kind of job?” or “what did we say about deadlines in last year’s tender?”, they interrupt the person who knows.

An assistant that searches that documentation and answers citing where it got it from turns a fifteen-minute interruption into twenty seconds. And here hallucination matters far less, because the user is your own team: they know to be sceptical and can open the cited document to verify.

Where it breaks: disorganised or outdated documentation. If you have three versions of the price list and none of them says which one governs, the assistant will confidently give you one of the three. The real work in this project is not the chatbot — it is tidying the source.

What it actually costs

The cost everyone looks at is the model, and it is the one that matters least. Processing a conversation with a commercial model is measured in cents; at SME volume, it is noise on the P&L.

The three costs that actually decide:

Setup. Connecting your sources, preparing the documentation, defining scope and building the handoff. This is most of the invoice, and it is engineering work, not configuration.

Maintaining the knowledge base. This is the one that sinks projects. A chatbot is only as good as the documentation it reads, and documentation ages. If nobody is assigned to maintain it, within six months the assistant is quoting last year’s prices. Before starting, answer this: who updates this, and when?

Initial supervision. For the first few weeks someone has to read real conversations and correct. It is not optional, and it has to be budgeted.

How we measure whether it works

The metric you will be shown is “conversations handled”. It is useless: it counts the ones that ended badly too.

We look at three others. Resolution without escalation: of the queries that came in, how many ended resolved without a human. Handoff quality: of those that did escalate, how many arrived with full context, without the customer having to repeat themselves. And wrong-answer rate, measured by hand on a real sample every week, because no tool will hand you that one.

If a chatbot resolves little but escalates flawlessly, it is a good project. If it resolves a lot and escalates badly, you have a problem that has not shown up in the report yet.

Mistakes worth avoiding

• Building the chatbot before tidying the documentation. It is the equivalent of automating on dirty data: the assistant broadcasts your contradictions in a confident voice.
• Not configuring “I do not know”. A model with no explicit permission to admit ignorance will always prefer to invent something plausible.
• Letting it write to customers unreviewed on contractual matters. Prices, warranties, deadlines and terms: the saving there is small and the risk is not.
• Measuring conversations instead of resolutions. The number goes up and the customer is still annoyed.
• Starting with the sales one because it is the most visible. It has the worst return of the three.
• Not assigning who maintains the knowledge base. With no named owner, the project degrades on its own within six months.
• Forgetting that conversation logs are personal data. They fall under data-protection rules: you have to decide what is stored, for how long, and where it travels. We cover it in GDPR and AI: what happens to your data in an LLM.

How we approach it

We start with an uncomfortable question: what happens to these queries today? If the volume has never been measured, there is no project to justify. If it has, we pick one of the three kinds — usually the internal one, unless the data says otherwise — scope it to a concrete domain rather than “answer everything”, and build the human handoff before anything else.

Then we measure for a few weeks with human supervision over real conversations, and only then widen the scope. It is slower than plugging in a widget, and it is why the result is still standing in year two.

Closing

At LMNHUB we build conversational assistants when the numbers justify it, and we say so plainly when they do not. We sell no licences and charge nothing per conversation, so we have no incentive to convince you that you need one.

If you are weighing up a chatbot for your company, tell us about your case and we will tell you honestly which of the three fits — or whether your problem is better solved another way.