How to Build an AI Customer Support Agent (Step by Step)

The short answer

An AI customer support agent reads a ticket, retrieves the matching sections of your help docs, and drafts a reply that cites those sections. A person reviews the draft before it goes out. Refunds, legal questions, cancellations, and answers the agent is not confident about go to a human with a reason attached. The steps below are the whole design. An AI customer support agent template is that same design with the wiring already done.

What the agent does on each ticket

One ticket in, one reviewable result out. Two statuses are enough: ready for review, and needs a human. The second status always carries a reason, so the person who picks it up knows why.

• Who sent it, the subject, and the body
• The help-doc sections the draft actually used
• A reply in your tone, saved as a draft or an internal note
• A confidence score and the escalation reasons
• A status a teammate can filter on

Architecture

Five stages, in order. Each stage should be able to stop the ticket. Retrieval can refuse to draft. The citation check can refuse a fluent answer. The escalation rules can override the model.

• Ticket intake accepts the sender, subject, and body, and skips a ticket you have already drafted. Start without the full customer history. Add it only when drafts are wrong without it.
• Knowledge-base retrieval splits your docs into sections, searches them, and puts only the matches in the prompt. An empty search skips the draft and escalates.
• Drafting is one model call. Ask for strict JSON: the reply, the section ids it used, a confidence score, and whether it thinks a human should take over. The instruction is to use only the retrieved text.
• Escalation runs after the model. Your rules override it on risky topics and on weak answers, and the handoff includes the draft, the sources, and the reasons.
• Guardrails drop any citation that was not in the retrieved set. A reply with no citation left is an escalation. A person approves the message before a customer sees it.

Step 1: Build a test set from tickets you already answered

Export a batch of real tickets to JSON, with the sender, subject, and body, and keep the reply a person actually sent next to each one. Run every prompt change against that batch before you connect a live inbox. Deduplicate on the ticket or thread id so the same message is not drafted twice.

Step 2: Write the docs as sections you can cite

Put the FAQ in Markdown. One topic per section: a heading in the customer's words, and the answer under it. The heading is what search matches and what the draft cites. A heading that says "Authentication" misses a ticket that says the reset link expired. "How do I reset my password?" matches it.

Step 3: Retrieve, then call the model once

Search the sections, keep the best matches, and send those with your company name, tone, and signature. Parse the JSON before you trust any field. Discard a citation that was not in the retrieved set. If none remain, mark the ticket for a human.

Skip a second call that only polishes the prose. That pass is where sentences from outside the docs show up. One grounded draft is the result you review.

Step 4: Escalate with rules you can read

Apply the rules after the JSON parses. Force a human for refunds, legal questions, and cancellations, whatever the confidence score says. Also force a human when the score is under the threshold you set, when retrieval was empty, or when no valid citation remains. Write the reason on the ticket.

Step 5: Store the draft, then connect the helpdesk

Save the reply, the cited sections, the confidence score, the reasons, and the status as a draft or an internal note. When the batch of old tickets looks right, accept live tickets on a small HTTP endpoint or a webhook. The helpdesk, or Gmail through an automation tool, posts the ticket and stores the JSON that comes back. The person who reviews the draft is the one who sends it.

Common pitfalls

These are the failures that show up once the demo looks fine and real tickets start arriving.

• Drafting when retrieval found nothing. That is where invented policy comes from.
• Pasting the whole help center into every prompt. The model mixes articles, and you pay for tokens the question did not need. Search first, and keep a pasted copy short.
• Treating the model's confidence as a measurement. Use it as a hint. The citation check and your keyword list are the controls.
• Sending automatically in the first week. A wrong promise on a refund costs more than a slow draft.
• No run that works without an API key. You need one so a bad prompt is obvious, separate from an API failure.
• Headings written for the help center, not for the way tickets are phrased, so search misses articles you already have.

Use an AI customer support agent template

The Customer Support Agent on ShipReadyAgents is this design. It answers tickets using only your help docs, cites the sections it used, scores its confidence, and routes refunds, legal questions, cancellations, and low-confidence answers to a human. You get a reply draft, the cited help-doc sections, a confidence score, escalation reasons, and a status of ready_for_review or needs_human. It drafts replies and never sends them. You review them in your helpdesk. Auto-send is deliberately not included.

It takes your FAQ or help docs as Markdown, tickets as JSON, a webhook, or helpdesk automation, and an LLM API key. Run the offline demo, then drop your docs into kb/. Set your company name, tone, and escalation keywords in policy.json. Add your LLM key and run it on a batch of real tickets. Connect the HTTP endpoint or the n8n webhook to your helpdesk.

It ships as an n8n workflow (webhook in, draft out) and as Python (standard library only, BM25 doc search, an HTTP endpoint, and an AGENTS.md file). The Python version searches your docs, so hundreds of articles are fine. The n8n version pastes docs into the prompt, so keep it under about 30,000 characters. It is told to use only your docs. Citations it invents are thrown out, and a reply that cites no doc section goes to a human instead. It posts back JSON you can save as a draft or an internal note, from anything that can call a webhook: Zendesk, Help Scout, Freshdesk, Intercom, or Gmail via Zapier, Make, or n8n. The cost note is an estimate, not yet measured: about $0.0005 per ticket on a small model (one call, ~2,000 tokens in). The script prints real token usage after each run. It is for small SaaS and e-commerce teams answering the same questions every day without a support hire.