AI Agents for Customer Support and Contact Centres

The compliance surface a support agent actually sits on

A support agent touches regulated data on nearly every contact, and the rules are not abstract. If a customer reads a card number to complete a payment, PCI DSS 4.0 applies, and since the March 2025 future-dated requirements took effect, disk-level encryption of a call recording no longer counts as protecting the PAN. The agent has to pause recording and transcription around card capture, or route payment to a compliant flow, so the number never lands in a transcript, a log, or a training set. We design the pipeline so sensitive spans are detected and redacted at the boundary, before anything is stored or sent to a model.

Recording and disclosure obligations follow the customer, not your agent. Two-party consent states require every participant to be informed, and AI disclosure laws in California, Utah, and Texas require the customer to be told they are speaking with an automated system. For outbound and follow-up contact, the TCPA one-to-one consent rule and the ten-business-day revocation window that took effect in 2025 govern what the agent may initiate and when it must stop. For any operation serving EU customers, GDPR governs the transcripts, the profiling, and the retention. We build these as enforced controls in the agent's decision path, disclosure on first turn, consent state checked before recording, revocation honoured across channels, not as policy text in a runbook that a model is trusted to remember.

Why this is a RAG and agent problem, not a fine-tuning problem

The instinct to fine-tune a model on past tickets is the most common and most expensive mistake in this domain. Your policies, prices, entitlements, and shipping timelines change weekly, and a fine-tuned model bakes yesterday's answer into weights that cost real money and time to retrain. A model tuned on last quarter's return window will confidently quote it after you change it, and you will not know until a customer does. Support answers must be retrieved from a live, versioned knowledge base at query time, not memorised. That is a retrieval-augmented generation problem, and getting retrieval right, chunking help articles by intent, keeping the index in sync with your CMS, ranking so the current policy beats the archived one, is where most of the accuracy lives.

The second half is agency. Answering is not resolving. To close a ticket, the agent has to take actions against your systems: issue the refund in the order platform, reset the account in your identity provider, update the address in the CRM, create and route the ticket. That is agent development: tool definitions with typed inputs, permission scopes so the agent can refund up to a threshold but not beyond, and deterministic guardrails around every state-changing call. Fine-tuning has a narrow, honest role here, tightening tone to your brand voice or improving intent classification on your specific ticket taxonomy, and we use it there, evaluated against a held-out set, rather than as the load-bearing answer engine it should never be.

Concrete use cases and honest outcome ranges

Tier-1 deflection is where the volume lives. Well-scoped, high-frequency intents, order and delivery status, password and account resets, refund and return requests, plan and address changes, are where autonomous resolution is realistic. Published enterprise benchmarks put median tier-1 deflection in the range of roughly 35 to 45 percent, with top-quartile programmes near 55 to 60 percent, and narrow transactional intents like password reset often clearing 65 to 75 percent. Nuanced complaints and edge cases rarely break 25 percent, and we say so up front rather than promising a blended number that only holds in a slide. A defensible target for a focused rollout is 45 to 60 percent deflection on the intents you choose to automate, not on all traffic.

The second lever is agent assist on the contacts that stay human. When the agent drafts responses, surfaces the relevant policy, and summarises the interaction, published figures show handle-time reductions in the range of roughly 15 to 40 percent depending on channel and how much of the workflow is inside the assist surface. The compounding effect matters more than either number alone: deflecting the repetitive contacts raises the average complexity of what reaches a human, which is exactly the work people are good at, while assist keeps handle time on that harder mix from climbing. We scope every engagement to the specific intents and channels where these ranges are earned, and we instrument both so the actual numbers replace the estimates within weeks of go-live.

What it connects to, and the pipeline that keeps it honest

A support agent is only as good as its integrations, and this is where end-to-end ownership pays off. The agent connects to your ticketing and CRM system, Zendesk, Salesforce Service Cloud, Intercom, Freshdesk, or ServiceNow, for context, history, and case creation. It connects to your CCaaS and telephony layer, Genesys, Amazon Connect, Twilio, or NICE, for voice and IVR, where latency is a hard constraint because a customer will not wait through dead air. It connects to your order, billing, and identity systems for the actions that actually resolve a contact. We treat latency as a first-class engineering target across this path, streaming responses and caching retrieval so voice interactions stay conversational rather than stilted.

The data pipeline runs continuously, not once. Knowledge base articles, macros, and policy docs are ingested, chunked, embedded, and re-indexed on change so the agent's answers track your current policy the day it changes. Transcripts flow into a redacted, permissioned store for evaluation. The eval loop is the part that separates a system we will stand behind from a demo: a maintained set of real support scenarios with graded expected outcomes, run on every prompt change, model swap, and knowledge update, so a regression in refund handling is caught before deployment, not by a customer. Cost is metered per intent and reported transparently, so you can see the unit economics of each automated contact type and decide what is worth automating next.

Failure modes, guardrails, and human oversight

The dangerous failure in support is not the agent saying it does not know. It is the agent confidently inventing an entitlement, a refund the customer is not owed, a policy that does not exist, a delivery date it cannot guarantee. We control this at the source: answers are constrained to retrieved, cited knowledge, and the agent is built to say it cannot confirm something rather than to fill the gap. Every state-changing action, refunds, credits, account changes, runs through permission thresholds and, above a configurable value, a human approval step. Honesty and escalation are engineered behaviours with test coverage, not personality traits we hope the model exhibits.

Escalation is a designed handoff, not a dead end. The agent hands off on explicit request, on detected frustration or vulnerability, on any interaction touching a compliance boundary, and on its own uncertainty, and it hands off with the full transcript and context so the customer never repeats themselves. Governance sits over all of it: role-based access to the tools the agent can call, audit logs of every action and every escalation, human review of sampled conversations, and the same evaluation harness gating every change. This is where our security and compliance posture, GDPR alignment and SOC 2 practices, stops being a checkbox and becomes the operating model. The goal is not an agent that never fails. It is an agent whose failures are visible, bounded, logged, and caught by evaluation before they reach a customer.

Common questions

How is this different from the AI features already built into our helpdesk?

Native helpdesk AI is optimised to answer inside one vendor's product, and it stops at the edge of that product. It can suggest an article; it usually cannot issue the refund in your order platform, reset the account in your identity provider, or honour a TCPA consent revocation across channels. We build an agent that resolves contacts end to end across your CRM, telephony, and systems of record, grounded in a live knowledge index rather than a static FAQ, with an evaluation harness and audit logging that helpdesk features do not expose. If a native feature genuinely covers an intent, we will tell you rather than rebuild it.

What deflection rate should we actually expect, and how soon?

Honestly, it depends entirely on which intents you automate, so we refuse to quote one blended number. Narrow transactional intents like password reset and order status can clear 65 to 75 percent; a focused rollout across well-scoped tier-1 intents defensibly targets 45 to 60 percent on that traffic; complex complaints stay largely human. We scope the first phase to a small set of high-volume intents, instrument the real numbers from day one, and let measured performance replace the estimate within the first few weeks rather than asking you to trust a projection.

How do we stop the agent from giving customers wrong policy or promising refunds they are not owed?

Three layers. First, answers are constrained to retrieved, cited knowledge from a versioned index that re-syncs when your policies change, so the agent quotes the current return window, not a retired one. Second, every state-changing action runs through typed tool definitions with permission thresholds, and anything above a configured value requires human approval. Third, a maintained evaluation set of real scenarios runs on every change, so a regression in refund or entitlement handling is caught in the pipeline before it reaches a customer, not after.