From Tickets to Conversations
Chat isn't just support anymore! It's a control surface where users expect instant action, not ticket queues. Time to rethink what customers need. Read: "Everything Starts Out Looking Like a Toy" #290
Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.
This week’s toy: Agentic coding for iOS apps is increasing big time.
Edition 290 of this newsletter is here - it’s February 2, 2026.
Thanks for reading! Let me know if there’s a topic you’d like me to cover.
The Big Idea
A short long-form essay about data things
⚙️ From Tickets to Conversations
Most customer service communications systems aren’t explicitly broken. They’re still doing exactly what they were designed to do. But the way they are doing it is not longer what customers expect.
Take ticket help desks like Zendesk, Freshdesk, and JIRA Service Desk. These systems are a good example of “job well designed” because used well, they resolve issues correctly, enforce consistent rules, and scale predictably. For a long time, giving you a ticket ID and resolving your issue in a reasonable amsount of time was exactly the right thing to optimize for in a support situation.
The need for support didn’t change. What changed was the expectation to respond instantly.
When correctness stops being enough
The traditional help desk (ITIL) model assumes that work arrives as a declared request. A user identifies a problem, opens a ticket, enters a queue, and eventually receives a response. Fairness and order matter more than immediacy. Waiting is acceptable as long as the process feels legitimate.
That model still works! Tickets get resolved, and it’s possible to manage and adhere to service level agreements. (Yes, I know that lots of tickets still breach their commitments).
But now there is ChatGPT and Claude, so users expect an immediate acknowledgement and ideally an answer on the first response. Resolution might come later, but silence from the help team feels like failure, or at the very least “I don’t matter to you.”
Let’s acknowledge that in the world of GPTs, waiting feels unnecessary when the question is simple, contextual, or exploratory. Even when you need to go get some information to solve a question, you should at least be able to respond right now with what you know.
This is where organizations get stuck. The system is still right, but it’s no longer aligned.
The wrong explanation for chat usage
When chat volume increases, it’s tempting to explain it as user confusion. Customers don’t know what they want, and they’re bypassing the “proper” interface. That framing made sense when chat was slow, text-only, and disconnected from real action.
Jevons paradox suggests otherwise … when it’s easier and cheaper to communicate, people will do it more!
Modern chat can persist context, render UI, surface options, preview outcomes, and trigger workflows inline. Once conversations can stay stateful and take action without handoffs, chat stops being a fallback channel and becomes a legitimate interface.
Don’t forget another big shift that happened over the last few years. If you can’t interact with a company on your phone, that interaction might as well not exist. Once conversational interfaces became something you could access instantly, from anywhere, the acceptable delay collapsed. Users stopped thinking in terms of sessions and started thinking in terms of moments.
When you’re using your phone and have question, you don’t want to wait. Some of this is a UX slight of hand, because when you lack an immediate acknowledgement, it feels like friction.
Chat + mobile + always available network access means that every app with messaging needs to feel like a text conversation.
Chat as a dynamic control surface
By “control surface,” I don’t mean that chat should replace every interface. I mean a surface where intent can be clarified and action can be taken without forcing the user to leave context.
Here’s how it works.
A user asks a question. The system responds, but also offers two actions inline. One click resolves the issue. No ticket number. No queue. No escalation. The conversation continues.
That’s not just faster support. That’s control.
In a ticketing system, help and action are separate. You explain the problem, then wait for someone else to act.
In an inline chat model, those boundaries blur. The system can guide the user, suggest next steps, and sometimes complete the action directly. The chatbot isn’t replacing resolution. It’s replacing waiting.
Chat as a user-owned inbox
One way to understand this shift is to stop thinking about chat and tickets as different tools. They’re different ownership models for conversation.
Tickets are conversations optimized for organizational flow. Chat is a conversation optimized for user continuity.
Organizations initiate help desk tickets. They use internal structure like queues, priorities, and ownership to make work manageable. Basically, you’re adding the user to the organizations Inbox.
Chat flips that relationship. The user starts the conversation and stays in it. Routing, escalation, and logging can still happen, but they don’t need to be exposed as part of the experience.
Tickets didn’t disappear. They stopped needing to be visible.
Historically, visibility was how systems maintained control. Process transparency was how trust was earned. Systems were brittle enough that users had to participate in internal workflows.
Why exposing tickets now feels heavy
When ticket mechanics are exposed, users are forced to adapt to internal workflows. IDs, statuses, and queue positions interrupt flow. Process transparency becomes part of the experience whether the user wants it or not.
But most customers don’t want transparency for its own sake. They want acknowledgment, progress, and resolution.
If those can be delivered without exposing internal routing, hiding it becomes a feature, not a bug. This is why chat feels lighter even when the underlying system hasn’t changed.
Where resistance shows up
When organizations resist this shift, it’s rarely because chat doesn’t work. It’s because ticketing systems encode long-standing assumptions about boundaries.
Treating chat as just another intake mechanism preserves existing roles and separations. Letting chat guide or act challenges them.
So objections show up as principled arguments:
“Support shouldn’t do product.”
“That belongs in the UI.”
“Chat should just answer questions.”
These sound like architectural concerns. Often, they’re defenses of familiar system design.
This isn’t an argument for novelty
Not all functionality belongs in chat. Not all users want guidance. Some domains still require formality, delay, and explicit handoffs.
This isn’t about chasing trends.
It’s about recognizing that systems age relative to expectations, not correctness. When expectations shift, correctness becomes an insufficient defense.
Treating chat as “just support” is no longer neutral. It’s a design choice—to preserve old boundaries even when customers no longer experience them that way.
What’s the takeaway? Users expect your system to work like a text conversation. If you started again and designed your support system today, what assumptions would it make about customer patience? I’d start by making sure you can answer more questions instantly and well, and setting expectations appropriately when your team needs more time to work.
Links for Reading and Sharing
These are links that caught my 👀
1/ Context is king - When you’re building applications (especially for AI), state is only the first thing you need to think about. Context is everything.
2/ A cookbook for agents - A wonderful compendium of patterns for AI agents. Check it out here and you’ll probably also check some of your assumptions.
3/ On estimating work - If you’ve ever been asked, “how long will it take?” and the answer that immediately popped into your head was “it depends…” you probably need to read this piece on estimating, written by a software engineer.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon