Skip to content
Chatbotscape
Editorial flat-vector illustration for How to Handle Off-Topic Questions in Your Chatbot
Published 7 min read

How to Handle Off-Topic Questions in Your Chatbot (Without Annoying Customers)

Quick answer: Write down what the bot is for and what it is not for. Give it one short, friendly refusal that names what it can do and offers a person. Put the boundary in the prompt, then add a check that does not rely on the prompt alone, such as a guardrail topic or a small classifier. Send sensitive questions to a human. Test with both off-topic messages (should be declined) and normal ones (should be answered), because tightening one error loosens the other.

Step 1: Write the scope in one paragraph

You cannot enforce a boundary you have not written. Draft three short lists:

  • In scope: what the bot answers, such as orders, delivery, returns, product questions, booking changes.
  • Out of scope, polite refusal: unrelated requests like poems, homework, general trivia, code, opinions on news.
  • Out of scope, hand to a person: anything with risk or emotion, such as legal, medical or financial advice, complaints about staff, safety issues, and anything about a competitor's prices you cannot verify.

Have someone outside the project read the lists. Disagreements show where the boundary is fuzzy. If your business has a legitimate gray area, decide it now; for example, a pharmacy bot may answer opening hours but not dosage questions. Your chatbot scripts and content strategy should match the same list.

Step 2: Write the refusal

A good refusal is short and does three things: says what the bot cannot help with, says what it can, and offers a way forward. Compare:

  • Poor: "I cannot answer that."
  • Better: "That is outside what I can help with here. I can check an order, change a booking or answer questions about our products. Would you like one of those, or should I get a person?"

Rules of thumb: no lecture, no apology spiral, no pretending the question was not asked, and no fake knowledge. Keep a variation or two so a customer who tries three times does not see the same sentence. After the second off-topic message in a row, offer a person rather than repeat the refusal; see fallback copywriting for wording ideas and handoff design for the exit. Do not count these declines as understanding failures; they are deliberate, so tag them separately from your fallback rate.

Step 3: Put the boundary in the system prompt

Add the scope to the system prompt in plain terms: the bot's role, the in-scope list, what to do with everything else, and the exact refusal to use. State the positive job first, then the limits. Avoid long lists of "never" rules; they are hard to maintain and models can follow them unevenly. See prompt engineering for chatbots for structure.

Be realistic about what this does. Intercom's help article on its Fin Guidance feature says guidance shapes tone, formatting and style but does not strictly control behavior, and that hard rules belong in a different mechanism. Other platforms are similar in spirit: instructions to a language model are strong hints. That is why the next step exists.

Step 4: Add a check that does not depend on the prompt

Pick one or two of these, in order of effort:

  1. Platform guardrail topics. Some platforms let you list topics to block. Amazon Bedrock Guardrails, for instance, defines each denied topic with a name, a definition up to 200 characters and up to five sample phrases, allows up to 30 per guardrail, and can block matching prompts and responses. Its documentation says topics describe themes rather than single words, should not be written as exceptions, and that topic order can change results, so test after every edit. Check what your own platform offers.
  2. A small classifier in front of the main model. Ask a cheap model or a rules layer one question: is this message about our products and services, yes or no? If no, return the refusal without calling the main model. This also saves cost. Research on intent classification has long found that out-of-scope detection is harder than classifying in-scope requests (Larson et al., 2019), so measure rather than assume.
  3. Retrieval check. If the bot answers from a knowledge base, treat "nothing relevant retrieved" as out of scope and refuse, instead of letting the model improvise. See reducing hallucinations and the confidence policy guide.

Whatever you choose, apply it to the reply as well as the question where you can, since a bot can drift off topic mid-conversation.

Step 5: Route the sensitive cases to people

For the third list from Step 1, do not rely on a refusal alone. Offer a human straight away, pass along a short summary of the question, and tell the customer what happens next. A medical or legal question should not receive an improvised answer from a retail bot. See escalation playbook and human handoff. Out-of-hours, say when someone will reply and collect contact details.

Step 6: Test for both mistakes, then keep testing

Build a small test set with two groups: messages the bot must answer and messages it must decline. Pull real ones from your transcripts, include phrasings such as "just this once" and mixed messages like "track my order and write a poem". Run it after every change to the prompt, model or guardrail; the regression testing guide and the QA protocol show how. Count two numbers:

  • Leaks: off-topic messages that got an answer.
  • Over-refusals: normal messages that got declined.

Then read a sample of live declines each week. Customers often phrase real needs oddly, and a declined question you should have answered is a content gap or a boundary set too tight.

Check the arithmetic

An invented test, not a benchmark. The set has 100 messages: 60 in scope, 40 off topic.

  • Prompt rules only: 28 of 40 off-topic declined (70%), so 12 leak (30%). 3 of 60 in-scope refused (5%).
  • Prompt plus classifier: 36 of 40 declined (90%), so 4 leak (10%). 6 of 60 in-scope refused (10%).

At 5,000 messages a month with 20% off topic (1,000 off topic, 4,000 in scope): prompt only leaks 1,000 × 30% = 300 and over-refuses 4,000 × 5% = 200; with the classifier, 1,000 × 10% = 100 leak and 4,000 × 10% = 400 are over-refused. The classifier removes 200 leaks and adds 200 wrongly refused customers. Whether that is a good trade depends on your risk: a bank bot may accept it, a shop trying to sell might tune the classifier to be looser. Your numbers will differ; the method carries over.

Common mistakes

  • No written scope, so the prompt says "stay on topic" and nobody knows what that means.
  • A cold refusal with no alternative.
  • Counting deliberate declines as failures in your fallback metric.
  • Testing only off-topic messages and never checking what got blocked by mistake.
  • Trusting the prompt alone for anything with legal or safety weight.
  • Setting it and forgetting it, though products, prompts and models change.

FAQ

How do I stop my chatbot from answering off-topic questions?

Write a clear scope, state it in the system prompt with a set refusal, add a check outside the prompt such as a guardrail topic or classifier, and test regularly.

What should a chatbot say to an off-topic question?

Say briefly that it is outside what it can help with, list what it can do and offer a person. Keep it friendly and short.

Can a system prompt alone keep the bot on topic?

It reduces off-topic answers a lot but is not a guarantee. Vendors describe such instructions as guidance, so add a separate check where it matters.

Will blocking off-topic questions hurt customer experience?

It can if the boundary is too tight. Measure over-refusals as well as leaks, and read live declines weekly.

Should the bot answer small talk?

Usually a brief friendly reply is fine and builds trust; see small talk handling. Decide this in Step 1.

How often should I retest?

After every prompt, model or guardrail change, and on a regular schedule such as monthly.

Sources

About this guide

Chatbotscape launched in 2026 as an independent review site for chatbot platforms. This guide is editorial guidance built from the sources above; the steps, wording and worked example are our own practice with invented numbers, and we have not benchmarked any guardrail product.

Last updated

31 October 2026 — first published.