*Assumptions:* 1. B2B support is uniquely broken; support seeps beyond tickets into the chaos of shared slack channels, emails, Jira boards; context fragmentation occurs every step of the way. 2. Paradigm-shifting tools are successfully marketed to startups. Build momentum and capture headwinds for expanding product offerings, creating product lift. 1. Create enough lift in the face of headwinds to disrupt mature, embedded tooling. # 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]].