Short answer: You keep a chatbot on topic with three layers working together — a system prompt that hard-scopes it to your business, retrieval that only supplies passages from your own content, and an explicit refusal behaviour for anything outside that scope. Any one layer alone leaks. All three together make off-topic answers rare and boring to attempt.
This matters more than it sounds. A widget that will write someone's homework is a widget that is costing you money and, when screenshotted, reputation.
Why chatbots drift in the first place
A general-purpose language model is trained to be helpful about everything. Left unconstrained, being helpful about everything is exactly what it does. Ask a plumbing company's chat widget for a lasagne recipe and an unscoped model will give you one, cheerfully, in your brand tone.
Drift has three common causes. The instructions are too vague — "you are a helpful assistant for Acme Plumbing" invites helpfulness generally. The retrieval step returns nothing and the model falls back on its own general knowledge to fill the silence. Or a visitor deliberately steers it, which is a different problem covered under prompt injection.
Layer one: scope it explicitly in the instructions
The instruction layer is not a personality blurb. It is a boundary definition. A good scope statement names what the assistant covers, names what it does not, and states what to do at the edge.
In practice that means specifying the business and its domain, listing the categories it should decline — general knowledge, other companies, medical or legal advice, anything requiring an opinion the business has not published — and defining the fallback sentence it uses when declining. The more concrete the decline behaviour, the less the model improvises.
Clerkzo applies this scoping by default rather than leaving it to you to discover. The widget is hard-scoped to the business it was installed for, and off-topic requests are refused rather than answered.
Layer two: ground every answer in retrieved content
Scoping tells the model what not to do. Grounding removes the raw material for doing it.
Because answers are built from passages retrieved out of your own knowledge base, the model is working with your text rather than its memory. When someone asks about a topic you have never published on, retrieval returns nothing relevant, and a properly configured system treats an empty retrieval as a reason to decline rather than an invitation to improvise. That is the single most effective anti-drift mechanism there is, and it comes free with retrieval-augmented generation done properly.
The failure mode to watch for is a system that retrieves weak matches and uses them anyway. If someone asks about crypto and your site has a page mentioning "investment," a naive system may retrieve it and produce something confidently wrong. Relevance thresholds exist to stop that.
Layer three: make refusal graceful
A refusal that reads like a slammed door costs you goodwill. A good one does three things: declines briefly, does not lecture, and redirects to something useful.
"That is outside what I can help with, but I can answer anything about our services, pricing or availability — or put you through to the team" does the job. It is short, it is not preachy, and it hands the visitor a next step.
The redirect matters because a share of off-topic questions are actually badly phrased on-topic questions. Someone asking a vague general question often has a specific need underneath it. Offering the real options surfaces it.
The adjacent-topic problem
The hard cases are not lasagne recipes. They are questions that sit next door to your business.
A dental practice gets asked whether a symptom is serious. A law firm gets asked what someone should do about their landlord. A gym gets asked about a diet. These are on-topic in subject and off-topic in authority — answering them means giving professional advice through a chat widget, and no business wants that liability.
The right handling is a scoped decline plus a route to a human: acknowledge the question, explain that specific advice needs a person, offer the booking or handoff. This is where human handoff stops being a support feature and becomes a risk control. Clerkzo includes handoff on every plan for exactly this reason.
How to find your drift, not guess at it
You cannot tune a scope you have not observed. Every conversation is saved, and reading them is the whole method.
Look for three patterns. Answers that wandered outside your business. Refusals that should have been answers — a legitimate customer question rejected because your content did not cover it. And thin answers where the model clearly had little to work with.
The first pattern is a scoping fix. The second and third are content gaps, and the correction loop closes them fast: flag the answer, type what it should have said, and your version becomes an authoritative override for that question going forward.
Test changes before shipping them. A playground that mirrors the live widget lets you attack your own scope — try the recipe question, the competitor question, the medical-adjacent question — and see what a visitor would actually get. Walk through the setup on how it works if you want to see where each control lives.
What good scoping is not
It is not keyword blocking. Banning a word list is trivially evaded and blocks legitimate questions that happen to contain the word.
It is not an enormous instruction document. Past a point, more rules dilute the ones that matter. A tight scope with clear decline behaviour beats a three-page policy.
And it is not a one-time setup. Your business changes, and the boundary should change with it. A monthly read of flagged conversations is enough for most.
Frequently asked questions
Will strict scoping frustrate real customers?
Only if the scope is drawn too tight. Scope by subject, not by phrasing, and always pair a refusal with an offer to reach a human.
Can visitors talk it out of its instructions?
They will try. Defence comes from layered design — instructions plus grounding plus refusal behaviour — not from one clever sentence in the prompt.
What should it do when a question is half in scope?
Answer the part it can support from your content, be explicit about the part it cannot, and offer a handoff for the rest.
Does scoping hurt lead capture?
The opposite. A widget that stays on your business and routes edge cases to a person produces more usable conversations than one that free-associates.