An AI chatbot that answers customer questions from your own documentation is one of the few genuinely proven business applications of these tools. It deflects repetitive support volume, works outside business hours, and handles the same twenty questions that consume most support time.

It also fails badly when built carelessly, and the failure is public — a bot confidently telling a customer something untrue about your product, in writing, on your own website.

The three approaches

1. A hosted chatbot service

You sign up, point the service at your website or upload your documents, configure a few settings and paste an embed code into your site. It handles the model, the retrieval, the interface and the hosting.

Cost: a monthly subscription, usually tiered by message volume or document count.

Time to launch: hours.

Trade-offs: limited control over behaviour, your content sits on their infrastructure, and costs scale with usage in ways that can surprise you. Verify data handling terms before uploading anything sensitive.

Suits: most small and mid-sized businesses. This is the correct default unless you have a specific reason to build.

2. A plugin on your existing platform

For WordPress and similar platforms, plugins connect your site content to a model provider and render the chat interface for you.

Cost: a plugin licence plus your own usage charges from the model provider.

Trade-offs: you manage the API relationship and the costs, which gives you more control and more responsibility. Quality varies enormously between plugins — check what retrieval method each actually uses rather than trusting the feature list.

3. Building it yourself

You write the integration: a retrieval layer over your content, calls to a model provider, and a chat interface.

Cost: development time plus per-use model charges.

Suits: businesses with unusual requirements, existing development capacity, or a need to integrate the bot with internal systems rather than just documentation.

How the useful version actually works

The critical technical point, whichever route you take: a good support bot does not answer from the model’s general knowledge. It retrieves relevant passages from your own content and answers from those.

The mechanism is straightforward. Your documentation is split into chunks and indexed. When a question arrives, the system finds the passages most relevant to it and supplies them to the model alongside the question, with an instruction to answer only from that material.

This is what keeps answers accurate and current. A bot answering from general training data will invent details about your product, because it does not have any. Any tool you evaluate should be doing retrieval; if it cannot tell you how it grounds answers, it is the wrong tool.

Preparing your content

Output quality is determined mostly by input quality, and this step is where most implementations are won or lost.

What to feed it: product documentation, frequently asked questions, policy pages, pricing details, and — the most valuable source and the most commonly overlooked — your existing support ticket history, which contains the questions customers actually ask in the words they actually use.

What to clean up first: outdated pages that contradict current ones, duplicated information stated differently in two places, and anything internal that should never be shown to a customer. The bot will surface whatever you give it, including the price list you forgot to update.

Contradictions are particularly damaging, because the bot has no way to know which version is current. It will confidently pick one.

Configuring behaviour

The instruction you give the bot matters as much as the content. Specify:

• Scope. What it should and should not discuss. A support bot should decline questions unrelated to your product rather than becoming a general assistant on your website.
• Admitting ignorance. Explicitly instruct it to say it does not know and offer a handover, rather than guessing. This single instruction prevents most embarrassing failures.
• Escalation. A clear path to a human, easily reachable at any point. Customers who cannot escape a bot get angry in ways that cost more than the support hours saved.
• Tone. Matched to your brand, and consistent.
• Prohibitions. No commitments about refunds, no legal or medical interpretation, no pricing promises outside published rates, no statements about future releases.

Testing before launch

Collect fifty real questions from your support history and run every one. Check the answers against what a good human agent would say.

Then test adversarially. Ask questions your documentation does not cover, to confirm it admits ignorance rather than inventing. Ask ambiguous questions. Ask questions about competitors. Try to get it to make a commitment on your behalf. Ask it to ignore its instructions, since some users will.

Fix what fails, then retest. Launching without this step is how organisations end up with a screenshot of their own bot saying something wrong circulating publicly.

Costs to plan for

Hosted services charge monthly, generally tiered by usage. Self-built solutions charge per interaction through the model provider, which is cheap individually and adds up at volume — and the cost is roughly proportional to how much content you supply with each question, so bloated retrieval is expensive as well as inaccurate.

Either way, model the cost at ten times your expected traffic before committing. A pricing structure that is trivial at a hundred conversations a month can be uncomfortable at ten thousand.

Privacy and compliance

Customers will type personal information into the chat regardless of what you tell them. Decide in advance what is logged, for how long, and who can access it. Publish a clear notice that they are talking to an AI system and what happens to the conversation.

If you operate in a jurisdiction with data protection requirements — and most now do — check where the provider processes and stores data, and whether that is permissible for your customers’ region. Worth getting proper advice on rather than assuming.

After launch

Read the conversation logs weekly, at least at first. They tell you two things: where the bot is failing, and what customers are confused about — which is frequently more valuable than the deflection itself. Questions that recur are documentation gaps, and fixing the documentation improves the bot and the site simultaneously.

Track deflection rate, handover rate, and satisfaction where you can measure it. A bot handling seventy percent of routine questions well is a success. One handling ninety percent with occasional confident errors is a liability.