Skill-Based Routing With AI Agents in Front: What Reaches Your Humans Now

Skill-based routing with AI agents in front changes what your routing is for: it no longer decides who answers the customer first, it decides which human gets the contacts the AI couldn’t finish. That sounds like a small shift. It’s not. It changes what every skill on your routing table means, and it’s the part of the AI conversation I see least discussed.

The numbers getting attention this autumn came from Salesforce. As Salesforce Ben reported in September, Marc Benioff said on the Logan Bartlett podcast that he had reduced support headcount from about 9,000 to about 5,000. He described AI agents handling around 1.5 million conversations, with a similar number handled by human agents over the same period, and said satisfaction scores were about the same for both. He called it a rebalance and said many people moved into other roles.

You can debate what that means for jobs, and plenty of people are. I want to look at a narrower question: if half your conversations are handled before a human sees them, what’s left for your routing to route?

What’s different about the contacts that reach a human now?

They’re the hard ones. That’s the obvious answer, and it’s true, but it hides three specific changes.

First, they’re longer. The quick, repeatable questions are the ones an AI agent handles well, so the contacts left over have fewer easy wins mixed in. Your average handle time will go up even if every agent is working exactly as before.

Second, they arrive with history. The customer has already explained the problem once, to a machine. If that conversation doesn’t travel with the contact, your agent starts from zero and the customer explains it twice. It’s one of the most common complaints about AI-first support, and it’s a routing problem, not an AI problem.

Third, they arrive annoyed more often. Some customers reach a human because the AI agent got it wrong, or went in circles, or couldn’t do the one thing they needed. The emotional starting point is different from a customer who rang in fresh.

What does each routing skill mean now?

When I wrote about skill-based routing earlier this year, I said it’s only as good as the data you route on, and that every extra skill has a cost in headcount. Both points get sharper with an AI agent in front.

Your old skills were usually built around topic: billing, technical, account changes, language. With an AI agent resolving the routine version of each topic, the human contacts inside each skill become a different mix. “Billing” used to mean a lot of “why is my bill higher?” and a few disputes. Now it may mean mostly disputes, exceptions and things the AI wasn’t allowed to do.

That suggests a different set of skills, built around why the AI handed over rather than what the topic was.

• Policy exceptions: the customer needs something the AI isn’t authorised to give.
• Failed resolution: the AI tried and the customer says it didn’t work.
• Complexity: the problem spans several systems or several earlier contacts.
• Emotion or risk: a complaint, a cancellation threat, a vulnerable customer.

Those four reasons need different people. An agent who’s brilliant at untangling a messy multi-system problem may not be the right person for a furious customer threatening to leave, and vice versa.

Where should the handover data come from?

From the AI conversation itself, and this is where most implementations fall short. A good handover passes the human three things: what the customer asked, what the AI tried, and why it stopped. If your routing engine can read the third item, it can route on it.

If it can’t, you’re back to routing on topic and hoping. Ask your vendor, specifically, what fields the AI agent writes on handover and whether your routing rules can use them. “It passes the transcript” isn’t the same answer. A transcript helps the agent once they’ve got the contact. It doesn’t help the router decide who should get it.

How should you route by emotion or risk?

Carefully, and with a human check. It’s possible to have the AI agent flag a conversation as angry, or a customer as at risk of leaving, and route on that flag. It’s useful when it’s right. When it’s wrong, a calm customer lands with your retention specialist and a furious one lands in the general queue.

So treat sentiment flags as a hint, not a rule, at least until you’ve checked them against real outcomes. Pull a sample each week: contacts flagged as high-risk and contacts that weren’t, and see which ones actually escalated, complained or cancelled. If the flag doesn’t predict those outcomes better than chance, don’t build your routing on it yet.

There’s one category where I’d route on any reasonable signal, even a noisy one: vulnerable customers. A bereavement, a financial hardship, a safety concern. Over-routing those to a skilled human costs you a few minutes of an experienced agent’s time. Under-routing them can cost far more, and it isn’t only a commercial cost.

What does the agent need on screen?

The AI conversation, summarised, at the top. Not the full transcript first, a three-line summary: what the customer wanted, what was tried, why it was handed over. Then the transcript below for anyone who needs the detail.

If agents have to scroll through a long exchange to work out what’s going on, they’ll ask the customer instead. That’s the repeat explanation customers hate most, and you’ve paid for an AI layer partly to avoid it.

What happens to first contact resolution?

It gets harder to read. I’ve written before about why first call resolution is one of the hardest metrics to get right, and an AI layer adds another complication: is a contact that the AI started and a human finished a first-contact resolution or not?

My view is that the customer decides. If they had to repeat themselves, or got passed along, it doesn’t count, however your system logs it. Measure FCR from the customer’s point of view across the whole journey, AI and human together, or you’ll get a number that improves while customers feel the opposite.

What does this do to staffing?

It makes forecasting harder before it makes it easier. Volume reaching humans drops, but handle time rises, and the mix by skill shifts in ways your historical data won’t predict. A plan built on last year’s averages will be wrong in both directions at once.

Start by forecasting the handover rate, not just total contacts. If the AI agent resolves half of your volume today, what happens when it’s updated next quarter, or when a new product launches and it doesn’t know the answers yet? The handover rate is the new driver of your human staffing, and it can move overnight when someone changes a setting.

That’s also why the internal promise matters. In my post on customer SLAs, the rule was don’t sell what nobody can back. With an AI layer, the customer-facing promise covers the whole journey, and the human queue has to be staffed to hit its share of that promise even when the handover rate jumps.

Who should take the handed-over contacts?

Your most experienced people, at least to start. It’s tempting to treat AI as the new first line and put junior agents behind it, because that’s how tiered support has always worked. But the contacts arriving now are the ones that used to go to second line. If you route them to your newest staff, you’ve effectively removed a tier and kept the most complex work at the bottom.

Over time, this changes how you build careers on the team. The entry-level job used to be learning on easy contacts. If those are gone, you need another way to build the same experience: shadowing, structured practice, or a deliberate share of simpler contacts held back for training. Otherwise, in two years, you’ll have experts and new starters and nobody in between.

What would I do this quarter?

Pull 50 handed-over contacts and read them. Tag each one by why the AI handed over. You’ll quickly see whether your current skills match the real reasons, or whether you’re routing a policy exception to someone who can only fix technical problems.

Then fix the handover data before you touch the routing rules. A routing table built on good handover reasons will beat a clever one built on topic guesses every time.

The AI decides what it can finish. Your routing decides whether the rest gets finished well.