How to Build a Chatbot That Solves a Real Customer Problem

Build a chatbot around one customer problem and a reliable next step. Begin with a narrow scope, approved information, an accessible interface, and a route to a person. Add AI only when it improves that workflow enough to justify its uncertainty and operating cost.

This guide uses Order Help, a hypothetical website assistant for delivery-policy questions. It is a design example, not a deployed Hapy client system or a tested vendor configuration. It answers public policy questions and opens a support route; it cannot view orders, issue refunds, or collect payment details.

Choose a measurable job

For Order Help, the job is to help a visitor find the applicable delivery information or reach support with context. Measure whether people reach the correct answer or handoff, whether answers remain accurate, and whether unresolved contacts decrease.

Do not count a closed chat as a resolved problem. A visitor may leave because the answer is wrong or the route to support is missing. Compare the new experience with the existing help page and support process.

Understand the different mechanisms

Mechanism	What it does	What it does not do
Rules and menus	Follow explicit branches and approved replies	Understand arbitrary language
Retrieval	Find relevant approved material	Guarantee that the selected passage answers the question
Conversation memory	Keep selected context between turns	Automatically retrain the model
Model training or fine-tuning	Change model behavior through a separate learning process	Keep business policies current by itself
Generative model	Interpret or draft a response from supplied context	Establish that the answer is true or an action is authorized

A chatbot can combine these mechanisms. A pre-trained model does not require a large custom training dataset for every application. Start by testing whether rules or retrieval already meet the need.

Design the conversation before choosing a platform

Order Help begins with an explicit description: it is an automated helper for public delivery information. Offer three clear choices: delivery policy, a problem with an order, and contact support.

The policy branch links to the current policy page. The order-problem branch explains that a support agent must review account-specific questions. Both provide a route to the actual support form and let the visitor return to the menu. Never claim that a person has joined or that a ticket exists before the handoff succeeds.

Use brief labels, visible focus, keyboard operation, and text that a screen reader can follow. Let visitors close the widget and read the normal help page. Customize tone and layout without disguising the bot as a human.

Configure a small rule-based version

For a plain HTML and JavaScript implementation, keep approved destinations in one configuration object. These are placeholder routes to replace with your site’s real pages before deployment:

const routes = {
  delivery: { label: 'Delivery policy', href: '/delivery-policy/' },
  orderIssue: { label: 'Get help with an order', href: '/support/' },
  human: { label: 'Contact support', href: '/support/' }
};

function destination(choice) {
  return Object.hasOwn(routes, choice) ? routes[choice] : routes.human;
}

Render buttons or links from this allowlist using text content rather than injecting visitor input as HTML. Unknown choices go to support. This example needs no model, account data, or custom training. It is a routing fragment, not a complete widget or production security implementation.

A hosted builder can implement the same branches. Verify its current interface, embedding method, accessibility, data handling, and handoff behavior in the selected account. Do not follow anonymous “Publish” button instructions from a different product.

Add AI only for a demonstrated gap

If visitors cannot find answers through the menu, test a model-assisted version against real, permissioned examples. Retrieve only approved public policy content and return its source link. Missing, conflicting, or account-specific information should produce a bounded handoff rather than a guess.

Treat retrieved pages and messages as untrusted input. OWASP’s prompt-injection guidance describes why instructions embedded in content need controls beyond a prompt. Keep tools narrowly scoped and enforce permissions in the application.

For this example, retain read-only access and no refund or record-update tools. If account access is added later, authenticate the user and enforce record ownership before retrieval. A model’s assertion of identity is not authorization.

Set privacy and retention boundaries

Do not request passwords, full payment-card information, or unnecessary personal details in the chat. For support handoff, collect only the fields the support process needs and explain where they go.

Before using old emails or tickets for evaluation or training, confirm permission, remove unnecessary personal and confidential information, and review provider handling and retention. Conversation memory should have an explicit purpose, access policy, and deletion path; indefinite storage is not a default product benefit.

Evaluate answers and failure paths

Create a case list with the input, expected route or answer, source, and pass condition. Include ordinary delivery questions, ambiguous requests, stale policies, unsupported languages, attempts to obtain another customer’s details, and unavailable support services.

For the menu version, check every defined branch and unknown input. For a generative version, repeat representative cases and review correctness, grounding, privacy, escalation, latency, and review effort. Do not trust self-reported model confidence as the only release gate.

Block launch if the bot exposes unauthorized information or makes a consequential commitment outside its scope. Set service-specific quality targets with the support owner rather than borrowing a universal accuracy percentage.

Deploy through a controlled path

Install the widget or script on staging using the chosen implementation’s documented method. Replace placeholder routes, validate links, test mobile and keyboard behavior, and confirm that privacy and consent handling match the actual deployment.

Connect the support destination and test successful submission, duplicate clicks, timeouts, and error messages. Verify analytics against successful handoff, not only button clicks. Publish to a limited audience first and retain an easy way to disable the bot while leaving support available.

Budget for operation

Estimate setup, design, content preparation, integrations, evaluation, hosting, monitoring, support, and future changes. For an AI version, add model calls, retrieval, storage, and human review. Capacity limits and service outages still exist; a bot does not serve unlimited customers at no additional cost.

An illustrative calculation: if 1,000 monthly conversations save two minutes each, the gross capacity is about 33 hours. If review and maintenance take 15 hours, the potential net capacity is about 18 hours before other costs. Those assumptions need measurement, and capacity is not cash savings unless an expense falls.

Maintain the content and handoff

Name an owner for policy changes, failed conversations, escalation queues, permissions, and incidents. Review unresolved contacts and add relevant cases to the evaluation set. Retire answers whose sources are no longer valid.

A useful chatbot earns its place through correct answers and successful handoffs. Use Hapy’s AI automation guide when the workflow grows beyond a small helper into a system that interprets information and acts across tools.

For a chatbot that acts across business systems, scope the permissions, exception handling, and human handoff in a business automation engagement.