AI Chatbot Development

How good a chatbot turns out depends less on the model than on the decisions made before anyone picks one: which questions it answers, which documents it relies on, which systems it may write to and at what point it stops and hands the conversation to a person. This guide walks through those decisions in the order a business owner faces them in an AI chatbot development project, with each technical term explained briefly.

The aim is to help you ask any vendor the right questions and to judge, with your own data, whether the bot earns its place after launch. Several sections also cover cases where a chatbot is the wrong answer.

01Audit your message logs before deciding

Make the chatbot decision from four to six weeks of real messages, not from a hunch. Export what arrived by email, WhatsApp, Instagram and your contact form, strip personal details and tag every message with one topic. That simple sheet shows what a bot could take over and what it should never touch.

While tagging, answer these questions for each message:

• Is there a written answer: If the correct reply lives on a page, in a document or in a system, a bot can use it; if it only lives in one employee's head, it has to be written down first.
• Is it personal: Questions where the fee depends on the case, or that need medical or legal judgment, belong with a professional, not a bot.
• Does it need live data: Order status, free slots or stock levels can only be answered once the bot is connected to the system that holds them.
• When did it arrive: If evenings and weekends are busy, a bot that only runs outside business hours is a sensible pilot.

If repetitive questions with written answers are only a small share of the total, a stronger FAQ page and saved reply templates give the same relief with less risk. Either way the sheet becomes the raw material of your first test set.

02The bot's job and limits by business type

The same technology does very different work from one sector to the next, and every job comes with its own list of things the bot must never do. Write both lists in the same document; the second one often matters more.

• Online store: Answers shipping, returns and sizing questions and reads order status; never approves a return, never invents a discount code, passes complaints to staff.
• Clinic or salon working by appointment: Explains services and shows open times; never diagnoses, never recommends treatment, never asks for health details.
• B2B service firm: Asks about the visitor's industry, need and timing and routes them to the right person; never quotes an amount, never interprets contract terms.
• Hotel or restaurant: Handles amenities, directions and booking requests; never confirms a room or table without checking live availability.

When a company has two distinct needs, such as pre sales lead capture and after sales support, building them as separate flows rather than one crowded bot makes testing and measurement far easier. Start with the topic that eats most of your team's time.

03The architecture in plain words

A chatbot tied to your sources has four layers, each with its own job. Ask every vendor to walk you through them one by one; if they cannot, what you are being offered is a chat window and little else.

• Retrieval layer: When a question comes in, the most relevant passages are pulled from the knowledge base. This is called RAG, retrieval augmented generation: the model writes its answer from those passages, not from its general knowledge.
• Instruction layer: The system prompt defines the bot's role, tone, scope and prohibitions. Whatever the user types, these rules take priority.
• Tool layer: For actions such as looking up an order or finding a free slot, the model calls predefined functions. This is known as function calling; the model never touches your database directly, only the doors you allow.
• Review layer: Before an answer reaches the user it is checked; if it contains an unsourced claim, a price commitment or personal data, it is blocked or a handover starts.

This split lets you locate an error: a wrong answer more often comes from a badly retrieved passage or an outdated text than from the model itself. Solid AI chatbot development logs which source produced every answer.

04Writing a knowledge base the bot can use

Accuracy depends directly on how the knowledge base is written, and a page that works for a human reader can be ambiguous for retrieval. The system splits text into chunks and picks the chunk closest to the question, so each chunk has to make sense on its own.

• One paragraph, one topic: If the return window and the shipping fee share a paragraph, the bot may mix them up; give every rule its own heading.
• Repeat the context: Write the service name instead of "this service", so a chunk read in isolation still says what it is about.
• Add a date and an owner: Every document carries its last updated date and the name of the person responsible; expired promotions move to an archive.
• Remove contradictions: If two documents give two answers to the same question, the bot picks one at random; decide which is valid and delete the other.
• Write the prohibitions down: Rules such as "the bot does not discuss payment terms on corporate invoices and refers to accounting" belong in the knowledge base too.

Plain sentences improve both the answer and the precision of retrieval; to spot long, nested sentences, run your texts through the readability checker. When hours, terms or services change, the knowledge base is the first thing to update.

05Integrations, channels and write permissions

The first decision when connecting a bot to a system is to separate read access from write access. Reading an order status is low risk; creating or canceling an appointment or changing a CRM record should never happen without explicit user confirmation. The bot shows a summary, acts only after confirmation and logs the result.

For businesses that run on appointments, the bot connects through an API to the calendar of an appointment booking website; open slots are queried live every time, never from a stale copy. On the CRM side each lead is stored in proper fields, such as name, preferred contact method, topic and source channel, rather than as a block of free text.

Channels bring their own rules. On the WhatsApp Business Platform, a 24 hour customer service window opens when a customer messages you; outside that window a business may only send templates Meta has approved. Meta's platform terms also prohibit uses whose primary purpose is offering a general purpose AI assistant; a bot that serves your own customers within a defined scope is not the target of that rule. Channel specific setup is covered on the WhatsApp AI assistant page, and the handover link takes a minute with the WhatsApp link generator.

06Choosing a model, hosting and fallback

Choose the model by the language quality, speed and data terms the job needs; the newest or largest model is not automatically the right one. Decide with your own test set rather than reputation: put the same 50 to 100 questions to two or three models and score the answers against the same criteria.

• Language quality: Grammar, tone and consistency in every language you serve, judged by a native reader.
• Faithfulness to sources: Does the model add facts that are not in the passages it was given; this matters more than fluency.
• Latency: Users expect the first words within a few seconds; a slow model frustrates people even when the reply is streamed word by word.
• Data terms: Whether the provider trains on your data, how long it keeps it and in which region it is processed, checked in writing.

An open model on your own server keeps data in house but adds hardware, updates and security work; for most businesses a paid API tier is more balanced. Whichever you choose, route all model calls through a single middle layer, so a request moves to a backup model when a provider fails and switching models later does not disturb the knowledge base. Ask about this layer in every AI chatbot development proposal.

07Conversation design from greeting to close

Good conversation design lets users understand within the first exchange what the bot can help with. The welcome message states that it is AI, names the topics it covers and says a person is available on request. Presenting the bot as a staff member, with a human name and photo, works against transparency and damages trust once people notice.

Answers fit a phone screen: two or three sentences and a source link. An ambiguous question gets one clarifying question, such as which location the customer means, instead of a guess. Fixed steps like bookings or return requests use buttons and short form fields, so flexibility stays with open questions and critical steps follow rules.

On binding topics such as fees, contract terms, refund rights or delivery dates, the bot makes no firm promise; it cites the source and routes confirmation to your team. This is a legal precaution, not a style choice. In Moffatt v. Air Canada (2024), the Civil Resolution Tribunal of British Columbia held the airline liable for a bereavement fare policy its website chatbot had described wrongly, and rejected the argument that the bot was a separate entity. What your bot writes can count as your statement, just like any page on your site.

08Handover triggers and the handover note

Handover is part of the design, not a failure of the bot, so when and how it happens is written down from the start. Triggers are defined as an explicit list, and each one is logged as the handover reason.

• User request: When someone asks for a person, the bot hands over without trying to talk them out of it.
• No source found: If retrieval finds nothing relevant enough, the bot says it does not know and offers a handover.
• Sensitive topic: Complaints, legal threats, health problems or payment errors go straight to staff.
• Repeated loop: If a user has rephrased the same question twice, the bot stops trying on the third attempt.
• High value request: Large orders or enterprise quote requests reach sales with an instant alert.

The note your team receives is short and standardized: name and preferred contact method, a one sentence summary of the request, the answers already given and the handover reason, so staff can continue without making the customer repeat anything.

Outside business hours, the bot says honestly when someone will reply and records the details, rather than saying "connecting you now" and leaving the user in an empty window.

09Test sets, attack attempts and version control

Before launch the bot is tested against a question set with the correct answers written in advance, and that set runs again after every change. It should not contain only easy questions; it should deliberately include the cases where a mistake would be costly.

• Routine questions: The most frequent questions from your message sheet, in different phrasings and with typos.
• Out of scope questions: Competitors, politics or medical advice, topics the bot must decline.
• Manipulation attempts: Messages such as "ignore your previous instructions" that try to break the rules. This is called prompt injection; the test checks that the bot never reveals its own instructions or another customer's data.
• Commitment traps: Questions like "can you promise me half off" that push the bot toward a binding statement.

Each answer is scored correct, partly correct or wrong, and wrong answers on critical questions block the launch. The knowledge base, system prompt and model version are numbered together, so if an update causes trouble you can roll back within minutes.

Providers also update and retire models, so the test set runs whenever the model version changes. Testing reduces risk without removing it; show the source under each answer, let users flag errors easily and add every flagged case to the next test set.

10Privacy: GDPR, disclosure and data transfers

A chatbot processes personal data, so before the build you need a data flow map showing what the bot collects, where it sends it and how long it is kept. Under the GDPR, users must be informed before the chat starts; a short notice in the window with a link to your full privacy policy is a sound starting point.

Health data is a special category under Article 9 of the GDPR. Clinics, pharmacies and similar businesses should not ask for symptoms in the chat, and should mask such details in logs when users volunteer them. If the model provider sits outside the EU or EEA, that is an international transfer and needs one of the bases set out in the GDPR, alongside a data processing agreement with the provider.

• Data minimization: A name and one contact detail are usually enough for a lead; ID numbers are never requested.
• Masking in logs: Phone numbers, e-mail addresses and card numbers are partly hidden in reporting views.
• Retention period: How long chat logs are kept is set in writing, and automatic deletion runs when the period ends.
• Access roles: Who can read logs and who can export them are defined separately.

Article 50 of the EU AI Act adds a transparency duty for systems that interact directly with people, which the welcome message covers. Outside the EU, check the rules of each market you serve; your legal adviser makes the final assessment.

11Rolling out from pilot to full use

In an AI chatbot development project the bot does not go live on every channel at once; it expands step by step as evidence comes in. Timing depends on message volume and the number of integrations.

1. Discovery: The message sheet, the system list and the bot's list of prohibitions are drawn up together, and the scope is put in writing.
2. Knowledge base and test set: Correct answers are matched to their source documents, and expected answers for test questions are written.
3. Internal prototype: The bot is opened to your staff only; for a week they try it with real questions and flag wrong answers.
4. Narrow pilot: The bot goes live on one channel, for example only on the website and only after hours; every conversation is read in the first weeks.
5. Expansion: If the error rate stays acceptable, business hours, a second channel or a new language are added.
6. Ongoing upkeep: Weekly log reviews, a monthly knowledge base check and test reruns on model updates go into the calendar.

For businesses serving several languages, each new language should be treated as its own pilot, with a knowledge base written in that language and language specific test questions. If your site's language structure is not ready yet, setting up a multilingual website first also settles which page the bot cites in which language.

12Measuring value and using unanswered questions

After AI chatbot development, value shows up in several measures that keep each other honest, not in one number. The share of chats closed without a handover only means something next to the accuracy score from manually read samples; if one rises while the other falls, the bot may be closing conversations with wrong answers.

• Correct resolution rate: The share of answers in a weekly random sample that match the source and are complete.
• Handover reasons: How often each trigger fires; a rise in "no source found" points to a gap in the knowledge base.
• Lead conversion: How many bot captured leads move on to a call, an appointment or a sale, tracked in the CRM.
• User feedback: A one click "was this helpful" at the end of the chat, stored with any comment.

The most valuable output is often the list of unanswered questions. Review it weekly: some items become new knowledge base paragraphs, some reveal a missing page on your site and some stay deliberately out of scope, which turns the bot into a record of what customers cannot find.

13Common mistakes in AI chatbot development

Most problems in chatbot projects are not technical; they come from making decisions in the wrong order. These mistakes come up often, and each has a better alternative.

• Starting with the chat widget: Picking the look first and thinking about content later produces an empty shell; start with the question list and the source documents.
• Feeding the whole site into the knowledge base: Old promotions and blog posts get indexed and the bot quotes expired terms; select only approved, current documents.
• Granting write access without confirmation: A bot that can cancel bookings or delete records can do damage on a single misunderstanding; tie every write action to user confirmation.
• Hiding the way to a person: Making humans hard to reach lowers the handover rate and loses customers; keep the handover option visible in every chat.
• Never reading the logs: Watching only the chat count hides errors; make weekly sample reading part of someone's job description.
• Launching without briefing staff: A team that does not know what the bot says will contradict it after a handover; brief them before the pilot and share the list of prohibitions.
• Accounts in the agency's name: If the model or messaging account belongs to someone else, the bot leaves when the partner does; open accounts in your company's name.

14Choosing a partner and the next step

The right partner asks about your messages and your systems in the first call rather than showing off a chat screen. Ask every vendor for written answers on these points:

• Do the logs show which source produced each answer, and how do you trace the cause of a wrong one?
• Who writes the test set, and what error level is accepted before launch?
• If the model provider changes, do the knowledge base and integrations stay in place?
• Who holds the accounts, the system prompt and the knowledge base at handover?
• Are a draft privacy notice and the data flow map part of the delivery?

Our AI chatbot development work runs as part of our AI automation services; when you need a separate customer portal or dashboard, that work moves to custom software development. We do not yet have a live client chatbot to show, so we describe our method rather than claim results; our automation, software and web projects are on the references page.

Cost depends on the number of channels, the systems to connect, the size of the knowledge base and the scope of upkeep; fixed price discovery options are listed on the pricing page. Send your ten most frequent customer questions and the systems you use through the contact form, and we will define the bot's scope, handover rules and a written quote with you.