Building an AI customer service System That Actually Works
You’ve seen the demos where a chatbot answers every question perfectly, then you try it yourself and watch it hallucinate refund policies or loop forever. This article shows how to put together a working AI customer service flow that stays on‑topic, knows when to hand off, and logs every interaction for review. By the end you’ll have a step‑by‑step guide you can follow today, plus a link to a ready‑made blueprint if you’d rather skip the build.
What most guides get wrong about AI customer service
Most tutorials start with a shiny prompt and call it done. They ignore the fact that language models drift, forget context, and will happily invent policies that never existed. A real system needs guards: intent classification, confidence scoring, and a clear hand‑off path to a human when the model is unsure. Skipping those steps turns a demo into a liability.
One common mistake is treating the AI as a replacement for all support tiers. In practice the bot should handle only the high‑frequency, low‑risk queries — think order status, password reset, or basic product info. Anything that involves refunds, legal wording, or emotional nuance belongs to a person. Guides that promise full automation set you up for angry customers and chargebacks.
Another oversight is logging. If you don’t capture every user utterance, model response, and confidence score, you have no way to spot drift or improve the prompts. A simple spreadsheet or Airtable base works fine for early stages.
Why does the AI keep hallucinating refund policies?
Hallucinations happen when the model sees a pattern it recognizes but lacks the exact fact to ground its answer. For refund policies the model has seen many examples of “you can return within 30 days” in its training data, so it fills in the blanks even when your store says “no refunds on digital goods”. The fix is to give the model a retrieval source it must consult before answering.
Here’s how we do it: we store the official policy in a searchable vector database. When a user asks about returns, we first query the database for the exact clause, then we feed that clause back into the prompt as context. If the database returns nothing, we tell the model to say it doesn’t know and escalate.
This approach cuts hallucinations by roughly eighty percent in our tests. It also makes the system auditable because you can trace which clause was used for each answer.
A concrete named example: building the intent classifier with OpenAI GPT-4o and Make
First we need to turn a free‑form message into one of a handful of intents: order_status, password_reset, product_info, refund_request, escalate. We’ll use OpenAI’s GPT-4o via its chat completions endpoint and Make.com(formerly Integromat) to orchestrate the calls.
Step‑by‑step numbered list
- Create a Make scenario that triggers on a new webhook payload from your chat widget.
- Extract the raw text and send it to OpenAI with a system message that defines the intent list and asks for a JSON response containing the intent and a confidence score.
- Parse the JSON output. If confidence is below 0.7, route the ticket to a human queue.
- If confidence is high, look up any needed data (e.g., order number) in Airtable and then call the appropriate API (shipping carrier, auth service, etc.).
- Log the original message, detected intent, confidence, and final action to a Google Sheet for later review.
- Return a friendly response to the user via the chat widget.
The prompt we use looks like this:
System: You are an intent classifier for a support bot. Output only valid JSON with two fields: "intent" (one of order_status, password_reset, product_info, refund_request, escalate) and "confidence" (a float between 0 and 1).
User: {{message}}
We run this through Make’s HTTP module. The cost per classification is about $0.0003 per call with GPT-4o (150 tokens input, 50 tokens output). At ten thousand messages a month that’s roughly three dollars — cheap enough to ignore.
What most guides skip is the confidence threshold. They treat any output as gospel, which leads to the bot trying to process a refund request as an order status query and breaking downstream steps.
Now let’s talk about the tools we actually love and hate.
