What should an AI chatbot know before launch?

Give the chatbot one useful job

An AI chatbot should begin with a narrow customer problem, not a promise to answer everything. A service business may need help explaining appointment preparation, directing visitors to the right service, answering routine policy questions, or collecting enough context for a person to continue the conversation.

The first question is therefore not which model to use. It is what the customer should be able to accomplish.

A chatbot is ready when its job, sources, boundaries, destination, and owner can all be named.

A clear job makes the conversation easier to design and the result easier to test. It also prevents the chatbot from becoming a decorative layer that talks without moving the customer forward.

Identify the conversations worth supporting

Review real customer questions from contact forms, sales calls, support messages, email, website search, and staff interviews. Group them by the action a useful answer should support.

Common groups include:

• Understanding whether a service is relevant.
• Finding a policy, instruction, location, or operating detail.
• Preparing for an appointment, purchase, or consultation.
• Comparing service paths without making a sensitive recommendation.
• Booking, enquiring, or reaching the correct team.
• Checking information tied to an authenticated account.

Frequency matters, but it is not the only condition. A rare question may still deserve careful handling if an incorrect answer would create a serious customer problem.

Start with a collection of real wording. Customers rarely ask questions using the same terms as the website navigation or internal team.

Define the approved source material

A grounded chatbot should answer from information the business has reviewed and is prepared to maintain. That may include:

• Service pages and approved product information.
• Help-center articles and operating instructions.
• Policies, eligibility rules, and appointment guidance.
• Location, availability, and contact information.
• Internal knowledge that is appropriate for the selected audience.
• Structured records available through a supported and permission-aware integration.

The source inventory should record an owner, last review date, intended audience, and any restriction on use. If two sources conflict, resolve the conflict before expecting the chatbot to choose correctly.

Public website copy is not automatically a complete knowledge base. Important answers may be spread across pages, buried inside documents, or written for marketing rather than direct customer use.

Improve the knowledge before connecting it

AI cannot make an unclear policy authoritative. Review the source material for gaps and ambiguity:

• Does the information give a direct answer before background detail?
• Are service names, locations, and requirements consistent?
• Are dates and conditions current?
• Does each policy identify exceptions or the person who can clarify them?
• Can the answer be understood without internal terminology?
• Is the material appropriate for the audience using the chatbot?

This cleanup often benefits the website, sales team, and support documentation even before the chatbot is built.

Decide what the chatbot must not answer

Boundaries are part of the product, not an error message added at the end. Write down the subjects that require a person, a verified account, or a different professional context.

The chatbot may need to avoid:

• Making commitments about price, delivery, eligibility, or outcomes that depend on individual facts.
• Interpreting legal, medical, financial, safety, or compliance questions beyond approved general information.
• Revealing private account or customer data without appropriate identity and permission controls.
• Inventing an answer when approved information is missing.
• Presenting a recommendation as a final business decision when judgment belongs to a person.

A useful fallback is specific. It should explain that the available information cannot support a reliable answer and offer the right next action.

Design answers around the next customer action

An accurate paragraph is not enough if the customer still does not know what to do. Each conversation group should have an intended destination.

Buttons, links, forms, scheduling, and CRM capture should be part of the conversation design where they serve the customer’s objective. The chatbot should not collect information merely because the technology permits it.

Make human handoff part of the first release

Customers need a clear way out of the automated conversation. Handoff should occur when the customer asks for a person, the question falls outside approved knowledge, the situation becomes sensitive, or the chatbot cannot resolve repeated clarification attempts.

A dependable handoff answers four questions:

1. Which team or queue receives the conversation?
2. What context follows the customer so they do not need to start over?
3. What response expectation is communicated without making an unsupported promise?
4. What happens when the normal recipient is unavailable?

If the chatbot creates a lead, the record needs the source, conversation summary, relevant selections, consent context, and an owner. The larger diagnostic in Where leads get lost between website and CRM can help test what happens after the chatbot says the enquiry was submitted.

Limit data collection to the job

Decide what the chatbot genuinely needs before asking for names, contact details, account information, uploaded documents, or conversation history. Data decisions should reflect the customer purpose, the system receiving the information, access permissions, retention practices, and the business’s applicable obligations.

Practical questions include:

• Can the question be answered without identifying the customer?
• Which fields are required for the next action?
• Where will the conversation and submitted information be stored?
• Who can access it?
• Does information pass to an external model or service provider?
• How can the team remove or correct a record when appropriate?

These are design and governance questions. Businesses should obtain qualified advice for legal or regulatory requirements that apply to their data and industry.

Write realistic test conversations

Testing should begin before implementation. Create a set of questions that includes normal requests, vague wording, missing information, conflicting sources, unusual phrasing, and requests the chatbot must refuse or escalate.

For each test, define:

• The required facts in a correct answer.
• Any statement the chatbot must not make.
• The approved source supporting the answer.
• The intended next action.
• Whether a person should take over.

The NIST Generative AI Profile describes testing and evaluation as part of managing generative AI risk. For a small-business chatbot, that principle becomes concrete through a maintained test set, human review, and documented handling for failures.

Evaluate more than whether the answer sounds good

A fluent response can still be incomplete or unsupported. Review chatbot performance across several dimensions:

Repeat important tests after model, prompt, source, integration, or policy changes. A launch test is not a permanent assurance.

Give the chatbot an operational owner

Someone should be responsible for reviewing failed searches, escalation patterns, outdated sources, customer feedback, and integration errors. Ownership may be shared across customer service, operations, marketing, and technology, but the responsibilities should not be assumed.

An operating review can ask:

• Which questions produced no supported answer?
• Which answers required customer correction?
• Where did visitors abandon the conversation?
• Which handoffs reached the wrong destination?
• Which source documents changed?
• Did the chatbot collect information that was not used?
• Which new question group is important enough to add?

The review should lead to source, conversation, workflow, or boundary changes. More conversation volume is not automatically a sign that the chatbot is useful.

Know when a chatbot is the wrong interface

A chatbot may not be the best choice when customers need to compare a small number of stable options, complete a structured calculation, navigate a sensitive process, or see information that is easier to understand in a table or form.

Consider a conventional interface when:

• The same few fields determine the result.
• Customers need to review all options at once.
• The process requires exact, repeatable calculations.
• Accessibility and error recovery are easier in a structured form.
• The primary problem is unclear website content rather than conversation.

The goal is not to force a conversational interface onto every task. It is to help the customer reach a correct and useful destination.

Use this chatbot readiness checklist

Before development begins, confirm:

• [ ] The chatbot has one defined customer job.
• [ ] Real customer questions have been collected and grouped.
• [ ] Approved sources are current, consistent, and owned.
• [ ] Prohibited subjects and uncertain-answer behavior are documented.
• [ ] Every priority conversation has a useful next action.
• [ ] Human handoff includes destination, context, and fallback.
• [ ] Data collection is limited to the stated purpose.
• [ ] Realistic test conversations and expected results exist.
• [ ] A person owns post-launch review and source updates.
• [ ] The business can explain why a chatbot is better than a page, form, or search interface for this task.

Build around answer quality and handoff

A useful chatbot does not replace the website, knowledge owner, or customer team. It makes approved information easier to reach and helps customers move into the correct human or digital path when conversation alone is not enough.

Appixi’s AI Chatbot Development services cover conversation design, approved knowledge connections, actions, human handoff, and evaluation. When the conversation needs to create or update customer records, Lead Capture and Routing provides the connected workflow path. Broader repeated work across several systems may be better addressed through Business Process Automation.