How to create a chatbot in seven steps, and when not to

The short version

• A chatbot should start with one job and a list of real questions, not a general brief to help customers.
• The right way to build a chatbot is the simplest route that passes your test questions: no-code, then a vendor agent, then custom code.
• A chatbot repeats your content, so outdated or conflicting documents become confident wrong answers.
• Prompt instructions guide a chatbot but enforce nothing, so limits on money, data and permissions belong in code.
• A chatbot is ready to launch when it has passed a real question set, has a working human handoff and has a named owner.

What are the steps to create a chatbot?

1. Choose one job and collect a few dozen real questions for it from your tickets, inbox or chat logs.
2. Choose a build route: a no-code builder, a vendor agent or custom code.
3. Connect the chatbot to a small set of approved, current content.
4. Write its instructions: scope, tone, what to decline and when to hand over.
5. Test it against the real questions and mark every answer right or wrong.
6. Add a human handoff that passes the full conversation to the person taking over.
7. Launch to limited traffic, read the failed conversations every week and widen only when the results hold.

How do you decide what a chatbot should do?

Give it one job with a clear finish line, such as answering delivery questions, booking an appointment or finding a clause in an internal policy. 'Help our customers' is not a job. It cannot be tested, because nobody can say when it has succeeded.

Before making a chatbot, collect a few dozen real questions for that job, in the words people actually used. Tickets, shared inboxes, call notes and site search logs are the usual places. Keep the awkward ones: the misspelt, the angry and the two questions in one. This list shows whether the questions repeat enough to justify a chatbot. It also becomes your test set later.

Decide who the chatbot is for as well. A public chatbot speaks to strangers, so it needs tighter limits than an internal one speaking to staff whose identity you already know. Building a chatbot for both at once means two sets of content rules in one system, so start with one audience.

Should you use a no-code builder, a vendor agent or custom code?

Use the simplest route that can do the job. A no-code builder suits a scripted flow or questions over a small body of content. A vendor agent suits customer support on a helpdesk it already integrates with. Custom code is for when the chatbot must act inside your own systems or follow rules a product cannot express.

The steps for how to build a chatbot stay the same on every route. What changes is who does the work and who carries the risk. Developing a chatbot from scratch means owning retrieval, testing, monitoring and every model change after launch. That is worth it only when a bought product blocks something you need. Try the simpler route first with your test questions, and let a specific failure justify the next one.

Compare running costs on your own volumes, because pricing models differ. Intercom's published pricing for its Fin agent, which is one vendor and not a market survey, applies a minimum of 50 outcomes per month when Fin runs on a non-Intercom helpdesk. So check what counts as a billable outcome and what the minimum is before you compare list prices.

For a custom build, the main cost is engineering time. Use your own payroll figure if you have one. The US Bureau of Labor Statistics publishes a May 2025 median for software developers, excluding self-employed workers. The page does not say whether benefits are counted, so do not treat it as the full cost of employing someone.

How do no-code builders, vendor agents and custom code compare?

How do you give a chatbot your company's knowledge?

Connect it to a small set of approved documents through retrieval. At question time, the system searches that content and passes the most relevant passages to the model. Answers then follow your documents as they change, and you avoid stuffing everything into the prompt.

The content is where much of the work sits. If two documents disagree, the chatbot will use whichever passage the search ranks higher, and it will sound equally sure either way. So remove outdated pages, resolve contradictions and name an owner for each source. Add a routine that updates the index when a document changes. Otherwise the chatbot will keep repeating the old refund policy after the website has moved on.

Check what the index actually holds, not what the source looks like. Scanned PDFs and tables often extract badly, and the chatbot can only answer from the text that survived.

Decide permissions now, not later. If different users may see different content, check what each user is entitled to before the search runs. Filtering answers afterwards means the model has already read what the user should not see.

What instructions should a chatbot have?

Give it a role, a scope, a tone, a rule for what to decline and a rule for when to hand over. Keep them specific enough to check a transcript against. Vague instructions such as 'be helpful' change little, because the model was going to try that anyway.

A workable starting set for a support chatbot reads like this: 'Answer only from the supplied passages. If they do not answer the question, say so and offer a person. Do not discuss pricing exceptions or legal claims. Ask at most one clarifying question.' Each line can be tested against a real conversation.

Instructions guide a chatbot. They do not enforce anything. A determined user can sometimes talk a model around its prompt, so anything that must never happen belongs in code outside the model. If the chatbot can issue a refund, the model may propose it, but your system should check the amount, the customer and the policy before anything moves. Give it the fewest tools that do the job.

How do you test a chatbot before launch?

Run your collected real questions through it and mark each answer right, wrong or correctly declined. Decide the pass mark before you read the results, and set it by what a wrong answer would cost. A wrong opening time and a wrong dosage do not deserve the same bar.

Add questions the chatbot should not answer: out-of-scope requests, attempts to make it ignore its instructions, requests for another customer's data and questions your content does not cover. A chatbot that answers everything is a warning sign. Declining well is a behaviour you have to test for.

Run the same questions more than once, because language models can answer differently each time. Keep the test set and rerun it after every change to the prompt, the content or the model, since a fix for one question can break another. Without that record, nobody can say whether the latest change helped.

When should a chatbot hand over to a person?

Hand over when the person asks, when approved content does not answer the question, when the conversation goes in circles, and when the matter carries real risk, such as money, legal exposure, health or a formal complaint. Asking for a person should work the first time.

Five9 and Hanover Research surveyed 3,000 consumers in the US, UK and Germany who had interacted with customer service, in April 2026. Five9 reports that trust still depends on having a person within reach. Five9 sells contact centre software, so read that with its interest in mind. The mechanism holds anyway: a chatbot with no exit turns its own mistakes into complaints.

Build the handoff as a feature. Pass the whole conversation, so the customer does not have to repeat anything. Decide what happens outside staffed hours: say that nobody is available, take the details and state when someone will respond. A handoff into an empty queue promises help that does not come.

How do you launch and maintain a chatbot?

Launch to a small share of traffic, one page or one channel. Read the transcripts, fix what failed and then widen. Creating a chatbot is not a one-off project. Content changes, customers ask new things and model updates change behaviour, so it needs a named owner after launch.

Measure what the chatbot actually resolved, not how many conversations it kept from your team. If you count only handoffs avoided, a customer who gave up and left looks the same as a customer who got an answer. So sample transcripts every week and check whether the answers were correct. Track how often people return about the same issue or ask for a person.

Turn each failure into a new test question, so the same mistake is caught if it comes back. Decide what you log and how long you keep it, because transcripts collect personal data whether or not you planned for it. Check your model provider's data terms before launch, not after.

When is creating a chatbot not worth doing?

It is not worth doing when your questions rarely repeat, when nobody will own it after launch, or when a wrong answer would cost more than the chatbot could save. In those cases, a better help page, a search box or a simple contact form may serve people better.

Other businesses using AI is a weak reason to start. Talkdesk commissioned Pollfish to survey 400 US small business owners in August 2025 and reports that roughly half already use AI to elevate customer service. Talkdesk sells customer service software, and the page does not define small business. Even at face value, that figure says nothing about whether a chatbot would work on your questions, with your content.

A useful check costs little. Look at your real questions. If a handful of topics recur and the answers already exist in writing, a chatbot has something to work with. If each question needs a person to look up a record or make a judgement, fix that process first, or automate it directly and skip the conversation.