--- title: "How We Scaled Platform Support 10x Without Scaling the Team" date: "2026-08-20T04:15:00" url: "https://www.godaddy.com/resources/news/how-we-scaled-platform-support-10x-without-scaling-the-team" --- # How We Scaled Platform Support 10x Without Scaling the Team ## Introduction Five engineers. Over 500 production applications. A user base doubling every year. That was the reality our Katana platform team faced heading into 2025. Katana is our internal platform that enables engineering teams to build, deploy, and run their applications on AWS. We had built something engineers genuinely wanted to use, but our success was creating its own problems. By putting AI at the front of our support workflow, we automated over 80% of our support workload, turned our assistant into a feedback engine for continuous improvement, and freed our team to focus on the complex problems that actually need human expertise. ## The scaling problem Our support model was straightforward: engineers onboarding to Katana or running their apps on the platform would post questions in our Slack support channel, and someone from our team would help. We had emoji-based workflows that automatically created Jira tickets so we could track requests. It worked well at small scale. But the math was getting brutal. Most questions weren't platform bugs. They were AWS consultations, onboarding guidance, and configuration advice. The kind of tribal knowledge that lived in the heads of our most senior engineers. With five people supporting 500+ applications and adoption doubling annually, we were heading toward a model where the majority of our time would be spent answering questions rather than improving the product. We needed to scale support exponentially without scaling the team at the same rate. ## Exploring AI-powered support Around mid-2025, we started brainstorming. The core question was simple: what if AI could have the knowledge our most senior team member has and use it to help customers get answers faster? We didn't have a detailed blueprint. Our principal engineer started experimenting, and a working approach emerged faster than we expected. ## How we built it We built our AI assistant by feeding it rich context from multiple sources. It draws on selected Slack history, custom instructions we've written for common scenarios, and our company's internal documentation system (so anything published in our docs is automatically accessible). Critically, it also connects to our platform API to pull real-time information about specific applications, including logs and configuration details. This means even when the AI can't fully resolve an issue, the engineer handling the escalation gets a significant head start with relevant context already gathered. We already had workflows where adding an emoji to a support request created a Jira ticket, so we leveraged the same pattern for AI-based escalations. Then we made a bold move: we ran a two-week experiment where we disabled direct posting to our support channel entirely. The only way to get support was through the AI assistant. Were we nervous? Absolutely. Our own team was the greatest skeptics. "AI won't replace humans," "it won't interpret requests properly." We heard it all. But we wanted data, not opinions. Two weeks later we surveyed our users, and the results surprised even us: > This is so nice! I love the fact that when it's not sure of the response, it suggests to go to the Slack channel or to open a ticket. It does not seem to BS us, which some AI assistants seem to do. > > The last time I used the support bot, I was blown away with how capable it was. It sets a high standard for agentic integration throughout our developer tools. With no significant friction and strong positive feedback, we made the change permanent. ## What it delivered and how we run it Today our AI assistant handles over 80% of all support requests autonomously. Only one in five interactions requires a human engineer. One unexpected but welcome effect: with AI handling all the straightforward questions, the escalations that reach our team are now genuinely complex problems requiring real investigation. The easy questions are gone. What's left is harder, but it's more meaningful work. But the assistant isn't just a chatbot. It's also a feedback engine. By analyzing conversation metadata and sentiment across all interactions, we can identify recurring themes, spot areas where the AI struggles, and surface patterns that point to gaps in our platform or documentation. That analysis feeds directly into how we prioritize improvements, both to the assistant and to Katana itself. We treat the assistant as a product, not a side project. We run a weekly on-call rotation where one engineer focuses on improving the AI. If we spot bad guidance, we update it immediately. Whenever we ship new platform features, we ensure the assistant has the information to support our customers accurately. Every Monday, an automated report drops into our team channel showing request volumes, human escalation rates, and negative sentiment percentage so our PM can follow up with unhappy customers. We also learned early that you need a fallback plan. If the assistant goes down, customers ping a manager directly who routes requests to the support channel. We've only needed it twice in the past year, but when those moments came, our team knew exactly what to do. ## What's next We're far from done. We want to integrate with status pages so our assistant can check upstream services like GitHub and proactively inform customers about external outages instead of debugging them. We're exploring automated feedback loops for human-handled escalations and looking for non-intrusive ways to measure AI support quality without relying on surveys. Our biggest takeaway? Don't be afraid to experiment. Don't fear pushback. Don't get stuck in analysis paralysis. Be biased for action. Start with a proof of concept, get something working, collect feedback, and iterate. The perfect solution will reveal itself through experimentation, not planning.