Tenreply logoTenreply
← Back to Blog
AI

AI Agents for Customer Support: A Practical Deployment Guide

An AI agent that can look things up and take actions is a different operational problem from a chatbot that answers questions. What permissions to grant, how to handle escalation, and how to measure whether it is actually helping.

What Makes It an "Agent" Rather Than a Chatbot

A chatbot answers. An agent acts: it looks up an order, checks stock, reschedules an appointment, applies a tag, assigns a conversation, issues a credit. The moment automation can change state in your systems, the risk profile changes completely — a wrong answer is embarrassing, but a wrong action has to be undone.

This guide is about running one in a support operation without giving away control.

Start From Permissions, Not Capabilities

The instinct is to ask what the agent can do. The better first question is what it is allowed to do. Sort every action into three buckets:

  • Read freely. Order status, delivery estimates, stock levels, appointment availability, past conversation history, account tier. Reads are safe and are where most of the value is — an agent that knows the answer beats one that asks the customer to repeat it.
  • Write with limits. Booking or rescheduling within available slots, applying tags, updating a contact field, assigning a conversation, sending a documented policy. Bounded, reversible, low blast radius.
  • Never without a human. Refunds and credits, cancellations, discounts, price overrides, account deletion, anything touching payment details, and any commitment about a date or outcome you cannot guarantee.

Write this list down before you configure anything. Teams that skip it end up discovering the boundary through an incident.

The Escalation Design Is the Product

Most AI support deployments are judged on how well they hand off, not how much they handle. Get these right:

  • Escalate on repeated uncertainty. Two unsuccessful attempts at the same question means hand off. Never let a customer loop through the same fallback three times — that is the interaction people screenshot and post.
  • Escalate on emotion. Frustration, threats to leave, complaint language, all-caps, profanity. These are not automation opportunities.
  • Escalate on request, immediately. "Talk to a human" should work first time, without a gauntlet. Making it hard produces the exact resentment you were trying to avoid.
  • Escalate on money. Any refund, billing dispute or discount request, regardless of how confident the agent is.
  • Hand off with context. The agent should arrive with a summary of what the customer wants, what was tried, and what was already ruled out. A handoff that makes the customer start over is worse than no automation.

And handle the out-of-hours case honestly. If nobody is available, say when someone will be, and make sure that promise is real. "An agent will be with you shortly" at 2am is a lie your customer will remember.

Grounding: Where Answers Are Allowed to Come From

An agent should have exactly two sources of truth, and neither of them is the model's own knowledge:

  1. Your systems, for facts. Order state, stock, slots, account details — read live via API. Never inferred, never remembered from a previous conversation.
  2. Your documented policies, for rules. Returns, shipping, warranty, escalation paths — retrieved from the actual documents, with the instruction to answer only from them.

Anything outside both is an "I will check with a colleague", not a guess. This is worth being strict about, because the model's default behaviour when it does not know is to produce something plausible.

One practical consequence: your policy documentation becomes operational infrastructure. If your return policy exists only in a senior agent's head, the agent will invent one. Writing it down is part of the deployment.

The Rollout Sequence That Works

  1. Weeks 1–2: assist only. The agent drafts replies and thread summaries; humans send everything. You get speed immediately and a free audit of where it would have been wrong.
  2. Weeks 3–4: autonomous reads. Let it answer order-status and availability questions by querying your systems. Facts come from the database, so the risk is low and the volume relief is real.
  3. Weeks 5–6: autonomous documented answers. One category at a time — shipping, then returns, then product questions. Add the next only when the previous is unremarkable.
  4. Week 7+: bounded writes. Rescheduling, tagging, assignment. Still nothing touching money.

Two weeks per stage is not caution for its own sake — it is how long it takes for the unusual cases to show up in your logs.

Measurement: The Metric That Lies

Containment rate — the share of conversations closed without a human — is the number every vendor leads with, and on its own it is close to meaningless. A bot that stonewalls people until they give up scores beautifully. Always read it alongside:

  • Repeat contact within 24 hours. The cleanest signal that a "contained" conversation was not resolved.
  • Time to human after escalation. If this is bad, automation is just a queue with extra steps.
  • Satisfaction, split by AI-handled and agent-handled. If the AI cohort is materially worse, containment is costing you goodwill.
  • Agent edit rate on drafts. Heavy editing means weak grounding. Read the edits — they are the highest-signal feedback you will get.
  • Action reversal rate. How often a human undoes something the agent did. This should be near zero; if it is not, tighten permissions.
  • Opt-outs and complaints mentioning the bot.

Read twenty transcripts a week by hand. Every team that does this finds something their dashboard did not show.

Things That Reliably Go Wrong

  • Launching everywhere at once. The rollback costs more trust than the phased path costs time.
  • Letting the model infer facts. If it cannot see the order, it must not describe the order.
  • Hiding the human option to protect containment numbers. This converts a support interaction into a complaint.
  • No logging. When a customer disputes what they were told, you need the transcript and the retrieved sources.
  • Pretending it is a person. Name the assistant. Customers accept competent bots; they do not forgive being deceived.
  • Never revisiting it. Products change, policies change. An agent grounded in last quarter's documents is confidently out of date.

Frequently Asked Questions

How much support volume can an AI agent realistically handle?

For a typical e-commerce or services business, 40–60% of incoming volume is order status, hours, availability and documented policy questions — that is the realistic autonomous envelope. Claims above roughly 80% usually involve counting abandoned conversations as resolved.

Should the AI agent handle refunds if the policy is clear-cut?

Let it gather the information, check eligibility, and prepare the refund for one-click approval. Keep the approval human. The time saved is nearly the same, and the downside disappears.

What about multilingual support?

This is one of the strongest arguments for an agent — one grounded knowledge base serves many languages without maintaining parallel flows. Keep the same escalation rules per language, and make sure a human who speaks that language is reachable.

Do I need to tell customers they are talking to AI?

Yes, and it is increasingly a regulatory expectation as well as a trust one. Name the assistant and keep the human route visible.

Does this work across WhatsApp, Instagram and web chat?

Yes, and it should be one agent across all of them rather than three configurations. Tenreply runs the same inbox, automation and AI across WhatsApp, Instagram, Messenger and website chat — see the omnichannel playbook.

Grant Reads, Earn Writes

The safest high-value deployment is an agent that knows a great deal and changes very little: broad read access, narrow write access, fast escalation, thorough logging. Start with AI assist in Tenreply and expand permissions as your logs earn it.