How to build an AI chatbot for customer support

Most support chatbots fail in the same way. They answer confidently from nothing, they cannot see the customer’s account, and there is no path to a person. The model is not the hard part. The boundary is.

Decide the job before the vendor

Write the questions the bot is allowed to answer. “Where is my order” needs your order system. “What is your return window” needs a page you already trust. “Can you refund me” is usually a human.

If you cannot list the allowed questions, do not buy a bot. Buy an hour to write the list.

Retrieval beats a clever prompt

Answers about your product should come from documents you control: help articles, policies, a short FAQ you would put your name on. Index those. Do not let the model improvise policy. Say, in the product, when the bot does not know.

Permissions matter. A bot that can see every customer’s orders because the API key is an admin key is a data incident waiting for a prompt.

The handoff is the feature

Define the sentence that ends the bot’s turn: low confidence, an angry message, a billing question, or the user asking for a person. The handoff should create a ticket your team already uses, with the transcript. A bot that traps the user in a loop is worse than no bot.

Fallback and cost

Providers time out. Have a visible failure, not an endless spinner. Put the API key on your account so the usage bill is yours and you can cap it. Log what was sent to the provider so your privacy policy can describe it accurately.

What to skip

Custom model training, for almost every support desk we see. A workflow tool or a simple form is enough when the “AI” was really “we have no link to the status page.” The service page for this work is AI and automation. Scope one job. Ship the handoff. Then add the next question type.