AI customer support agent that answers from your own content

Scripted bots vs. an agent grounded in your content

An older generation of chatbots worked off decision trees: match the visitor's exact phrasing to a pre-written branch, or fail. Ask the same question five different ways and you'd get five different outcomes, because the bot wasn't understanding the question — it was pattern-matching against a script.

A retrieval-augmented agent works differently. When a visitor asks something, the system searches your knowledge base for the most relevant passages — from crawled pages, uploaded documents, or Q&A pairs you've written — and hands those to the language model as context for its answer. The model handles the variation in how people phrase things; your content stays the source of truth for what the answer actually says.

Training it on what you already have

There's no separate authoring step. Point a bot at a URL and it crawls the page; upload a PDF, DOCX, TXT, MD, or CSV and it's chunked and indexed; or write short Q&A pairs directly for the questions you already know come up. All three source types can be mixed on a single bot, and any of them can be added or removed at any time from the Knowledge tab.

When you update the underlying content — a docs page changes, a new FAQ gets added — re-embedding refreshes what the bot can retrieve, so answers stay current without rebuilding the bot from scratch.

What happens when it doesn't know the answer

Grounded answers also mean grounded limits — if the knowledge base doesn't cover something, a well-configured agent should say so rather than guess. That's a system-prompt instruction worth being explicit about: tell the bot to say it isn't sure and offer to connect the visitor with your team, rather than filling the gap with something plausible-sounding but wrong.

This is also where lead capture and support meet: an instruction like "if you can't answer, ask for their email so the team can follow up" turns a dead end into a handoff instead of a dropped conversation. The visitor gets acknowledged, and you get a record of exactly what the agent couldn't cover — useful signal for what to add to the knowledge base next.

Keeping quality up as you scale

Every conversation can be closed and reviewed from the Conversations tab, and visitors can rate a conversation, giving you a running signal for where answers are landing and where they aren't. The bot's usage and analytics views show message volume and trends over time, so a spike in unanswered or poorly rated conversations about a particular topic is visible before it becomes a pattern of support tickets.

Treat the knowledge base as something that keeps growing, not a one-time upload — the most common reason a support agent underperforms months in is that the product moved on and the training content didn't.

Design a useful support knowledge base

Begin with the content customers already rely on: help articles, setup instructions, policies, troubleshooting steps, and answers to recurring questions. Group documents by product area and keep titles descriptive so a human can find the source later. A short, current article that explains one task clearly is often easier to maintain than a long page mixing unrelated procedures.

Check that content is safe and appropriate for a public chatbot. Internal notes, personal customer details, credentials, unpublished product plans, and staff-only procedures should not be added as public source material. If a page contains both public and internal sections, separate and review it before crawling or uploading.

Evaluate answers before publishing changes

Build a small test set from real support questions, paraphrases, and edge cases. Include questions whose answers are in the source, questions with incomplete source material, and questions the bot should hand off. Check that answers reflect the right policy, stay within the source, and tell visitors what to do next when the answer is missing.

Retest after a meaningful content or prompt change. Review helpfulness ratings and unresolved conversations, but do not treat a low number of complaints as proof of correctness; visitors may leave without reporting a bad answer. A staff member should periodically sample conversations and correct the source material when the product changes.

Keep sources current and resolve conflicting answers

A knowledge base can contain the same policy in a help article, an older PDF, and an FAQ that has not been updated. If those sources disagree, a retrieval system may return the wrong version even though each file looks relevant. Assign an owner to important source pages, review them when a policy or product changes, and remove or replace superseded documents rather than leaving conflicting copies in the bot's source set.

Use consistent language for dates, plan names, and step sequences. A short change log or a review date on internal source documents helps the team decide what needs rechecking, even if the public page does not show that detail. After a source change, test questions about the changed policy and neighboring topics to ensure the update did not leave an old answer accessible through a duplicate file.

Create a reliable route to a human

A human handoff is more than a sentence saying "contact support." Tell the bot which verified channels are available, what information a person needs to continue, and when it should stop troubleshooting. For billing, account access, security reports, complaints, and other sensitive cases, a direct link or a lead request is usually clearer than asking the visitor to repeat a long story in an open chat.

Avoid promising a response time unless your support team has committed to it. If the team is unavailable, describe the actual next step and the hours it monitors. Test the handoff with keyboard-only navigation and at mobile widths so the contact option remains visible and usable when the bot reaches its limit.

Choose support measures that reflect customer outcomes

Conversation volume is an activity measure, not an outcome. Pair it with signals your team can verify, such as whether the visitor found the relevant article, whether the conversation needed a human, what topics remain unanswered, and how visitors rate the response. If your support system records tickets, compare categories over consistent periods and account for product launches or seasonal changes before attributing a change to the chatbot.

Use low ratings and repeated follow-up questions as investigation prompts. Read the source passages and conversation together: the issue might be missing documentation, a confusing policy, an outdated answer, or a prompt that asks the model to do too much. Make a targeted correction, then rerun the test set so a fix for one question does not introduce a new problem elsewhere.

Build a lightweight review routine for the support bot

Assign an owner to check the bot after product and policy releases. That person can review a sample of recent questions, update stale source pages, test the most important answers, and confirm the human support route still works. The routine does not need to be elaborate; the important point is that content maintenance has a named owner and is not left until a customer reports a serious mismatch.

Keep a short list of known limits and decisions the bot must not make. When the bot is uncertain, the right response is to acknowledge the gap and point the customer to an available next step. If a question is common but the policy is undecided, escalate the policy decision to the business owner instead of writing a confident answer into the knowledge base.

Give support content a clear owner

A chatbot project needs an owner for both the technical setup and the information it uses. The site administrator can manage widget placement, while a subject-matter owner reviews product and policy answers. If nobody is responsible for approving an update, old instructions can remain in the knowledge base long after the public product has changed.

For each important source, note who can confirm the information and how the team will learn about a change. This can be a simple release checklist or a regular review task. The goal is not to add process for its own sake; it is to make sure the bot does not become an unmaintained copy of a product that has moved on.

Setting it up

Create a bot, write a system prompt describing its role and what it should do when it's unsure, then add your help docs, key product pages, and any Q&A pairs for questions your team answers often. Set the welcome message and tone, then embed the widget — as a floating bubble via script tag, or as a standalone page for a dedicated support link. See the embedding guide for the exact steps on your platform.