# Pylon’s Founders at SaaStr AI Day: A 1,000-Person Support Team Deflected 50% of Its Tickets. Headcount Didn’t Change. > Source: > Published: 2026-08-11 10:40:34+00:00 **Marty Kausas and Advith Chelikani on why deflection rate is the wrong numberin CX. And what they’re replacing it with, and what you should, too.** Pylon closed out the latest SaaStr AI Day with the two co-founders walking through the launch they shipped the week before, which they’re calling agentic customer support. Marty Kausas is co-founder and CEO, Advith Chelikani is co-founder and CTO. The company is a little over three years old and around 1,600 customers, almost all B2B. Their argument is that support bought the wrong AI product for the last two years, and the deflection numbers everyone reports are hiding it. ### What the session covered: - Why a 50% deflection rate produced zero headcount change at a company with 1,000 support people - The case for human plus AI over full replacement, and why support ran the other direction - Two live examples of a ticket that arrives already investigated, including one that replaced a manual AWS log query - Beta results from customers: 70% fewer escalations at one, 64.5% faster first response at another ## 1. The test is whether the job is unrecognizable Kausas opened with an engineer who joined Pylon earlier this year after a two-year sabbatical. He left as a software engineer with no AI coding tools and came back into a job he described as unrecognizable. Before, you wrote the code, tested it, and reviewed it yourself. Now you’re managing agents doing that work. That’s the bar Kausas set for support. If a support person joins your company and the job feels like the job they left, nothing has actually changed. He also put up AI spend by department. Coding is the only bar that has meaningfully taken off. Every other function is still at the start. ## 2. The deflection number that didn’t move headcount Kausas’s argument is that the fastest-growing AI companies are running human plus AI augmentation rather than full replacement. He pointed at the model labs themselves, plus Cursor in coding and companies like Harvey in legal, and noted that he uses Claude and Codex daily and neither is close to automating him. Support went the other way. Almost everyone ran at full-resolution agents, which Pylon frames as solving a real but narrow slice of the problem, especially in B2B where tickets carry more context and more relationship. The example: a company of roughly 5,000 people with about 1,000 on the support team deployed a fully automated resolution agent. It deflects around 50% of tickets. Headcount didn’t change. The reason is that ticket count and work volume aren’t the same measurement. What an agent can fully resolve with no human in the loop is a limited set of questions, and those are the easy ones that consumed the least time to begin with. Deflecting 50% of tickets can remove a much smaller share of the actual work. Everything hard still escalates to a person. Pylon’s bet follows from that: automated resolution gets commoditized, and the value sits in helping humans do the escalated work faster. Worth noting this is a vendor drawing a line where their product sits, and the specific 50% example came from one customer conversation rather than a study. The underlying point is still testable in your own numbers. Compare your deflection rate against your support headcount and your median handle time over the same period. ## 3. Why DIY with Claude hits a wall Most teams already have people asking Claude for help answering tickets, connected to the help center, feature request logs, the support system, and the code base. Kausas’s position is that this gets you real but limited help. His example: one of the best ways to answer a new ticket is finding similar past tickets. A skill that has to read through every past ticket to do that is impractical every single time. Pylon’s answer is precomputing the context layer instead. Account setup, goals, use cases, interaction history, and sentiment are computed ahead of time, along with related tickets, related knowledge articles, and who the contacts are and what they care about. The claimed result versus rolling your own is three to six times cheaper inference, better quality, faster responses, and team control instead of a group of people trying to co-own one skill. ## 4. What a pre-investigated ticket looks like Chelikani demoed Pylon’s own support queue. A customer named Ryan asks for a fix to a filter in the analytics part of the product. On the right side, the background agent has already run. What it produced before a human touched the ticket: it interpreted the screenshots and identified the analytics area even though the customer never named it, found two similar past issues from other customers, surfaced a call from the previous week where this customer had been frustrated about the same thing, and checked the code to confirm the backend was implemented but not surfaced on the front end. It concluded this was a UI regression rather than a missing feature, and suggested next steps. Karen, the support engineer, then worked interactively. She asked whether an open feature request existed in Linear (it didn’t), pushed the agent deeper into the code base to confirm a suspicion, ran a skill that packaged the customer context and the investigation into a Linear issue tied to the ticket, then asked for a reply drafted in her tone of voice. She reviewed it and sent it. The division of labor is the point. The agent did the gathering, and the human kept the judgment call and the responsibility for the response. ## 5. The AWS log query that took a minute instead of twenty The second example was a customer asking when a specific team in their instance had been deleted. The manual version: log into AWS, open CloudWatch, look up the customer’s organization ID, write a SQL query against the logs, read the results, and figure out what happened. The agent had already done it, using IDs it already held for that customer plus the new one provided, and it knew where to look and what the query should be because it had solved this type of issue before. It returned the exact timestamps and drafted a response built on the audit trail from the logs. Owen on the support team sent it as written after confirming the results. The customer got a real answer in a minute or two instead of a note saying someone would look into it. ## 6. The agent learns from people doing their jobs Asked how much non-technical team members can shape the agent, Chelikani’s answer was that going back and forth with it is functionally writing down every step you took to solve the issue. Ask it to check whether a feature request exists, and it learns that in this class of ticket you check feature requests, and where you check them. The next similar ticket arrives with that already done. Same for knowing which Slack channel covers which project. That’s a different adoption model from most AI tooling. The people who can’t configure anything are still training the system by working in it. ## 7. Background agents and the Slack surface Auto-investigating every incoming ticket is the most common background agent, but teams set up others. Pylon’s own runs every time a feature request closes: it summarizes what shipped, checks whether it’s actually deployed, decides whether it resolves the customer’s original ask, and posts that into the AI thread on the relevant ticket. That closes a gap most support teams live with, where engineering ships the fix and nobody tells the person who took the complaint. The Slack surface carries the same knowledge as the app. In the demo, someone forwarded a customer question into a channel, tagged Pylon, and got an answer drawn from the code base, logs, past tickets, and prior customer interactions. Chelikani followed up by asking whether a knowledge base article should be updated to prevent the confusion. The agent found the relevant doc, drafted the update, and tagged him for review before publishing. ## 8. What beta customers are reporting Self-reported numbers from beta, so treat them as directional: - One customer saw 70% fewer escalations to engineering within about a month, because support could answer more without going to other teams or other tools - Another saw 64.5% faster time to first response - Several are serving a growing customer base without adding headcount - The Slack agent produced organizational leverage beyond support, with salespeople getting product answers and product and engineering pulling bug and feature request trends themselves The last one is the most durable. When one person on the team is the only one who can solve a certain class of technical problem, their process becomes a skill anyone can run. That raises the floor across the team and shortens onboarding. ## 9. What it’s doing to how teams get hired Two changes Kausas and Chelikani are seeing across customer interviews. Cost is becoming a real line item. Teams that built their own version and got to the bleeding edge early are now spending significant money on model calls to get the same workflow done. And team composition is shifting. Companies are hiring more junior and more technical support people, plus a dedicated builder persona whose job is constructing the system and feeding the agents so the rest of the team runs better. ## What to take from this if you’re evaluating support AI **Stop reporting deflection rate alone.** Pair it with headcount and handle time. If deflection went up 50% and neither of those moved, you automated the easy tickets.**Measure escalations, not just resolutions.** The 70% escalation reduction is the more interesting number here, because escalated work is where support cost actually lives.**Precomputed context is the real moat claim.** Anyone can connect a model to a help center. The question to ask any vendor is what gets computed before the ticket arrives versus at query time.**Watch your own model spend.** Teams that built this in-house are hitting cost as a constraint. If you’re rolling your own, price it against the ticket volume before you commit. Marty Kausas and Advith Chelikani are reachable on LinkedIn, or at founders@usepylon.com, which reaches all three co-founders.