# Pylon: Zendesk Killer / Omnichannel Platform In the year 18 AZ (After Zendesk), Pylon keeps coming up in conversation with people of all functions - "Hey, have you heard of Pylon, could be worth checking out..." It hits close to home, thinking about the communication matrices we all navigate to connect a problem or a question to a data point to a resource to a dream. Everyone builds their own best-path through habit, be it their own or those shaped by the tools we use. My days often involve bridging gaps - translating a product difficulty that's first reported in Zendesk or ServiceNow or Splunk into an actionable Jira ticket, then explaining the fix or guidance back to support, sales, enablement, etc., or collaborating with product or engineering depending on the nature of the issue. I'll assess manually documenting in Confluence where there's lightning to capture for others... It works, but it's friction. So many handoffs, so much context lost between platforms through lossy membranes [[Thesis - Current tools are lossy membranes]]. Each tool is its own silo, its own little kingdom. Pylon seems to be committed to blowing up these kingdom with the offer of a single, unified platform where bi-directional, persistent channels (think gRPC) of communication are centralized and available, where context isn't dropped, where the conversation flows seamlessly into the build... and that feels potentially culture-redefining. * The core idea looks like pulling customer conversations from places like Slack, Teams,. Intercom, or Zendesk directly into a workspace where Engineering (using Jira, Linear, etc.) and Product can collaborate _without_ the endless copy-pasting and context switching. ## The pitch(es) 1. Signal vs. Noise - Targeting the data and triage problem, a primary engineering headahce. * *Turns chaotic B2B conversations into clean engineering signal; Focus on the work that innovates and energizes* * *Stop the firefight and turn support noise into the customer signals you need* * *The structed(ominichannel) layer for the unsructed(n-channel) chaos of B2B support* * Engineering Tax - Targeting the operational cost and inefficiency of n-channel support. * *Turn your engineering 'support tax' into your biggest product asset* * *Designed to get engineers out of the support queue and back to the roadmap* * *End the 'escalation tax' by giving support the context they need to be first-solvers* * Agent Framework - n-channel support fragments user context and teams misfire on broken or frayed signals. * *The omnichannel to connect user, support and engineering agents, free of noise* * *In one shared context finally answer, "What do my customers really care about?" * *The translation layer between a use's problem and the next opportunity/feature* * B2B Chaos - Targeting the mess of Slack and Teams, the industry "norm" * *Tame the chaos of slack to unlock engineers to build, not firefight* * *The first platform that treats B2B support as a systems problem, not a ticketing problem* This brings up a deeper point I spend a lot of time thinking about: how do you _structure_ all that consolidated data so AI agents can actually use it effectively? It's one thing to consolidate data and another to build a knowledge graph or mapping that lets an agent understand the link between a Slack complaint, a Jira ticket, and the specific GitHub commit that caused/fixed it. And you have to build that graph knowing the underlying AI models will radically change every 6 months. Flexibility for future agent capabilities feels paramount. * Also saw Pylon has an AI feature to generate knowledge base articles. I've kludged together versions of this before, trying to automate documentation from support threads, repeated pain-signals, and bug fixes. Seeing it integrated neatly is exciting. * The real challenge (one of them) is keeping that article _updated_ when related issues evolve, instead of spawning duplicate, slightly different articles every time. The goal should be to _simplify_ the knowledge base in order to magnify it's usefulness. **Simplify to magnify**. ## What is Pylon trying to blow up - **First Response Time (FRT):** How long does a customer wait (in a Slack channel or email) for a _first_ human acknowledgment? - Pylon's case studies capture a 90% reduction (e.g., from 35 minutes to 3.5 minutes) as a massive, tangible win that stops customer frustration before it starts. - **Time to Resolution (TTR):** The long-tail. How long from the first message until the problem is _actually_ solved? This is a measure of operational efficiency and agent enablement. - **AI Resolution Rate (or Ticket Deflection):** The new, but not really, critical AI-native metric. What percentage of incoming issues are resolved by the AI _without any human agent intervention_? - Pylon's case studies show this at **50-80% for L1 tickets**. This is the key to breaking the "linear scalability" problem. - **Engineer Escalation Rate:** I imagine this is on an engineering leader's mind. What percentage of "support" tickets end up requiring an engineer's time? The "support tax" quantified. - Pylon can and should get this number as close to zero as possible for anything that isn't a _true, novel bug_. - **Customer Satisfaction (CSAT):** The classic "how did we do?" score. - Pylon's thesis appears to be that faster, more accurate, AI-assisted resolutions will naturally drive this number up. Seeing walls like these knocked down in real-time feels exhilarating. Need to dig deeper. *(Side note: Noticed their intro videos default to 2x speed. Tells you something about their target audience's pace, maybe? Definitely prioritizing speed and efficiency. Fun touch.)*