Companies are cutting the people who run support before they’ve built the team that runs the AI.

If you run support, you’ve heard some version of the promise: put AI on the front line, take 20% of the volume off the queue, and cut 20% of the team to match. Sometimes it’s 30%. Sometimes it’s half. Or worse, it runs backward: we need to cut 20% of the team, so cut 20% of the tickets.

The problem is that this math treats a ticket as a unit of work. It isn’t. A password reset and a billing dispute both show up as one ticket, but one might take minutes while the other can take days and pull in three teams. Volume tells you how often customers reached out. It doesn’t tell you how much work it took to resolve what they asked.

That’s the missing step in the pitch. In most teams I’ve seen, nobody measures the work on either side: not the work AI removes from the queue, and not the work it creates. Headcount then gets reduced like-for-like with volume, as if every ticket that disappears frees up the same slice of someone’s day.

AI usually takes the easy share first: order status, password resets, questions with one right answer. How large that share is varies a lot. In B2B it’s often small, and many consumer companies already route their simplest contacts to self-service. What’s left for people is more likely to be the hard work: the exceptions, the customer who’s already angry, the issue that crosses three systems. In many teams, those easy contacts were also how new agents learned.

At the same time, AI creates work that never shows up in the volume number. Someone has to own what it knows, check what it says, and catch what it gets wrong.

Put those together and the numbers change. For a 50-person team, the ticket math says cut 10. The work math says 2 to 3 to start. Chapter 5 shows the math.

AI doesn’t run itself. After it goes live, someone has to be accountable for how it performs, what it knows, what it says, how it hands off, what it can’t handle, and what it actually saved.

These are responsibilities. They don’t mean seven new hires. On a small team, one person may hold three of them. What matters is that each one has a name next to it, and that it sits with people who already understand the product and the customer.

Run the AI like a product your customers use. A failure I see often is set-it-and-forget-it: it launches, the vendor dashboard looks fine, and nobody watches it closely until something breaks in public. A product needs an owner, live monitoring of real trends, escalation thresholds set in advance (a customer who asks twice, frustration in the conversation, a cancellation or billing dispute, a high-value account), and KPIs that support, product and finance all see.

Ownership splits between two teams. The central AI or platform team owns the models, retrieval, evaluations, guardrails, security and what the AI’s tools are allowed to do. Support and post-sales own the knowledge, the quality review, the escalation design and the work-based measures. Some decisions need both: support writes the test questions and the platform team runs them, support sets the escalation thresholds and the platform team builds them, and no model upgrade ships until it passes support’s test set. Neither team can run it alone.

And support is only where this starts. My bet is that AI tooling becomes the front door to the enterprise. In one conversation it can answer a question, nudge adoption, walk a customer through setup and flag a renewal risk. The lines between support, success, services and sales are blurring, and the AI runs on knowledge from all of them.

Adopting AI in support runs through five stages: decide, deploy, prove, staff and sustain. At each one there’s a default move and a better one. The default is easier in the moment, and it’s the move the pitch sells, which is why it’s so common.

If you’re already on the default path somewhere, you’re in good company. The paths don’t split once. Every stage is a fork, so you can switch at any of them. Switching just costs more the later you do it.

Start where you are. Find the first stage where you see the warning sign, and make that stage’s move before anything else. Later stages depend on it.

In its public jobs forecast, Forrester says AI “could account for 6% of total US job losses” by 2030, and that it “will augment 20% of jobs over the next five years.” If that’s even close, most of AI’s near-term return won’t come from the people it replaces. It will come from what the same people can do with it: resolve problems faster, cover hours and languages you could never staff, reach customers before they have to reach you, and turn every conversation into evidence for product and retention decisions.

That changes what to count: the work AI replaces and the work it augments, both measured in hours.

The vendor picks the scoreboard first, unless you do. Every number on the left can improve while the right gets worse.

Four measures cover both sides:

Old tickets give you a rough before. Only a baseline measured at launch gives you one you can defend. If you don’t have these numbers yet, don’t hold the rollout for them. Start measuring now. Every week AI runs without a baseline is a week of savings you cannot prove.

Cutting well

Some of the savings are real. The goal is a number that holds up. Cut in stages instead of all at once, and release each stage only when the measures hold: confirmed resolution steady, repeat contact and abandonment flat, escalations manageable. If they slip, pause that stage, not the program.

That’s a smaller first number. It’s also one you can defend at the next board meeting, and it leaves room to cut further when the evidence says you can. Putting dollars, payback and stage gates on your own numbers is what the Baseline does.

Many changes to an AI’s behavior after launch come from what it knows: a feature ships, a policy changes, a customer’s setup gets customized. Others come from prompts, tools, permissions and model upgrades, which the platform team owns. This chapter is about the knowledge.

Knowledge is no longer a help center. It’s spread across every system the AI is connected to, so every one of those systems becomes a quality gate. Some of them sync with each other, say Salesforce and Jira, or a CRM and a marketing platform like HubSpot or Klaviyo. When the same fact lives in two places, one of them has to be the source of truth, field by field, or the AI will find both versions.

A help center serves an answer someone wrote and reviewed. An LLM writes a new answer every time: it looks things up across databases and documents, infers what applies, and combines it into a response nobody has reviewed. Every source can be right and the answer still wrong.

None of the parts are new. Knowledge-Centered Service (KCS) gave support a way to capture and improve knowledge as it works. Data governance gave us source owners and a source of truth. LLM evaluation gave us test sets. What’s new is that the AI draws on all of these sources at once, so they need one lifecycle and one owner. I’m calling it the knowledge development lifecycle, or KDLC, and testing it in public.

When the loop catches an error, the first question is what kind it is:

The steward tracks every error to closure, including the ones the platform team fixes. And one customer’s data showing up in another customer’s answer isn’t a knowledge bug. It’s a security incident.

One owner runs the whole loop: a knowledge steward. Source owners own their data; the steward owns the standard, the loop and the scoreboard. The role can sit in support, operations or the platform team, as long as it spans every source.

The failure doesn’t show up on launch day. It shows up months later, after the people who could have caught it are gone: stale answers nobody owns, deflection that looks great while real resolution falls, the hardest work landing on fewer people, the reasons behind the rules walking out the door, and no path left from new hire to expert.

Some of the reversals are already public, and the analysts expect more.