**Regarding the use of "agent":** Agents are useful for understanding systems; Personas are for understanding people. More, [[Thesis - Agents are for understanding systems; Personas are for understanding people]]. # Zendesk: A Case Study into the Ticketing Revolution This case study will comprise of a step into a time capsule to consider what the world that needed Zendesk looked like, a look at the world that we find ourselves in following the advent of Zendesk, the problems we created for ourselves with the entrenchment of these systems, and the challenges Zendesk may be facing innovating itself today. This is a high-level look at a hypothetical but typical software company, "Anto-NoVation", and its use of Zendesk evolving over the years, to the present day. 1. What problems did Zendesk solve? 2. What is the world that Zendesk created and what systems did we wind up with as a result? 3. What problems did those systems create? 4. What challenges does Zendesk face innovating on themselves? ## The world that needed Zendesk Let's take a step into a time capsule. The year is 2008 and Anto-NoVation, a fresh-on-the-scene startup with a hip new app, Pagr. Pagr is a smash hit. It promises to turn Yellow pages into a social experience, sending a user an automated email if they pass within 50 feet of a "favorited" establishment or of someone who also has the app on their device and whose profile they've "favorited" out of the coveted "digitized Yellowpages". People are only really using it for the "digitized Yellowpages". Conversation around the app is constantly confused with reference to a physical pager. The database for the "digital Yellowpages" is 30% wrong, it's buggy, it drains the battery on a [Palm Treo 650]([Treo 650 - Wikipedia](https://en.wikipedia.org/wiki/Treo_650)) in 35 minutes. And it's already on 10,000 devices. The company's beating heart is a single shared email inbox: `[email protected]`. The inbox is a warzone. In an already multi-agentic 2008, there are four separate yet equally important personas: Jen (the Support persona), [email protected] (the User persona), Aleksandar (the Engineer persona), and Bozhidar (the Business persona/CEO). These are their stories. ### The Personas in 2008 #### The Support persona, Jen Jen lives in `[email protected]` Here's a glimpse into the challenges Jen faces. * At 9:01AM, Jen begins replying to an user email: "Pagr won't stop emailing me that I'm next to Tim's Pizza!" While she's typing, Jen's coworker has replied to the email from his Blackberry asking that the customer restarts their device. Jen doesn't know this when she replies. * *I want to know what is being worked on, so that I don't duplicate work and confuse the customer. * On her lunch, coffee, smoke breaks, she can feel the "Unread" count of that Outlook inbox rising ceaselessly. * *I want to know what I should be prioritizing, so that I am not blindly working towards an arbitrary goal.* * At 10:14AM, Jen sees an email come in that reads, "STALKER APP. CANCEL. REMOVE ME!!!" The user appears difficult and the problem is sure to be challenging. Someone else will answer it. Dave skips it, too. The email sits in the inbox for 53 hours, seen by everyone and owned by no one. * *I want to assign an email to an owner, so that I know important issues won't be ignored. * At 2:43PM, a new email arrives, "It's still broken..." Jen has no idea who this user is or what they're referring to. She spends a grinding 15 minutes searching the "Inbox"" and Sent" folder for the user's email address. * *I want to see all past conversations with a customer in one place, so that I can understand their history and context without needing to follow-up. #### The User Persona, [email protected] Sent a bug two days ago, they've heard nothing since. * [email protected] sent an email for a "stuck GPS" bug 2 days ago. With no reply, they've just followed up, "HELLOOOO??? IS ANYONE EVEN WORKING THERE???" * *I want to know the status of my problem, so that I am assured it hasn't been sent into a void; so that I know it's been received. #### The Engineering Persona, Aleksandar Aleksandar is one of a few engineers, hates email and prefers to be in "Bugzilla." * Jen confirms that [email protected]'s "stuck GPS" bug is real and forwards the 16-message-long email chain to Aleksandar with the subject: "FWD:FWD:FWD: URGENT!!! GPS bug" * *I want to have a clean problem summary, so that I can prioritize and address problems.* * Aleksandar reads through the convoluted, repeated angry customer reports, with unrelated logs. He can't reproduce the issue with what he has to go off of, and replies: "What OS? What device? When did this occur?" and closes the ticket. * *I want to understand the issue context, so that I can take effective action.* #### The Business Persona, CEO CEO walks through the office a few times a day and asks "How are we doing? What's the biggest fire?" * Jen looks at the 400 unread emails. "I... think the GPS one? Or maybe battery drain?" She has no data, only anecdotes. The CEO has no dashboard, no FRT, no CSAT. He is running a million-dollar company by "vibes" from the support inbox. * *I want to quantify my team's work and my product's problems, so that I can make data-driven decisions about where to invest resources."* ## The world that Zendesk created Anto-NoVation adopted Zendesk as its first support tool in 2009. Their support team now has a specialized, departmental function with a "fortress" or tool built for its unique workflows, separate from engineering (in Jira, Bugzilla) or sales (in Salesforce). As I shift into considering systems and their interfaces, I'll be referring to agents instead of the personas above. More, [[Thesis - Agents are for understanding systems; Personas are for understanding people]] - **The "Queue" is King:** Zendesk is the support agent's fortress and the center of the support cosmos. Emails, web forms, and chat messages are all ingested and transformed into a ticket, which is assigned to a support agent. - Assignment is automated, curated, manual, and most often a mix of the lot. An Anto-Novation, Queue-captains respond to queue alerts and ensure that unassigned tickets are assigned according to resource/agent availability. - **The World is a Workflow:** The support agent's life is defined by Zendesk's Triggers and Automations. The helpdesk handles how tickets are routed, prioritized, and tagged based on _support-defined_ logic (e.g., "If `form_field` is `billing`, assign to `Tier_1_Billing`"; if `customer_tier` is `top_99` trigger `break_glass_support` ). - The primary business value of a helpdesk is managerial oversight. The ability to track metrics (like FRT), enforce SLAs, and measure agent productivity is the key to scaling a support team. - **The Wall is Built:** Engineering and product agents are not citizens of this fortress. They are outsiders, distant but gravitationally dense planets, who are brought in via a very specific, high-friction process: escalation. A ticket is "sent" to Jira, which creates a new, partially-connected record in the engineering system. - The engineers at Anto-Novation pick up the escalation banana-phone, receive some context, ask a few follow-up questions, make a plan, receive new context, adjust the plan, check the time and discover the day is half over. ## The problems that world has left us with Zendesk's architecture, and the culture it reinforces is the definition of a silo. Context sharing is operationally painful - the engineering and product agents that exist beyond the walls receive fragmented glimpses at the user, and while Zendesk was certainly a revolution at it's inception, I ask myself, are these lossy membranes still useful to us? There are the before-Zendesk (BZ) companies, like Anto-NoVation, that experienced it's value firsthand, and those after-Zendesk (AZ) - **The "Jira Wall":** When a Support Agent escalates a ticket, context is immediately lost. The new Jira ticket contains only the summary the agent wrote. It loses the full, raw customer conversation, the sentiment, the other 10 tickets from that same user, and the account's ARR. The Engineering Agent is now working from a third-hand, filtered piece of information. - The "ticket" was/is the a necessary atomic unit for a support interaction. It transforms an intangible request into a structured, measurable, and assignable object of work; and tickets were not intended as reusable assets. - **The "Slack Black Hole":** B2B support actually happens in Slack. The customer, the account manager ("Business Agent"), and the support agent are all in a chaotic thread. Zendesk's answer to this is to _manually_ create a ticket from a Slack message. This "ticket-ization" fragments the conversation. The "real" conversation continues in Slack, while a fossilized copy lives in Zendesk, now instantly out of date. - The techno-archeologists at Anto-Novation have become good at reading the bones through their rich tribal knowledge. Unfortunately, when they move on to new dig sites and projects, new hands may put together a duck out of the fossils of a Toyota Prius. - **The "Support-Centric" Universe:** The Support Agent's primary metric is "Time to Resolution" (TTR) within Zendesk. The Engineering Agent's metric may be, let's say that it is at Anto-NoVation, "Sprint Velocity" within Jira. These tools do not speak the same language or share the same goals. An engineer closing a Jira ticket doesn't auto-update the customer. The support agent must manually poll Jira, get an update, "translate" it for the customer, and then close the Zendesk ticket. This is a high-friction, manual handoff at every step. ## The future with or without Zendesk Zendesk is a mature, embedded tool trying to bolt on AI, while new tools are built AI-first. It's worth stating that Zendesk successfully provided a needed solution to a real problem. That said, it's maturity creates two fundamental points of friction against it's prospect for AI/agentic relevancy: - **Problem 1: The "Bolt-On" Trap** Zendesk's AI is built to optimize the existing model, data structures, workflows. Its AI "agents" and "copilots" (as seen in their recent 2025 announcements) are designed to do two things: 1. Help the **Support Agent** write replies within the ticket. 2. Answer simple questions by reading the **Knowledge Base**. This is an AI cannonball aimed at being decoratively mounted onto the wall, not tearing it down or reconsidering it's architectural virtues. It doesn't solve the core problem that the knowledge isn't in the Knowledge Base. It's in Slack threads, in Jira tickets, and in Google Docs. Zendesk's AI, by default, is blind to the actual sources of truth in a modern B2B company and expects agents to onboard their documentation into Zendesk's stonework. * At Anto-Novation, the AI tack-on for smart ticket matching is effective less often than it's helpful, and it costs Support Agents time verifying if matched tickets are actually related. - **Problem 2: The Data Silo Paradox** Zendesk is trying to build AI on itself, but it only holds the "Support Agent's" slice of the pie. It doesn't have the Engineering Agent's data (Jira, code commits and comments) or the Business Agent's data (Salesforce, Slack). Zendesk's AI is trying to win a war using only the intelligence from one silo. An AI-first tool is a horizontal intelligence layer that sits _across_ all silos, creating a new, shared context for all agents. Zendesk can't do this without fundamentally re-architecting its entire "ticket-centric" worldview, which would alienate the very users who built their careers on it.