# 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. # Roll-Up The operational inefficiencies captured below; What is Pylon selling against? * **High-Cost & Low Scalability:*** Support costs (headcount) grows linearly with the customer base which an org can't hire it's way out of. High agent burnout and churn mean high training, hiring, and recontextualizing costs. * **Engineering "Support Tax":** Significant percentage of most expensive engineering cycles are spent reactively on support cases, context-switching, answering internal questions (extended back and forth) instead of *proactively* building the roadmap. * **Customer Churn & Revenue Risk:** Slow first-response times (FRT) and time-to-resolution(TTR) are basically death by a thousand cuts. Think, an innovator one day is catching up the next. * Pylon highlights case studies with 90% decreases in FRT as a core health metric. * **Customer Feedback "Black Box":** Support tickets (n-channel - Slack, email, Teams, Jira) are a massive, unstructured "black box" of data. Business is flying blind, unable to quantify or even see what bugs are actually high-impact or what features users really need (without a whole lot of instrumentation, i.e. my taxonomy efforts). ## The User Agent problems Value is the goal, the reality/norm is a blocker. 1. User agents have solvable problems with an existing solution 1. Discoverability: User agents cannot find the existing solution - buried in docs, in old slack threads, gated behind a support agent. 2. Applicability: User agents cannot apply an existing solution - unclear docs, too technical, versioning upkeep, tribal knowledge. 2. User agents have solvable problems without an existing solution; a new solution must be created 1. Engineering Dependency: User agents are blocked by a bug, data issue, or integration failure that requires eng. 2. Product Dependency: User agents are blocked by a feature gap or limitation that requires product decision and roadmap prio. ## The Support Agent problems Squeezed from both sides - user urgency & engineering bandwidth 1. Support agents don't always know the correct solution 2. Support agents can't always find the correct, existing solution 3. Support agents solve the same problem repeatedly 4. Support agents are taxed by context-switching 5. Support agents may not interpret the user's problem correctly 6. Support agents struggle to triage and route issues (efficiently) 7. Support agents are taxed by reproducing user issues 8. Support agents don't ask the right question(s) to establish necessary user context 9. Support agents need to document solutions in an external, customer-friendly way (internal/external boundary) 10. Support agents have solutions to user problems the user is dissatisfied with 11. Support agents receive user dissatisfaction despite solving an issue 12. Support agents are provided partial or inadequate data user data ## The Engineering Agent problems Building the future, taxed by the present. 1. Engineering agents are blocked by escalations that lack reproducible context, logs, or user impact to act. 2. Engineering agents lack quantified data (frequency, revenue impact, ARR) to prioritize bugs against feature 3. Engineering agents are taxed by constant back-and-forth with support just to understand the core problem, delaying the fix. 4. Engineering agents are pulled from the roadmap to act as "support for support", answering internal questions and fighting fires 5. Engineering agents are taxed by by reminders for updates to support agents for bugs and fixes ## The Business Agent problems Responsible for growth, flying blind with outdated formulas, linear costs. 1. Business agents are paying a high "engineering support tax", burning expensive resources on reactive, non-roadmap work 2. Business agents can't scale support org; headcount costs grow linearly with customer base 3. Business agents risk customer churn due to slow FRT and TTR 4. Business agents are flying blind, unable to see or access the "black box" of chaotic customer feedback and signals to identify high-impact bugs or strategic features 5. Business agents suffer from high agent burnout and churn, creating a high-cost cycle of hiring, training and recontextualizing (lost tribal knowledge) ### Consideration: The "Outdated" Business Agent Formula: How is a "Business Agent" assessing support cost? A linear formula, some variation of a Cost Per Ticket (CPT). Explored further, [[Business Agent Support Cost Formula]].