Duck
Tutorials6 min read

Building an AI Customer Service System That Actually Works

Samet Turan— Editor··6 min read

Learn how to create a reliable AI customer service pipeline using no‑code tools, real prompts, and debugging steps — then decide if you want the ready‑made blueprint.

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

  1. Create a Make scenario that triggers on a new webhook payload from your chat widget.
  2. 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.
  3. Parse the JSON output. If confidence is below 0.7, route the ticket to a human queue.
  4. 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.).
  5. Log the original message, detected intent, confidence, and final action to a Google Sheet for later review.
  6. 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.

Concrete love: Airtable’s built‑in automation

I love how Airtable’s automation can watch a view for new records and fire a webhook to Slack when a ticket is marked urgent. It requires zero code, runs reliably, and gives us a visible audit trail. The free tier offers enough runs for a solo operator testing the flow.

Concrete gripe: Make’s operation limits on the free plan

The free tier of Make only allows 1000 operations a month. During our first stress test we hit that limit after two days because each classification used two operations (HTTP request + JSON parse). The sudden halt forced us to upgrade to the $29/mo plan, which bumps the limit to 10k operations — still tight but workable.

— and good luck finding docs for this — the Make knowledge base hides the operation‑count details behind a FAQ that’s easy to miss.

How to debug when this breaks

When the bot starts giving weird answers, first check the logs in your Google Sheet. Look for three patterns: low confidence scores, missing intent tags, or empty retrieval results from the vector store.

If confidence is low, tighten the prompt. Add a few shot examples that show the model exactly what JSON shape you expect. If the vector store returns nothing, verify that your source documents are actually indexed — sometimes the upload script skips files with special characters in the name.

If the hand‑off to a human never fires, confirm that the webhook from Make to your ticketing system is receiving a 200 response. A silent 500 will make the scenario appear finished while the ticket sits in limbo.

Finally, run a weekly sanity check: send five known‑phrases through the system and verify the intent and confidence match expectations. Any drift beyond ten percent triggers a prompt review.

Pricing opinion and tool love/hate

I think $29/mo for Make’s basic plan is fair for the automation power it gives you, especially when you compare it to Zapier’s $49/mo for a similar operation count. The free plan is a joke for anything beyond trivial testing — you’ll hit the wall fast.

On the other hand, I’ve found that OpenAI’s pricing is surprisingly reasonable at current levels. Even with GPT-4o the per‑message cost stays under a cent, which means you can scale to thousands of interactions without breaking the bank. If the price ever jumps above $0.01 per call I’d re‑evaluate, but for now it’s a solid bargain.

If you want the deep cut on this, deeper coverage of AI agent platforms.

All told, the stack we’ve built — Make for orchestration, OpenAI for language, Airtable for logging and simple CRM, and a Pinecone vector store for policy retrieval — runs under fifty dollars a month for a solo operator handling a few thousand chats a month. If you’d rather skip the build and deploy a working version in an afternoon, we’ve packaged this workflow as a blueprint at deepusecase.com/vault.

— The Colophon

One AI tool. Tested. Reviewed.
In your inbox every Sunday.

~3 minute read. Real outcomes from operators, not marketers.

Free. One email per Sunday. Unsubscribe in one click.