Chatbots that know your business and admit when they do not

Why most chatbots fail and what we do differently

The old generation of chatbots failed because they matched keywords against a script. If the visitor phrased something unexpectedly, the whole conversation collapsed. Language models solved that problem completely and introduced a new one, which is that a model left to its own devices will answer confidently even when it has no idea, and a confident wrong answer about your refund policy is worse than no chatbot at all.

Our approach is grounding. Rather than relying on whatever the model absorbed during training, we index your genuine material, meaning policies, product information, manuals, common questions and where appropriate your live records. When somebody asks a question, the system retrieves the relevant passages first and requires the answer to be based on them, with the source available so anybody can verify it.

Alongside that we define what happens when the retrieval finds nothing useful. The assistant says it does not have that information and offers a route to a person, rather than improvising. That single behaviour is the difference between a tool your team trusts and one they quietly ask you to remove.

Knowing when to hand over to a human

A chatbot should be judged partly on how gracefully it gives up. We build escalation paths that trigger on low confidence, on repeated failed attempts, on any hint of frustration in the conversation, and immediately whenever somebody asks for a person. When it hands over, it passes the whole conversation so the customer never has to explain twice, which is the most infuriating part of most automated support.

Some topics should never be automated at all. Complaints, cancellations, anything involving money owed and anything touching a vulnerable situation are routed to a person by rule rather than by the model deciding. Those boundaries are agreed with you during design and enforced in code.

Learning from what people actually ask

Every conversation is logged, and those logs are the most valuable output of the whole project. Within a fortnight you will know exactly what your customers or staff ask most often, which questions the assistant answers well and which it consistently fails. That information routinely leads to better website content, clearer policies and improvements to the product itself.

We review the logs with you after launch, identify the gaps and improve the underlying material rather than only adjusting the assistant. A question the chatbot cannot answer is usually a question your website answers badly too.

Where we build them

Assistants can live on your website, inside a customer portal, within an internal system for staff or in a messaging channel your organisation already uses. The most valuable deployments we see are frequently internal rather than public, because staff questions about policy, process and precedent consume an enormous amount of senior time and are answered from documents that already exist.