Scaling Support Without Hiring
At WPML we handled around 5,000 support reports a month. I should say upfront that nothing was broken when this started - no backlog crisis, no burning platform. It was my own conviction that we could do considerably better, which made it a harder case to make than a rescue would have been.
It happened in two acts, and the order is the whole story.
Act one: the unglamorous groundwork
Before any AI, we built self-service, automatic collection of debug data at the point of reporting, and canned diagnostics for recurring cases. At the time that was just good operational hygiene. In hindsight it's what made everything afterwards possible: by the time we introduced an AI agent, our common problems were already documented, reports already arrived with structured data attached, and recurring cases already had defined resolution paths.
Most AI support projects fail here, in my view - not at the model, at the mess. They're pointed at an undocumented queue and asked to be magic.
Act two: the agent
I led the build and rollout of an orchestrated AI support agent, staged from 10% of incoming conversations to 100% over about six months. Four decisions mattered more than any prompt:
- A triage agent first. Every report was classified "AI Ready" or "Needs Human" before anything else touched it. Needs-Human went straight to a person - with the debug data already collected, so they could start working instead of starting a conversation. About 60% came back AI Ready.
- An escalation agent. Around 30% of the AI-Ready cases still ended with a human - but arriving with the full history of what had already been tried. An escalation that restarts the conversation from zero is a failure twice.
- A manual override. A new bug appears on a Tuesday, the agent doesn't know about it, and it will confidently keep getting it wrong. We built a way to inject sudden changes directly, the same day.
- A permanent evaluation loop. Every week, one of my most senior supporters and I read what the agent had actually said to customers and fed back where it failed. That loop never came off. It's the whole job.
What changed
Around 30% of total workload - the known issues and the documented how-tos - was absorbed entirely. Average resolution time went from roughly 24 hours to around 10 within a few weeks of full rollout.
The team got smaller, not bigger. The more interesting part is that it changed shape. Once the fast tickets were gone, what remained for humans was the ambiguous and the genuinely hard - so speed stopped being a fair measure of a supporter. Some of the least technical people moved to other departments and some left; the people we hired afterwards were more technical than the people we'd hired before. People were nervous during this, and I'd treat that as a normal cost of the change rather than something to manage around.
What I'd do differently
Two things.
I'd give the human team a copilot before putting the agent in front of customers - so people get used to working alongside it, and so you learn from real cases where the "AI Ready" line actually sits, instead of guessing and finding out in production.
And I'd roll out more slowly. We moved faster than I'd have chosen, and I didn't push back hard enough. The early hiccups were fixable technically, but much harder to fix in how customers and supporters felt about the agent. That perception took far longer to repair than the bugs did.
Scaling without hiring turned out to be less about the AI and more about what the AI inherits. Ours inherited two years of classification, documentation and structured data. Point one at a mess, and you'll scale the mess.