AI Services
AI chatbots trained on your content
A good chatbot answers like your best employee, instantly and around the clock. We build bots trained on your own content with retrieval, so answers are grounded in facts, with human handoff whenever it matters.
Who it is for: Businesses whose team answers the same questions daily, or who lose enquiries outside office hours.
Everything in this service
- Bot trained on your site, docs and FAQs (retrieval-based)
- Website, WhatsApp or Messenger deployment
- Human handoff rules and escalation
- Lead capture and booking integration
- Accuracy monitoring and monthly tuning
What to expect
- Customers answered instantly at any hour
- Fewer repetitive tickets reaching your team
- Enquiries captured that used to bounce
How ai chatbots actually works
Why chatbots invent answers, and what stops it
A language model on its own is a prediction engine. It produces the text most likely to follow your question, which is not the same as the text that is true. When it has never seen your prices, your delivery times or your cancellation policy, it does not go quiet. It produces something plausible instead, and plausible wrong answers are worse than no answer at all.
The fix is not a better prompt or a stricter tone. It is changing where the answer comes from. A grounded bot searches your own content first, retrieves the passages that actually address the question, and then writes the reply using only those passages. The model still handles the language, but the facts come from documents you control and can point at. When nothing relevant is retrieved, the bot has nothing to write from, and that is exactly the moment it should stop rather than improvise.
This distinction matters commercially. A bot that quotes a price you retired last year, promises a refund window you do not offer, or invents a service you do not sell creates a customer expectation you may have to honour. Grounding is the difference between a support tool and a liability.
- Ungrounded models fill gaps with plausible text, not silence
- Retrieval means the answer comes from your documents, not model memory
- Wrong answers create expectations you may be held to
- Prompt wording alone will not prevent invention
- If nothing relevant is retrieved, the correct behaviour is to stop
How grounding on your own content actually works
The bot needs a knowledge base: your service pages, pricing, policies, help articles, onboarding documents, common email replies. Those get split into passages, indexed so they can be searched by meaning rather than exact wording, and retrieved when a question comes in. The quality of that source material sets the ceiling on the quality of every answer the bot will ever give.
Most of the work in a good build is here rather than in the model. Contradictions have to be resolved, because if two documents state different delivery times the bot will confidently pick one. Out-of-date pages have to be removed rather than left in the index. Internal notes, draft policies and anything commercially sensitive have to be deliberately excluded, since anything indexed can surface to a customer. And content written for humans skimming a page often needs a plainer version, because a paragraph that assumes you can see the pricing table above it makes no sense when retrieved on its own.
We also decide what the bot is allowed to answer at all. A bot with access to everything will attempt everything. Narrowing the scope to the topics you actually want handled, and routing the rest to a person, produces a far better experience than a bot that is technically capable of discussing anything and reliably good at nothing.
- Source quality sets the ceiling on answer quality
- Resolve contradictions before indexing, the bot cannot judge which is right
- Exclude internal, draft and sensitive material deliberately
- Rewrite content that only makes sense in the context of a full page
- Define the topics in scope, and route everything else to a human
Teaching a bot to say it does not know
Saying nothing useful is a feature, not a failure. The behaviour we design for is straightforward: when retrieval returns nothing relevant, or returns material that only partly addresses the question, the bot admits the limit and offers a route forward. It does not apologise at length, and it does not guess.
That behaviour has to be built and tested, not assumed. We write test questions that we know the knowledge base cannot answer and confirm the bot declines rather than improvises. We test near-misses too, which are harder: questions where a document is topically close but factually wrong for the situation, such as a policy that applies to one product being pulled in for another. Those are where confident errors hide.
The response to a gap should still be useful. A dead end reads as a broken bot. An admission plus a booking link, an email capture or a transfer to a person reads as competent handling, and customers judge it accordingly.
- Declining is designed behaviour, not an absence of behaviour
- Test with questions the knowledge base genuinely cannot answer
- Test near-misses, where a related but wrong document is retrieved
- Pair every admission with a next step, never a dead end
- Short admissions read as competent, long apologies read as broken
Designing escalation before you design the bot
Escalation is the part most projects treat as an afterthought and then regret. It needs deciding early, because it shapes what the bot is for. There are two kinds of handoff and they are not interchangeable. Rule-based escalation triggers on topic: complaints, refunds, anything legal or medical, high-value enquiries, existing customers with an account issue. Signal-based escalation triggers on the conversation itself: repeated rephrasing, frustration in the wording, the same question asked twice, or a direct request for a person.
The handoff also needs to work at the human end. A transfer that dumps a customer into a queue with no context makes them repeat themselves, which is the single most reliable way to make a chatbot experience feel worse than no chatbot. The conversation so far, what the customer was trying to do, and what the bot already told them should arrive with the person picking it up.
Out of hours needs its own path. If nobody is available, the honest option is capturing the enquiry with a stated response time and meeting it, rather than implying someone is about to appear.
- Decide escalation rules before building conversation flows
- Escalate on topic and on frustration signals, they catch different cases
- Pass full conversation context to the person taking over
- Never make a customer repeat what they already told the bot
- Give out-of-hours conversations an honest capture-and-callback path
Measure accuracy, not deflection
Deflection rate, the share of conversations that never reach a human, is the metric most chatbot vendors lead with. It is also the easiest metric to improve badly. A bot that answers everything confidently, correct or not, will show excellent deflection while quietly damaging trust. A bot that makes it hard to reach a person will show better numbers still.
The measure that matters is accuracy: of the answers given, how many were correct and complete. Getting that number requires reading conversations. We sample transcripts regularly and grade them, which is unglamorous and the only method that works. Alongside it we track resolution, meaning the customer got what they came for and did not return with the same question a day later, and escalation quality, meaning the handoffs that happened were the ones that should have happened.
Reporting should be honest about the trade-off. Pushing more conversations to the bot and keeping answers correct pull in different directions, and the right balance depends on what a wrong answer costs you. For a booking enquiry that cost is low. For a technical specification or a policy question it is not.
- Deflection alone rewards confident wrong answers
- Sample and grade real transcripts, there is no shortcut
- Track whether the customer came back with the same question
- Review escalations that should have happened and did not
- Set the coverage-versus-accuracy balance by what an error costs you
Keeping the knowledge base current
A chatbot decays. Prices change, services are retired, policies are updated, and the index quietly keeps serving the old version until somebody notices. This is the most common reason a bot that worked well at launch is embarrassing a year later.
The maintenance model has to be decided at build time. Content that lives on your site can be re-indexed automatically on a schedule, so published changes flow through without anyone remembering to act. Content that lives in documents needs an owner and a review date. Either way, someone in your business has to be accountable for the knowledge base, and that person should be told when the bot answers a question badly rather than finding out at the quarterly review.
The other half of maintenance is additive. Every question the bot could not answer is a content gap, and those gaps are the most useful list you will get from the system. They tell you what customers actually want to know, in their own words, which is worth having whether or not you feed it back into the bot. We review those gaps monthly, write the missing answers, and the bot improves as a side effect of your content improving.
- Re-index site content automatically so published changes flow through
- Give document-based content a named owner and a review date
- Treat unanswered questions as a content gap list, not a failure log
- Fix gaps monthly rather than at an annual review
- Retire old documents from the index, do not just add new ones
What to expect in the first three months
The first weeks are the noisiest and the most useful. Real customers ask questions in ways nobody on your team predicted, phrased with typos, missing context and several questions bundled into one sentence. That is normal, and it is the raw material for tuning.
A sensible launch is narrow. Start with the question types you know the bot handles well, keep escalation generous, and widen the scope as accuracy proves out. The alternative, launching with everything switched on and tightening later, means your customers do the testing and some of them do not come back. We also recommend telling customers plainly that they are talking to an assistant and how to reach a person, because the trust cost of pretending otherwise is not worth the small gain.
By month three you should have a stable picture: which questions are handled reliably, which reliably escalate, where the content gaps are, and what the bot is genuinely saving your team. That picture, not a deflection percentage, is the basis for deciding how much further to take it.
- Launch narrow with generous escalation, then widen
- Expect real questions to be messier than your test questions
- Tell customers they are talking to an assistant and how to reach a person
- Use early transcripts to tune wording, scope and handoff rules
- Judge value by team time saved and enquiries captured, not a single rate
A clear path, step by step
- 01
Audit and plan
We check the current state, find what is holding you back, and agree a prioritised plan.
- 02
Fix and build
We make the changes: technical fixes, content, structure and internal links.
- 03
Make it citable
We add the structure and signals that help search and AI engines trust and quote the page.
- 04
Track and improve
We measure rankings, visibility and enquiries each month, then refine.
Why choose us for this
Grounded answers from your content, not model guesses
Escalation to humans built in from day one
We measure accuracy and keep tuning it
Common questions
How is this different from a scripted chatbot?
Scripted bots follow fixed menus and break on anything unexpected. A retrieval-based bot reads your actual content and answers naturally, and it improves as your content does.
What happens when the bot does not know?
It says so and hands off: to email capture, a booking link or a live person, based on rules we set together. It never invents an answer to fill the gap.
Explore related work
Want this for your business?
Book a free visibility call and I will tell you honestly whether I can help.
How this is delivered
One person leads every project. Where a job genuinely needs a specialist, I bring in people I have worked with before and manage them, so you get one point of contact and one invoice rather than three suppliers blaming each other.
- You talk to the person responsible for the work, not an account manager
- Specialists are briefed and managed by me, and their work is checked before it reaches you
- One contract, one invoice, one place to chase