AI
Chatbot Development: How to Build an AI Chatbot That Works
Chatbot development is the work of building a conversational assistant that answers customers from your own content, looks things up in your systems and hands the conversation to a person when it should. In AI chatbot development the language model is the small part. Quality comes from the content, integrations, handoff rules and testing around it.
Connecting a model to a chat window takes an afternoon, and the rest of the project is where the difference in quality is made.
What is an AI chatbot, and what is it not?
An AI chatbot is conversational software that uses a language model to understand a question and write an answer from a defined set of sources. Three kinds of software go by the name chatbot, and they suit different jobs.
A scripted chatbot follows decision trees and buttons written in advance. It is cheap and completely predictable, which makes it a good fit for a handful of repetitive questions. It stops being useful as soon as a visitor asks something the script did not anticipate.
An AI chatbot uses a language model to handle varied phrasings of a question and to write an answer. Built properly, it answers from a defined set of sources: your help articles, product data, policies and documentation. This is what most people mean today when they ask for a chatbot.
An AI agent goes one step further and acts: it creates records, updates orders or moves a task forward inside your systems. The line between a chatbot that looks things up and an agent that acts is where the risk changes, and we cover agents separately in our guide to AI agent development.
Most business chatbots should start as the second kind, with read-only access to the systems they need, and take on actions only once they have proved reliable.
Where is an AI chatbot worth building?
A chatbot pays off where the same questions arrive every day and the answers exist somewhere in your content or systems. Good candidates include:
- Customer support: delivery times, returns, warranty terms and order status, answered at any hour, with a handoff to a person for anything unusual.
- Pre-sales questions: helping a visitor choose between products or plans by asking what they need and pointing to the right option.
- Intake and qualification: collecting the details of a request (what, when, budget) and passing a clean summary to your team.
- Internal knowledge: answering staff questions from policies, handbooks and past tickets, with links to the source.
- In-product assistance: answering questions inside your app about the user's own data, such as their plan, usage or numbers.
A chatbot is the wrong tool in two common cases. If people keep asking the same question because the answer is missing or hidden on your website, fix the website first. At low volumes, compare the full running cost with the time your team would save before investing in a chatbot. Reading a week or two of your incoming messages usually settles the question and gives you the first set of test cases for free.
How does AI chatbot development work?
AI chatbot development runs through nine steps: define the job, prepare the content, ground the answers, connect your systems, design the handoff, choose the model, add guardrails, test against real questions, and launch with the conversations being read. It looks like any serious software project, plus a few steps specific to AI.
Define the job and what success looks like
Write one sentence that describes the job, such as "answer questions about orders, delivery and returns for customers of our online store". Then decide what the chatbot must never do (quote a price that is not in the catalog, promise a refund, give medical or legal advice), when it must hand over to a person, and how you will measure it. Useful measures are the share of conversations resolved without a person, the handoff rate and the answers your team marks as wrong.
Prepare the content it answers from
The chatbot can only be as good as the material behind it. In most projects, gathering and cleaning that material takes longer than any other step. Policies contradict each other, help articles are out of date, and some answers exist only in one employee's head. Collect the sources, remove the duplicates, fix the contradictions and write down the answers nobody wrote down before. This work improves your website and your team's own answers too.
Ground the answers in your sources
The standard technique is retrieval: when a question arrives, the system searches your content for the most relevant passages and gives only those to the model, with an instruction to answer from them and say so when they do not contain the answer. Anthropic's guidance on reducing hallucinations recommends allowing the model to say it does not know and grounding responses in quotes from the source. The chatbot can link to the source it used, which lets the customer check and lets your team see where a wrong answer came from. Good retrieval depends on well-structured content more than on the choice of model.
Connect it to your systems
Answers like "where is my order" or "is this in stock" should never come from the model's memory. They come from your order system, inventory or booking calendar through an API integration, and the chatbot only phrases the result. Start with read-only access, give the chatbot its own credentials and log every call. If it later needs to act, for example to book an appointment, add that as a separate step with its own checks.
Design the conversation and the handoff
Decide how the chatbot introduces itself, how it asks follow-up questions and what happens when it cannot help. A good handoff passes the conversation to a person together with a short summary, so the customer does not have to repeat themselves. A chatbot that cannot reach a person annoys customers more than having no chatbot at all.
Choose the model
Test candidate models on your own questions, because public benchmarks say little about your tasks. What matters is how well it follows your instructions, how it handles your languages, what it costs per conversation, how fast it responds and how the provider treats your data. Many chatbots use a smaller, cheaper model for routine questions and a stronger one for the harder cases.
Add guardrails
The limits that matter belong in code, not only in the prompt. Restrict what data the chatbot can reach, filter what it may send back (no internal notes, no other customers' data) and watch for prompt injection, where text inside a document or a user message tries to give the chatbot new instructions. OWASP lists prompt injection as the first risk in its Top 10 for LLM applications. Decide how personal data is handled and stored before launch, because it affects how the system is built.
Test against real questions
Build an evaluation set from real messages: common questions, awkward phrasings, questions it should refuse and questions it should hand over. Run the chatbot against that set after every change to the content, the prompt or the model, and track how many answers are correct, how many are wrong and how many are handed over. Anthropic's documentation on defining success criteria and building evaluations is a good starting point. A demo with ten friendly questions tells you very little.
Launch and read the conversations
Start with a limited launch and have someone read the conversations every day for the first weeks. Real users will ask things your test set missed, and each of those becomes a new test case or a content fix. After that, keep reviewing a sample regularly, watch the running costs and re-run the evaluation whenever the model provider updates the model.
What we learned building three digital products
Three products we designed, developed and launched carry lessons that apply directly to chatbots.
Plainhub is a financial platform for startups. Founders record what happened in plain words, and a live financial model recomputes cash, burn rate, MRR and runway from every recorded event. Its built-in AI finance agent works with the company's own numbers to help founders understand their financial position. The lesson for any chatbot that answers questions about someone's data: calculate the numbers in code, and let the AI explain and work with them instead of producing them.
NovaOracles is a personalized astrology platform. The problem it set out to solve was apps that repeat generic text or let a chatbot improvise. Its readings are built from each person's own birth chart, calculated by its own astronomy engine based on the VSOP87 planetary theory, and the content is available in five languages. Grounding the product in computed data is what keeps each reading specific to the person. A chatbot that answers questions about a customer's account needs the same discipline: every fact it gives comes from your own systems, never from a guess.
Not every AI feature should be a conversation. Recognizing food from a photo, adapting a daily plan from activity and sleep data, or showing a single computed number can serve the user better than a chat window. Pick the interface from the task, and use a chatbot where open-ended questions are the real job. Our AI development service covers the options.
Should you use an off-the-shelf chatbot or build a custom one?
Use an off-the-shelf chatbot when your questions are general and the content already lives in the tool, and build a custom one when it must work with your own data, sit inside your product or follow controls you define. Many helpdesk, e-commerce and website tools now include an AI chatbot, and when the chatbot does not need to reach your own systems, buying is faster and cheaper, so start there.
| Off-the-shelf chatbot | Custom build | |
|---|---|---|
| Content source | The tool's own content, such as helpdesk articles | Any of your sources and systems |
| Actions in your systems | Limited or none | Designed to your rules |
| Controls and limits | The vendor's settings | Defined by you, enforced in code |
| Languages and channels | Whatever the tool supports | Planned for your markets |
| Setup effort | Low | Higher, scoped to the job |
A custom build makes sense when the chatbot has to work with your own data or business logic, sit inside your product, follow controls you define, or behave consistently across several languages and channels. It is also the route when the built-in option cannot reach the data that matters or cannot be restricted the way your risk requires. If you are comparing partners for this kind of work, our guide to choosing an AI automation agency lists the questions that separate real engineering from resold templates.
What drives the cost of an AI chatbot?
AI chatbot cost splits into a one-time build, driven by content, integrations, languages and testing, and a running cost driven by usage. A good proposal keeps the two separate.
The one-time build depends on how much content has to be gathered and cleaned, how many systems the chatbot connects to, how many languages and channels it serves, how strict the handoff and security rules are and how much testing the risk requires. A chatbot that answers from twenty help articles on one website is a small project. One that looks up orders, books appointments, works in several languages and runs inside a mobile app is a much larger one.
The running cost depends on usage, because most language models are billed by the amount of text they process. Add hosting, monitoring and the time someone spends reading conversations and updating content. Measure the cost per resolved conversation during a pilot and compare it with the cost of a person answering the same question. For how AI projects are scoped more broadly, from a single feature to a full product, see our guide to AI development services.
What mistakes sink an AI chatbot?
Most chatbots that disappoint share five mistakes: launching without clean content, letting the model hold the facts, giving no way to reach a person, testing only friendly questions and neglecting the chatbot after launch.
- Launching without clean content. A chatbot built on outdated or contradictory material will repeat it confidently.
- Letting the model hold the facts. Prices, stock, balances and policies belong in your systems and sources, where they can be checked and updated.
- No way to reach a person. Every chatbot needs a clear handoff, and the person who takes over needs the conversation history.
- Testing with friendly questions only. The questions that break a chatbot are the ones users ask when they are confused or annoyed.
- Launch and forget. Content changes, products change and models change. Someone has to own the chatbot after launch.
How we approach chatbot projects
AI chatbots are part of our AI development service. We develop AI features, systems and complete products tailored to the business: AI agents, automations and custom solutions using AI models, API integrations, machine learning and mathematical models, from architecture to deployment. We can integrate a chatbot into a system you already run or build a new product around it, so you do not need to start from scratch. One team handles the architecture, UX/UI, backend and AI integration, testing and launch, which matters for a chatbot because the conversation, the data and the interface have to be designed together. After launch, we can continue with maintenance, optimization and new features.
What does a data-grounded assistant need?
Plainhub's AI finance agent answers questions about a founder's own cash, burn and runway. The founder sees those figures on the dashboard, so any answer that disagrees with them is wrong in a way that is easy to spot. For that reason the agent reads the figures the live model has already calculated. If you plan an assistant that talks about a customer's data, decide which system owns each number before you decide anything about the chat window. More about the product is in the Plainhub case study.
FAQ
What is AI chatbot development?
AI chatbot development is building a conversational assistant on top of a large language model so that it answers from your own content and data, connects to the systems it needs, and hands the conversation to a person when it should. The model is a small part of the work. Most of the effort goes into preparing the content it answers from, the integrations, the handoff rules, testing against real questions and monitoring after launch.
How is an AI chatbot different from a scripted chatbot?
A scripted chatbot follows buttons and decision trees you write in advance, so it is predictable but stops being useful the moment a visitor asks something outside the script. An AI chatbot can handle varied phrasings of a question and writes its own answers, which covers far more real questions. That flexibility is also why it needs grounding in your content and clear limits, so it does not invent policies, prices or facts.
How do you stop an AI chatbot from making things up?
Give it a defined set of sources to answer from and instruct it to answer only from them, ideally with a link to the source it used. Keep facts that must be exact, such as prices, stock levels or account balances, in your own systems and have the chatbot look them up through an integration instead of recalling them. Then test it against questions it should refuse or hand over, and read real conversations after launch.
Should we use an off-the-shelf chatbot or build a custom one?
Use an off-the-shelf chatbot when your questions are general, your content already lives in the tool (for example your helpdesk articles) and you do not need it to act in your own systems. Build a custom one when it has to work with your own data or business logic, sit inside your product, follow controls you define, or behave the same way across several languages and channels.
Where to start
Send us the questions your customers ask most and the system that holds the answers, at hello@ozgnstudio.com. We will tell you whether a chatbot, an agent or a better FAQ page is the right first step. The rest of our AI work is on the AI development service page.