AI Chatbot Development: How to Build a Chatbot for Your Business, Step by Step

AI chatbot development is the work of designing, connecting, testing and running a chatbot that answers people in plain language using a large language model, the kind of AI behind ChatGPT. For a business, the model is the easy part. The real work is deciding what the chatbot should handle, giving it the right information, connecting it to the right systems, and making sure it hands over to a person when it should.

This guide explains how to build an AI chatbot for your business step by step: choosing the right kind of chatbot, preparing the knowledge it answers from, connecting it to your systems, designing the handoff to your team, protecting customer data, making it accessible, testing it, and keeping it accurate after launch. It also explains what drives AI chatbot development cost, so you can budget for running the chatbot as well as building it. It is written for business owners, operations leads and product teams planning their first chatbot or replacing one that does not work well.

What Is AI Chatbot Development?

AI chatbot development is the process of building a chatbot that understands questions written in everyday language and replies using a large language model. It covers choosing the chatbot’s job, connecting it to approved company information and systems, setting rules for what it may do, testing its answers, and monitoring it after launch so it stays accurate.

Older chatbots followed scripts: a fixed menu of questions and pre-written answers. Modern AI chatbot development replaces most of the script with a model that can understand varied wording, but that flexibility comes with a new problem. A model can produce a fluent answer that is wrong, so most of the effort in a business chatbot goes into grounding its answers in your own information and limiting what it can do.

Three Kinds of Business Chatbots

The first decision in AI chatbot development is which kind of chatbot the job needs. Anthropic, which makes the Claude models, describes the basic building block of agentic systems as “an LLM enhanced with augmentations such as retrieval, tools, and memory” Source [1]. How many of those additions a chatbot gets is what separates the three kinds below.

Table 1. The three kinds of business chatbot, from simplest to most capable.

Most businesses should start with the simplest kind that does the job. Anthropic’s advice for building with language models is to find “the simplest solution possible, and only increasing complexity when needed” Source [1]. A knowledge chatbot that answers well is more useful than an action chatbot that cannot be trusted.

The line between a chatbot and an AI agent is mostly about actions. Anthropic notes that “Customer support combines familiar chatbot interfaces with enhanced capabilities through tool integration” Source [1]. Once a chatbot can change records or trigger processes, it needs the controls of an agent. Our post on the difference between an AI agent and an AI assistant explains where that line sits.

Why Chatbot Accuracy Is a Business Risk

A chatbot speaks for your company, and customers act on what it says. In Moffatt v. Air Canada, a Canadian tribunal ordered the airline to compensate a customer after its website chatbot gave wrong information about a bereavement fare. The tribunal rejected the idea that the chatbot was separate from the company: “It makes no difference whether the information comes from a static page or a chatbot,” and “I find Air Canada did not take reasonable care to ensure its chatbot was accurate” Source [2].

The OWASP Top 10 for LLM Applications 2026, a widely used security list for AI applications, describes the same risk under Misinformation: “The core risk is that the incorrect output is trusted and acted upon.” One of its example scenarios reads like a support chatbot gone wrong: “A customer-service agent misreads a policy and approves a refund that violates the terms, resulting in financial loss” Source [3].

The award in the Air Canada case was small, but the principle matters for every business: you are responsible for your chatbot’s answers. That is why grounding, testing and handoff take up most of the steps below.

Who You Need for AI Chatbot Development

A chatbot project needs fewer people than most software projects, but it needs the right ones. Before you start, put a name next to each of these responsibilities:

• Business owner: decides what the chatbot handles, approves its rules and is accountable for its results.
• Content owners: keep each knowledge source current, so the chatbot never repeats an outdated policy.
• Support lead: knows the questions customers really ask, writes the test set and designs the handoff to the team.
• Developer or development partner: sets up the model, retrieval, integrations and monitoring.
• Security and privacy reviewer: checks what data the chatbot can reach, what it logs and what the model provider stores.

On a small team, one person may cover several of these roles. What matters is that every responsibility has an owner before launch.

How to Build a Chatbot, Step by Step

These nine steps to build a chatbot apply whether you use a chatbot platform, a custom build, or a mix of both. The order matters: each step depends on decisions made in the one before it.

1. Pick One Job and Define What “Resolved” Means

Start with one job that comes up often and has a clear end. “Answer questions about order delivery” is a good first job. “Handle customer service” is not. Look at your support inbox, chat logs or call notes and pick the questions that are frequent, repetitive and answered from information you already have. Good first jobs include delivery and order questions for an online store, policy questions from staff for HR, product and warranty questions for a support team, and booking questions for a service business.

Then write down what a resolved conversation looks like: the customer got a correct answer, confirmed it helped, and did not contact you again about the same thing. Also write down what the chatbot must never do, such as promise refunds, give legal or medical advice, or discuss other customers’ accounts. These two lists become the basis of your tests in step 8.

2. Choose a Platform, a Custom Build, or Both

There are three common routes for AI chatbot development:

• A chatbot platform. Chatbot development platforms let you configure a chatbot on top of an existing model, connect a knowledge source and add it to your website without much code. This is the fastest route for an FAQ or simple knowledge chatbot, but you are limited to the integrations and controls the platform offers.
• Custom chatbot development. A development team builds the chatbot around a model provider’s API, your data and your systems. This takes longer, but it gives you control over where data goes, how answers are checked, which systems the chatbot can reach and how it hands over to your team.
• A mix of both. Many teams start on a platform to learn which questions matter, then move to a custom build when they need deeper integrations, stricter data controls or lower running costs at volume.

Choose based on the job from step 1. If the chatbot only needs your public help pages, a platform may be enough. If it needs your CRM, order system or internal documents with different access levels, custom chatbot development is usually the safer choice.

3. Prepare the Knowledge It Will Answer From

A knowledge chatbot uses retrieval-augmented generation (RAG): before answering, it searches your approved documents and gives the most relevant passages to the model. Amazon Web Services describes RAG as “a technique that uses information from data sources to improve the relevancy and accuracy of generated responses” Source [4]. Anthropic puts the business case simply: “customer support chatbots need knowledge about the specific business they’re being used for” Source [5].

The quality of the chatbot depends on the quality of these documents. Before connecting anything:

• Choose the sources deliberately. Use current, owned documents: help articles, policies, product sheets. Leave out drafts, old versions and anything that contradicts another source.
• Give every source an owner. Someone must update the document when a policy changes, or the chatbot will keep repeating the old one.
• Prepare documents so passages make sense on their own. Documents are split into small passages before they are searched. Anthropic notes that “traditional RAG solutions remove context when encoding information” Source [5], so a passage that says “this applies within 30 days” is useless if it no longer says what “this” is.
• Show sources in answers. AWS recommends that you “Include citations in the generated response so the original data source can be referenced and accuracy can be checked” Source [4]. Citations let customers and your team verify an answer in one click.
• Respect access levels. If some documents are internal only, the chatbot must check permissions before it searches. OWASP’s guidance on sensitive information is direct: “Authorize before retrieval” Source [6]. Filtering an answer after the model has seen a confidential passage is too late.

Fossilite’s guide to building production RAG that reduces hallucinations (opens in a new tab) covers source preparation, retrieval testing and citations in more depth, and our RAG architecture and retrieval quality guide explains how retrieval is set up and measured.

4. Connect It to Your Systems

Chatbot integration is what turns a chatbot that talks into one that helps. Integrations let the chatbot look up an order, check stock, create a support ticket or book an appointment. Model providers support this through function calling, also called tool calling, which OpenAI describes as “a powerful and flexible way for OpenAI models to interface with external systems” Source [7]. In practice, your developers describe each available action, the model asks for one when a customer’s request needs it, and your application carries out the request and returns the result.

The Model Context Protocol (MCP) is an open standard for these connections. Its specification describes MCP as “an open protocol that enables seamless integration between LLM applications and external data sources and tools” Source [8]. It can make integrations easier to reuse across tools, but it does not decide what the chatbot should be allowed to do. The same specification states that “Hosts must obtain explicit user consent before invoking any tool” Source [8].

Three rules keep chatbot integration safe:

• Start with read-only access. Looking up an order is low risk. Issuing a refund is not. Add actions that change records only after the read-only version works well.
• Give the chatbot its own limited account. It should reach only the records and actions its job needs, enforced by your systems rather than by instructions in the chatbot’s prompt.
• Confirm before any change. For actions such as booking, cancelling or updating details, show the customer what will happen and ask them to confirm.

5. Design the Conversation and the Handoff to a Person

Write the chatbot’s opening message so people know what it can help with and that a person is available. Keep answers short, use the customer’s wording, and ask a clarifying question instead of guessing when a request is unclear.

The handoff to a person is the most important part of the conversation design. Amazon’s contact center documentation lists the main reasons to escalate: “Use escalations when a task requires an agent, a business rule prevents automation, the user asks for a person, or the flow needs to transfer the conversation into a Connect Customer queue” Source [9]. Add your own triggers, such as repeated failed answers, complaints, or any topic on your “never” list from step 1.

When the chatbot hands over, the customer should not have to start again. Microsoft’s Copilot Studio documentation describes the goal: “When your agent hands off a conversation, it can share the full history of the conversation, and all relevant variables” Source [10]. Pass the transcript, a short summary and any details the customer has already given. Outside working hours, the chatbot should say when a person will reply and collect contact details instead of leaving the customer waiting.

6. Build In Security and Privacy

A chatbot that reads customer messages and your documents is exposed to a risk called prompt injection: text that tricks the model into ignoring its instructions. It can come from a user typing “ignore your rules” or from a document the chatbot retrieves. OWASP’s 2026 list is clear that this cannot be fully prevented: because of how language models work, “no reliable prevention mechanism exists today,” so the defense has to come from the system around the model Source [11]. Its advice is to design the surrounding system “on the explicit assumption that the model’s instruction boundary will eventually be bypassed” Source [11].

In practice, that means:

• Limit what the chatbot can reach and do, as in step 4, so a successful trick cannot cause real harm.
• Keep secrets out of the chatbot’s instructions. Never put passwords, API keys or confidential rules in the prompt.
• Connect only data every user of the chatbot may see, or enforce permissions before retrieval as in step 3. OWASP warns that “oversharing upstream” through unscoped drives and legacy permissions is one way sensitive data ends up in a chatbot’s answers Source [6].
• Protect conversation logs. Logs often hold names, emails and order details. Decide how long you keep them, who can see them, and what your model provider stores.

7. Make the Chat Window Accessible

A chatbot that some customers cannot use is a broken chatbot. The Web Content Accessibility Guidelines (WCAG) 2.2, the W3C standard that many accessibility policies refer to, apply to chat widgets like any other part of a website. The criteria that matter most for a chat window are:

• New replies are announced to screen readers. WCAG’s Status Messages criterion requires that such messages “can be presented to the user by assistive technologies without receiving focus” Source [12], so a blind user hears the chatbot’s reply without losing their place.
• Everything works with a keyboard. Opening the chat, typing, sending, using quick-reply buttons and closing the window must all work without a mouse.
• The focused item stays visible. A floating chat button or window must not cover the part of the page a keyboard user is on.
• Buttons and fields have clear labels, and session timeouts can be extended for people who type slowly.

Plain answers help everyone: short sentences, no unexplained jargon, and links to the full source for anyone who wants detail.

8. Test Before Launch

Test the chatbot the way customers will use it, not with a handful of easy questions. Anthropic’s engineering team explains why structured tests, called evals, matter: “Evals make problems and behavioral changes visible before they affect users” Source [13]. You do not need thousands of test questions to start; Anthropic notes that “20-50 simple tasks drawn from real failures is a great start” Source [13].

Build your test set from step 1: real customer questions, questions the chatbot should refuse, questions that need a handoff, unclear questions, and a few attempts to make it break its rules. For each one, write down what a good answer looks like. Microsoft’s guidance on testing AI applications names the measures to check before deployment: “task adherence, groundedness, relevance, and safety” Source [14]. Groundedness means the answer is supported by your own documents rather than invented.

Set a pass level before you test, for example that every policy answer must match the source document and every out-of-scope question must be handed over. Re-run the same tests every time you change the prompt, the model or the documents. Our post on LLM testing covers how to build and grade these tests.

9. Launch Small, Then Monitor and Improve

Launch to a small group first: one page, one region, or a share of chat traffic. Microsoft’s guidance continues after launch: “After deployment, continuous monitoring ensures your AI application maintains quality in real-world conditions” Source [14].

Track a short list of numbers every week:

• Resolution rate: the share of conversations resolved without a person.
• Handoff rate and reasons: why conversations reach your team.
• Answer accuracy: a weekly review of a sample of answers against their sources.
• Repeat contacts: customers who come back about the same issue.
• Cost per resolved conversation: what the chatbot costs to run for each conversation it actually resolves.

Turn every wrong answer you find into a new test case, fix the source document or the instructions, and re-test before the change goes live. Expand the chatbot to new topics only when the numbers for the current ones hold steady.

What Drives AI Chatbot Development Cost

AI chatbot development cost has two parts: the cost to build the chatbot and the cost to run it. Most guides only discuss the first.

Build cost depends mainly on four things: the number of systems the chatbot must connect to, the state of your documents, how strict the security and approval requirements are, and how much testing the use case needs. An FAQ chatbot on a platform can be set up quickly. A custom action chatbot connected to several systems with different access levels is a software project.

Running cost depends on usage. Model providers charge per token (a small chunk of text, often a short word or part of one), both for the text sent to the model and for the text it writes back. Anthropic, for example, lists its model prices in dollars per million tokens, separately for input and output Source [15]. On every turn of a conversation, the chatbot sends its instructions, the conversation so far and any retrieved passages to the model. Language models do not remember earlier messages on their own: OpenAI notes that “each text generation request is independent and stateless” Source [16], so the history is sent again with every message, and long conversations cost more per reply.

Four levers keep running costs under control:

• Caching repeated text. Instructions and standard passages that are sent with every message can be cached. OpenAI says cached input is “discounted up to 95%” and that “Prompt caching is enabled by default for supported OpenAI models” Source [17].
• Sending less. Retrieve fewer, better passages and summarize long conversations instead of sending the full history every time.
• Using the right model for each task. A smaller, cheaper model can handle simple questions, with a larger model reserved for harder ones.
• Running background work in batches. Work that does not need an instant reply, such as nightly test runs or conversation summaries, can use batch processing. Anthropic’s Batch API, for example, offers “a 50% discount on both input and output tokens” Source [15].

Prices change often, so estimate from the provider’s current pricing page: measure the average tokens per conversation in your pilot, multiply by expected monthly conversations, and compare the result with the cost of handling those conversations today.

How SensViz Builds AI Chatbots

SensViz handles AI chatbot development as part of our generative AI development work, including internal knowledge assistants that answer staff questions from approved documents, customer support assistants that prepare replies for agents to review, and assistants embedded in products. When a chatbot needs to take actions across several systems, that work sits with our agentic AI development team.

If you are still deciding what your chatbot should handle, we can start with the job, the sources and the handoff rules before anything is built. If a platform will do the job, we will say so.

Frequently Asked Questions

These answer two questions businesses often ask before starting AI chatbot development.

Do We Need to Train Our Own Model to Build an AI Chatbot?

Usually not. Most business chatbots use an existing model from a provider and connect it to your own documents through retrieval, so answers come from your current information without training a new model. This is faster, cheaper and easier to update: when a policy changes, you update the document instead of retraining anything.

Can an AI Chatbot Remember Previous Conversations?

Within one conversation, yes, because the chatbot sends the conversation so far with each message. Remembering a customer across separate visits only works if you build it: the chatbot has to store past conversations or short summaries, ideally linked to your CRM, and look them up when the customer returns, with clear rules on consent and retention.

Sources

1. Anthropic, “Building Effective AI Agents,” (opens in a new tab) 19 December 2024.
2. Civil Resolution Tribunal of British Columbia, “Moffatt v. Air Canada, 2024 BCCRT 149,” (opens in a new tab) 14 February 2024.
3. OWASP Gen AI Security Project, “LLM07:2026 Misinformation,” (opens in a new tab) OWASP Top 10 for LLM Applications 2026, released 3 August 2026.
4. Amazon Web Services, “Retrieve data and generate AI responses with Amazon Bedrock Knowledge Bases,” (opens in a new tab) Amazon Bedrock User Guide, accessed 12 October 2026.
5. Anthropic, “Introducing Contextual Retrieval,” (opens in a new tab) 19 September 2024.
6. OWASP Gen AI Security Project, “LLM02:2026 Sensitive Information Disclosure,” (opens in a new tab) OWASP Top 10 for LLM Applications 2026, released 3 August 2026.
7. OpenAI, “Function calling,” (opens in a new tab) OpenAI API documentation, accessed 12 October 2026.
8. Model Context Protocol, “Specification,” (opens in a new tab) version 2026-07-28.
9. Amazon Web Services, “Managing escalations,” (opens in a new tab) Amazon Connect Customer Administrator Guide, accessed 12 October 2026.
10. Microsoft Learn, “Hand off to a live agent,” (opens in a new tab) Microsoft Copilot Studio documentation, last updated 3 August 2026.
11. OWASP Gen AI Security Project, “LLM01:2026 Prompt Injection,” (opens in a new tab) OWASP Top 10 for LLM Applications 2026, released 3 August 2026.
12. W3C, “Understanding Success Criterion 4.1.3: Status Messages,” (opens in a new tab) Web Content Accessibility Guidelines (WCAG) 2.2.
13. Anthropic, “Demystifying evals for AI agents,” (opens in a new tab) 9 January 2026.
14. Microsoft Learn, “Observability in generative AI,” (opens in a new tab) Microsoft Foundry documentation, last updated 31 July 2026.
15. Anthropic, “Pricing,” (opens in a new tab) Claude Platform documentation, accessed 12 October 2026.
16. OpenAI, “Conversation state,” (opens in a new tab) OpenAI API documentation, accessed 12 October 2026.
17. OpenAI, “Prompt caching,” (opens in a new tab) OpenAI API documentation, accessed 12 October 2026.