Customer service agents need knowledge, not scripts

A classic support chatbot works off a decision tree: if the request matches category A, answer A follows. If it matches no stored category, it gets routed to a human. That works for the same simple cases every time and reliably fails on anything that deviates slightly from the norm, which is a large share of what actually reaches support in the first place.

An agent built on a language model works differently. It reads the request, searches the sources actually relevant to it (product data, order history, internal policies, prior comparable cases) and drafts a reply or takes an action: issuing a refund, rescheduling an appointment, canceling an order. The decisive difference isn't better language. It's access to real, current data instead of a fixed list of pre-written answers. A chatbot can only repeat what someone wrote into it beforehand. An agent can go look.

The language model itself has become commodity by now. The leading providers sit close together in quality for support use cases, and the difference between them rarely decides whether a customer ends up satisfied. What decides it is what the agent is allowed to see: the full order history instead of an excerpt, the current return policy instead of an outdated PDF version, the actual contract status instead of an assumption.

Companies that invest first in the most expensive available language model and only afterward in data access are buying the wrong priority. A cheaper model with full, current data access beats an expensive model without that access in practically every case.

That also holds for switching between model providers. If the actual work sits in the clean connection to order systems, CRM and knowledge base, the underlying language model can be swapped out later without rebuilding the whole solution. Build the architecture this way and you're not locked into a single vendor.

Most support organizations underestimate how much of their actual knowledge is documented nowhere. It sits in the heads of experienced staff who've known the edge cases for years but never wrote down how they're decided. At the same time, multiple contradictory versions of the same policy often exist in different repositories, because nobody removed the old version when the new one appeared.

Closing these gaps before launching an agent isn't a bureaucratic warm-up exercise. It's the actual work. An agent drawing on an outdated or contradictory knowledge base produces confidently wrong answers, faster and at greater scale than any single employee ever could.

In practice, a deliberate intermediate step pays off: walk through the relevant documents for the planned first category together with your most experienced support staff before the agent ever goes live, even once. These sessions rarely take longer than a few days, but reliably surface the contradictions and gaps that would otherwise only become visible through wrong answers reaching customers.

The instinct to point the agent first at the hardest, most expensive request category is understandable. That's where the biggest lever seems to be. In practice that's the wrong starting point. Difficult categories usually also have the most incomplete documentation and the most exceptions. The agent fails early, trust on the team drops, and the rollout as a whole gets a bad reputation.

The better starting point is a category with high volume and good documentation: order status, return conditions, simple contract changes. There you can show quickly that the agent works reliably. That early, visible reliability is the foundation for gradually expanding scope to more complex cases.

The expansion itself should follow the same pattern as the start: one more category, not all remaining ones at once. Every new category brings its own exceptions and its own documentation gaps. Add several categories at once and you lose track of which change caused which effect when quality suddenly drops in one of them.

A production customer service agent needs clear escalation rules: at what level of model uncertainty, on which topics, and above what order value a human decides. Defining these rules is a job for the most experienced people on the team, not IT, because they know the edge cases that never made it into the handbook.

That also shifts the role of the support team. Less time on the same standard requests, more time maintaining the knowledge base, reviewing escalations, and handling the more complex cases that genuinely need human judgment. This is rarely an overnight reduction in team size. It's a shift of the work toward what actually needs a human.

This shift needs leadership, not just technology. Employees who've been evaluated for years on tickets handled need an equally clear new definition of what good work is measured by now. Leave that question unanswered and uncertainty builds that slows the whole rollout, regardless of how well the agent works technically. Communicate that new definition early and openly, and you remove most of the internal resistance before it even forms.

Self-resolution rate alone is a weak metric. It rises even when the agent fobs customers off with incomplete answers who then contact support again. More telling are first-contact resolution across both channels, cost per contact, and the change in customer satisfaction for the categories the agent is active in.

If you tie personnel decisions to the agent, do it only after these metrics have held steady over a solid stretch of time, not based on the first promising weeks after launch. The first weeks mainly show whether the agent works at all, not whether it keeps working through seasonal peaks or unusual requests.

An agent accessing order and contract data is usually processing personal data under the GDPR. Without that access the agent stays useless, but that argues for building in logging from the start, not for withholding the access: what data was retrieved, what decision was made, who can audit it afterward. Adding that logging later is considerably more work than designing it in from the beginning.

That same logging pays off twice: it satisfies the documentation duty toward data protection officers, and it supplies the data needed to understand why the agent got a specific case wrong. Without it, every root-cause analysis stays a guess.

A common pattern in quickly rolled-out solutions is the agent that classifies requests but barely resolves any of them itself, an elaborately built router rather than a resolver. It looks impressive in a demo but barely relieves the team's day-to-day load, because the actual work still sits with humans.

An agent's value lies in resolution, not classification. A useful check before any rollout: how many requests leave the agent with a completed action, not just a handoff?

This pattern usually comes from caution: give an agent no authority to act, and it can't trigger a wrong action either. That's an understandable first stage, but not one a company should stay in permanently. The right response to that caution is tightly bounding what the agent can do and backing it with escalation rules until trust has built up more broadly, rather than withholding all action rights. An agent allowed to issue a refund up to a set amount on its own and escalate above it is a good middle step between a pure router and full autonomy.