How to Build an AI Chatbot

Updated September 15, 2026 · AI-assisted guide. Sources and illustrative examples are identified below.

TL;DR: Build a useful AI chatbot by choosing one customer task, supplying approved answers, defining its limits, and testing the complete journey through resolution or handoff. Launch when those checks pass and someone owns the ongoing work. A working chat window alone does not establish readiness.

---

Editorial update: This guide replaces broad promises about rapid deployment and business results with a practical planning and acceptance process. The examples are illustrative, not DOYJO client results.

Define the job before choosing the software

Write a one-sentence job for the first release. For an illustrative home-service company, it might be: “Help visitors understand our service area and request an estimate using the correct contact route.” That is specific enough to test. “Improve customer engagement” leaves the builder guessing about what success means.

List the questions that belong in that job, using your actual inquiries where available. Remove personal details that the project does not need. Ask staff which questions have dependable answers and which require inspecting a property, checking an account, or making an exception. An assistant cannot fix an unclear policy by rephrasing it confidently.

Set a practical completion standard. In this example, a visitor should find an accurate service-area answer or reach the estimate request page with clear expectations. A long conversation, a friendly reply, and a clicked link are observations. They do not by themselves prove that an inquiry reached the business.

Choose what the chatbot can answer and do

Separate three capabilities: explaining published information, reading private or changing information, and taking an action. The first release may only need the first. Linking to a booking page is simpler than checking availability and reserving a time inside chat.

This scope table also helps you evaluate software. A feature that sounds impressive in a demonstration may add no value to the selected job. Add capabilities when a real task requires them and the surrounding process can support them.

Prepare a small, maintained source collection

Collect the approved pages for services, prices, locations, policies, and contact options. Resolve contradictions before connecting them. If one page gives an old phone number or a discontinued offer, remove or correct it at the source.

For each source, record an owner and a review trigger. A pricing change should prompt an assistant check; waiting for a calendar reminder could leave a wrong answer live. Preserve links so a visitor can read the underlying information.

AI Engine documents several ways to provide business context, including instructions, page content, retrieved knowledge, and dynamic information. These have different purposes; connecting a knowledge collection is not the same operation as retraining a model. See AI Engine’s business-knowledge guide. Test the chosen setup with your content rather than assuming the model already knows your business.

Write behavior that matches the scope

Give the assistant a clear identity, a short description of its job, approved sources, and a useful response when information is missing. Specify how it should handle requests outside the project, including a direct route to a person.

For our illustrative service company, a useful uncertain answer is: “I cannot confirm coverage for that address from our published service area. The office can check it through the estimate request page.” This is more useful than guessing or repeatedly asking the visitor to rephrase.

Write examples of acceptable and unacceptable answers. Include a pricing question that requires qualifications and a request for a guarantee the business does not offer. These examples become repeatable review cases. Instructions guide behavior, but testing is still needed; a sentence telling a model to be accurate is not a substitute for checking its answers.

Build the complete handoff

A human handoff has a destination, an owner, and an observable outcome. Decide whether the assistant opens a contact page, creates a ticket, or transfers to staffed live chat. Describe exactly that behavior to the visitor.

If staff are unavailable, explain the next step using the business’s actual published expectations. Do not imply a person is joining when the system only stores a message. If you promise to preserve the conversation, verify that the receiving team can see it and has permission to use it.

For an inquiry workflow, test the destination with designated test data and the business’s authorized recipients. Verify receipt, routing, and the visitor’s confirmation message. Mark test records clearly. A successful button click does not establish delivery, and a draft ticket is not a submitted ticket.

Test realistic failures as well as correct answers

Create a review sheet containing the question, expected behavior, actual answer, source, and result. Include normal phrasing, misspellings, follow-up questions, missing information, contradictory sources, a request for a person, and an attempt to push the assistant outside its role. Keep a stable set for comparing changes.

Check whether the answer is accurate, relevant, sufficiently qualified, and linked to the right source. For actions, verify the external result separately. Record unknown outcomes instead of quietly counting them as successful resolutions.

Make release blockers explicit. Examples include revealing another customer’s information, inventing prices, falsely confirming an appointment, or trapping a visitor in a conversation. Cosmetic preferences can go into a later improvement list. A small test set cannot prove universal reliability, but it can expose concrete problems before more visitors encounter them.

Check mobile use, accessibility, and waiting states

Open the assistant on a narrow screen and complete the chosen task. Check that the keyboard does not hide the input or send control, long answers remain readable, links work, and the close button is reachable. Repeat using a keyboard and representative assistive technology.

Visitors should understand when a request is processing and when it has failed. W3C’s guidance on accessible status messages explains how relevant updates can be conveyed without requiring focus to move. Test the implemented widget, including its changing messages, rather than assuming a plugin label establishes accessibility.

Measure the time until an answer starts and the time until it finishes. Streaming text may make the first response appear sooner while the full task still takes longer. Check slow connections and expected busy periods. Add voice only when users need it and you can test its extra interaction requirements.

Set an operating budget and a stop procedure

Account for setup, platform fees, model usage, connected services, and staff review. Estimate a normal month and a busy month using explicit assumptions. Record what happens when a spending or usage limit is reached so the fallback is understandable.

Name the person who can pause the assistant, correct a source, and contact the implementer. Keep a record of the active configuration and an available return path to the last working version. A model or plugin update should trigger relevant checks before you rely on its changed behavior.

During a pilot, compare the complete workload with the old process, including corrections and repeat contacts. Expand only when the measured value and quality justify it. An improved FAQ, search function, or intake form can also be a successful outcome of the review.

Bring a concrete brief to your project review

Bring your chosen customer task, approved pages, existing contact workflow, test cases, expected volume, and operational owner. Those details let a developer assess the actual work and identify dependencies before quoting it.

A Sheboygan business serving nearby communities may need careful service-area answers; a company serving customers nationwide may need different routing and availability rules. DOYJO can help assess these requirements through AI Curdy’s AI integration services. The right first release is the one your business can maintain and your visitors can successfully use.

Keep exploring

• Prepare business knowledge for a chatbot
• Measure chatbot resolution accurately
• Explore AI Curdy’s practical AI guides

Have a question this guide should answer? Send it to AI Curdy, or share the guide with the person responsible for your customer support workflow.