AI chatbot development

What separates a useful chatbot from a liability

There are two failure modes. The old one is the decision-tree bot that offers four buttons, none of which describe your problem. The new one is a language model with no grounding that answers fluently and sometimes wrongly. The second is worse, because a wrong answer delivered confidently gets believed.

The fix for both is the same idea: the bot should only be able to say things that are written down somewhere you control, and it should tell you where it got them.

Grounding, and why it is not optional

A grounded chatbot retrieves the relevant passages from your own documentation, policies and product information, and answers from those. If the retrieval finds nothing relevant, the honest answer is that it does not know, followed by an offer to fetch a human.

This has a second benefit people underestimate. Because every answer traces to a source, you can audit the bot. Somebody complains that it said the wrong thing? Look at the conversation, see which passage it used, and either fix the passage or fix the retrieval. Without grounding, your only lever is rewording a prompt and hoping.

Honest escalation

A bot that will not hand over is worse than no bot. Escalation should trigger on low retrieval confidence, on explicit request, on repeated failure to resolve, and on any topic you have flagged as human-only, which for most businesses includes complaints, cancellations and anything involving money.

Critically, the handover carries the full conversation. Making a customer who has already explained their problem explain it again is the single fastest way to make the bot a net negative for satisfaction.

What I build

The content layer

Most chatbot projects are actually content projects wearing a disguise. The bot can only be as good as what it retrieves, and most businesses discover during this work that their documentation contradicts itself, is out of date in three places, or never covered the questions customers actually ask.

I start by pulling the real questions out of your support history, checking whether each one is answerable from existing material, and flagging the gaps. Fixing those gaps improves your human support at the same time.

Retrieval that works on real questions

Customers do not phrase questions the way documentation is written. They use your product’s nickname, they describe symptoms rather than features, and they misspell things. Retrieval has to handle that, which means testing against real phrasings rather than against the headings in your help centre.

Scope boundaries

The bot gets an explicit list of what it will not discuss. Not because the model cannot generate an answer, but because you do not want it to. Legal questions, medical advice, pricing negotiations, competitor comparisons. It declines and offers a person.

Conversation review

Every conversation is logged and reviewable. In the first weeks I go through them with you, because that is where the real requirements are. You find questions you never anticipated, retrieval failures on phrasings you would not have guessed, and usually two or three gaps in your documentation that were also costing your human team time.

Where a chatbot is the wrong answer

If your support volume is low, a bot is a lot of machinery to save a small number of replies. If most enquiries need account-specific action rather than information, you need integrations more than you need a bot. And if your documentation genuinely does not exist yet, write it first: a grounded bot with nothing to ground on is just an expensive way to say “I do not know”.