Pylon's founders at SaaStr AI Day: how its support team deflected 50% of tickets without increasing headcount. At SaaStr AI Day, Pylon's founders argued that customer support has pursued the wrong AI metrics, demonstrating why agentic AI augmentation outweighs pure automated deflection. Marty Kausas and Advith Chelikani on why deflection rate is the wrong number in 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. Machine Learning & Artificial Intelligence 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 * 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. Engineering & Technology 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. Beta customer results report 70% fewer escalations at one company and a 64.5% faster first response time at another, demonstrating the measurable value of human-in-the-loop agentic workflows.

Custify integrates with Pylon, Maxio, Groove to enhance customer visibility. Custify's new integrations with Pylon, Maxio, Groove, and Granola bring support, billing, and AI meeting data into its Customer 360 Profile, enabling CSMs to identify churn risks earlier. Custify, a customer success platform for SaaS companies, has announced four new native integrations with Pylon, Maxio, Groove, and Granola. These integrations are designed to provide customer success managers (CSMs) with a more comprehensive view of account health by bringing support tickets, billing data, revenue signals, and AI meeting notes directly into the Customer 360 Profile. The move addresses a critical need for SaaS companies: catching early warning signs of churn. According to Custify, support and billing issues are often the first indicators that a customer may be at risk. By integrating these data sources, CSMs can now see support ticket volume, billing status, and revenue changes alongside existing health scores and renewal dates, all in one place. Philipp Wolf, CEO of Custify, emphasized the importance of these signals. "Support and billing signals are some of the earliest warnings a CS team can get," he said. "With Pylon, Maxio and Groove, that signal now shows up precisely where CSMs are already working, as part of customer sentiment and health scores." The new integrations offer specific capabilities. The Pylon integration imports B2B support tickets from Slack, email, and in-app channels, allowing CSMs to review ticket volume and status next to health scores and renewal data. The Maxio integration syncs subscription, billing, and revenue data automatically, enabling CSMs to track MRR, ARR, invoices, and renewal dates, and to trigger playbooks on billing events such as payment failures or downgrades. The Groove integration imports email support tickets and contacts, rolling ticket counts up to the company level so CSMs can spot accounts with rising support activity. In addition, Custify added a Granola integration that enriches existing calendar meetings with AI-generated summaries and transcripts inside the Customer 360 Profile. This feature aims to give CSMs deeper context from customer interactions without manual note-taking. Custify, recognized as a leader in customer success software by G2, says these integrations help CSMs catch support and billing risk earlier, before it turns into churn. The company is headquartered in Bucharest, Romania, and serves B2B SaaS companies globally.