{"slug": "scaling-support-without-hiring", "title": "Scaling Support Without Hiring", "summary": "WPML Support, the support team for the WPML WordPress plugin, scaled its operations without hiring by deploying an orchestrated AI support agent that now handles 100% of incoming conversations, absorbing about 30% of the total workload and cutting average resolution time from roughly 24 hours to around 10. The rollout, led by an unnamed team member, involved a triage agent classifying reports as AI Ready or Needs Human, an escalation agent, a manual override, and a permanent evaluation loop, with the team shrinking as less technical staff moved on.", "body_md": "# Scaling Support Without Hiring\n\nAt WPML Support, we handled around 5,000 support reports a month. Nothing was really broken when this started. There was no huge backlog or crisis that forced us to act. I just believed we could do considerably better, which actually made the case harder to make than it would have been during a crisis.\n\nThe work happened in two stages, and the order mattered.\n\n## Act one: the unglamorous groundwork\n\nBefore we introduced any AI, we worked on the basics: better self-service, automatic collection of debug data when a customer reported a problem, and canned diagnostics for recurring issues.\n\nAt the time, this was just good support operations. Looking back, it was also what made the AI project possible. By the time we introduced an AI agent, our common problems were already documented, reports came with useful technical information attached, and recurring issues had clear ways of being solved.\n\nIn my experience, this is where a lot of AI support projects go wrong. Not because of the model, but because of the mess around it. You point AI at a queue that nobody has properly documented and expect it to somehow figure everything out.\n\nIt usually doesn't.\n\n## Act two: the agent\n\nI was heavily involved in the rollout of an orchestrated AI support agent, taking it from 10% of incoming conversations to 100% over about six months. Four decisions ended up mattering much more than any prompt we wrote.\n\n**A triage agent first.** Every report was classified as either “AI Ready” or “Needs Human” before anything else happened. Needs-Human cases went straight to a supporter, with the debug data already collected, so they could start solving the problem instead of spending the first few messages collecting information. Around 60% of reports were classified as AI Ready in the first months.**An escalation agent.** Around 30% of the AI Ready cases still ended up with a human. The difference was that the human got the full history of what the AI had already tried. If an escalation means starting the conversation all over again, you've basically failed twice.**A manual override.** A new bug appears on Tuesday, the agent doesn't know about it, and it can confidently give the wrong answer all day. I asked for a way to push new information directly into the system when something like that happened, rather than waiting for the normal update cycle.**A permanent evaluation loop.** Every week, for the first weeks, I went through what the agent had actually told customers and looked for where it had gone wrong. We kept feeding those findings back into the system. That loop never really went away. In fact, I think it's the most important part of the whole thing. And as far as I know it's still going on.\n\n## What changed\n\nAround 30% of the total workload - mostly known issues and documented how-tos - was absorbed completely by the agent in the first few weeks. After the full rollout, average resolution time fell from roughly 24 hours to around 10.\n\nThe team got smaller, not bigger. Some of the less technical people moved to other departments and some left. But the more interesting change was in what was left for the supporters.\n\nOnce the easy and predictable tickets were gone, supporters were dealing with the ambiguous cases and the genuinely difficult problems. That meant speed is no longer a particularly fair way to judge someone's performance.\n\nThere was obviously some nervousness around this. I don't think that's something you can completely manage away. When you change someone's job quite dramatically, they're going to have feelings about it.\n\n## What I'd do differently\n\nTwo things.\n\nFirst, I'd give the human team a copilot before putting the agent in front of customers. It would give people time to get used to working with AI, and, it would let you learn from real cases where the “AI Ready” line should actually sit. We were making some of those decisions while already in production.\n\nSecond, I'd roll things out more slowly. We moved faster than I would have chosen, and I didn't push back hard enough on that.\n\nThe early problems were mostly fixable from a technical point of view. The harder part was how customers and supporters felt about the agent. Once people lose confidence in a system, fixing the underlying bug doesn't automatically fix that confidence. That took much longer.\n\nIn the end, scaling support without hiring turned out to be less about the AI itself and more about what you give the AI to work with.\n\nOurs inherited years of classification, documentation and structured data.\n\nIf you point AI at a mess, you're probably just going to scale the mess.", "url": "https://wpnews.pro/news/scaling-support-without-hiring", "canonical_source": "https://amitkvint.com/writing/scaling-support-without-hiring/", "published_at": "2026-08-12 00:00:00+00:00", "updated_at": "2026-09-02 08:24:04.599224+00:00", "lang": "en", "topics": ["ai-agents", "ai-products", "ai-tools"], "entities": ["WPML Support", "WPML"], "alternates": {"html": "https://wpnews.pro/news/scaling-support-without-hiring", "markdown": "https://wpnews.pro/news/scaling-support-without-hiring.md", "text": "https://wpnews.pro/news/scaling-support-without-hiring.txt", "jsonld": "https://wpnews.pro/news/scaling-support-without-hiring.jsonld"}}