How to build a customer support chatbot for your website (step-by-step)

TL;DR: A customer support chatbot is a retrieval agent plus an escalation path. Ingest your help content, retrieve the right passage, answer from evidence with citations, and hand off to a human when confidence is low. The engineering is straightforward; the discipline is in freshness, refusal, and evaluation before you put it in front of customers.

A website support chatbot answers customer questions from your existing knowledge — help center, docs, policies — and escalates to a human when it cannot help. The goal is deflecting repetitive questions accurately, not deflecting them at any cost. A bot that confidently gives wrong refund policy is worse than no bot.

This tutorial builds one you can trust and maintain, whether you use a no-code platform or write the pipeline yourself.

What a support chatbot needs to do

1. Answer from your knowledge, not from the model's imagination.
2. Stay current as policies and articles change.
3. Cite sources so customers and agents can verify.
4. Escalate to a human with full context when unsure or when intent is high.
5. Be measured on accuracy and deflection, not just chat volume.

Step 1: Define scope and success

Pick one audience and one topic area to start — for example, billing questions for existing customers. Write down what "resolved" and "correct" mean, and which questions must always escalate to a human (cancellations, complaints, anything legal or financial-sensitive). A narrow, well-tested launch beats a broad, shaky one.

Step 2: Prepare your knowledge base

Gather the smallest set of documents that answers the most tickets. Then:

• Remove duplicates and outdated pages so retrieval is not choosing between three conflicting answers.
• Separate customer-safe content from internal notes and macros.
• Assign an owner and review date to each collection.

Answer quality tracks content quality more than model choice.

Step 3: Ingest, chunk, and index

Split documents into chunks of roughly 500–1,000 tokens with light overlap, preserving headings and tables. Embed each chunk and store it in a vector index with metadata: source URL, title, last-updated date, and audience. The metadata lets you filter (public only) and cite sources.

Step 4: Retrieve and generate

For each question, retrieve the most relevant chunks — filtered to customer-safe content — and prompt the model to answer only from them, cite the source, and refuse when the passages do not contain the answer. Return the source link in the reply so customers can verify and so you can debug bad answers later.

Step 5: Build the escalation path

Design handoff before launch, not after the first angry customer. When the bot is unsure, or the customer asks for a human, or the topic is on your always-escalate list, route the conversation to your inbox or ticketing tool with the full transcript attached. A clean handoff is a feature customers notice.

Step 6: Deploy the widget

Embed the chat widget on your site, scoped to the pages where questions arise (pricing, docs, checkout). Match your brand, set clear expectations ("AI assistant — I can connect you to a human anytime"), and make the human handoff one click away.

Step 7: Evaluate before customers see it

Build a test set of 30–50 real questions from past tickets: exact answers, paraphrases, conflicting articles, questions your docs don't answer, and recently changed policies. Score each response for accuracy, citation correctness, freshness, refusal, and correct escalation. Re-run after every content or prompt change. This is the gate between a demo and production.

Step 8: Launch small and expand

Go live read-only for one audience and one topic. In week one, require citations and review every low-confidence or escalated conversation, fixing the underlying article rather than adding prompt exceptions. Expand to more topics, audiences, or languages only after the bot passes evaluation.

Track deflection rate, unanswered-question rate, escalation accuracy, citation correctness, evaluation pass rate, latency, and cost. Deflection without accuracy is just customers leaving with the wrong answer.

Common mistakes to avoid

• Connecting your entire knowledge base including internal notes, then relying on the prompt to keep secrets out.
• Skipping refusal, so the bot always answers even with no evidence.
• Launching without an eval set, so you find failures from customer complaints instead of a test run.
• Measuring volume, not accuracy, and calling deflection a win when it was a wrong answer.

How Currai fits

When you build the bot yourself, its failures are invisible without instrumentation. Currai traces each conversation — question, retrieved passages, model input and output, prompt version, latency, and cost — so you can see why an answer was wrong or an escalation misfired. Evals score accuracy, citations, and escalation against production traces. See debug a slow RAG pipeline and evaluate multi-turn customer support conversations, or start tracing.

Frequently asked questions

How long does it take to build a support chatbot?

A basic retrieval bot on a no-code platform can go live in days. Building a trustworthy one — with fresh content, refusal, escalation, and evaluation — takes longer and is the part that determines whether customers get correct answers.

Do I need engineers to build one?

Not necessarily. No-code platforms cover ingestion and deployment. Building it yourself gives control over retrieval, refusal, and evaluation. The principles are the same either way.

How do I keep the chatbot from giving wrong answers?

Constrain answers to retrieved evidence, require citations, add explicit refusal and escalation, evaluate with a real test set, and monitor live conversations for confident wrong answers.

What should I measure after launch?

Deflection rate, unanswered-question rate, escalation accuracy, citation correctness, evaluation pass rate, latency, and cost — not chat volume alone.