Hey everyone! I was just helping a new team member get set up in our support platform, and they asked a question that I realized might be a common point of confusion for folks just starting out.
What's the practical difference between a "ticket" and a "conversation"? At first glance, they seem like they could be the same thing—a customer reaches out, you help them, it's done. But the way modern platforms handle them can be quite different, and it affects your workflow.
Here's how I usually break it down:
* A **ticket** is traditionally a single, contained unit of work. Think of it like a case file. A customer submits an issue, it gets a ticket ID, and that thread is dedicated to resolving that one specific problem. Once it's solved, you close the ticket. If the same customer has a new, unrelated issue tomorrow, you'd typically create a new ticket. It's very structured and great for tracking specific problems over time.
* A **conversation** is often a continuous thread with a customer, more like an ongoing chat history. It might span multiple topics or questions over days or weeks. The platform might keep one open thread per customer (or per channel, like email). This feels more fluid and customer-centric, as you have the full context of your interactions in one place.
The platform you use (like Zendesk, Intercom, Freshdesk, etc.) will lean one way or the other, and it really changes how your team manages the inbox and reports on volume. Some newer platforms are fully conversation-based, while more traditional help desks are ticket-centric.
Has your team recently switched from one model to the other? What was the biggest adjustment for your agents? I'd love to hear what's working for people.
—Mike
Measure twice, slice once.
Spot on about tickets being a unit of work. That's critical for SLAs and metrics. The closure creates a clean audit trail.
Where I've seen teams trip up is trying to use a "conversation" model for technical support. It gets messy fast. You lose the ability to measure time-to-resolution on discrete issues because everything is one long, rolling thread.
Use conversations for sales or onboarding chats. Use tickets for any actual problem that needs tracking and closure.
Benchmarks or bust.
That line about sales or onboarding chats is interesting. What about a hybrid case? Say a customer in an onboarding conversation suddenly reports a technical bug. In a platform like Intercom, you'd probably have to spin that out into a separate ticket manually. Does that manual step break the flow, or is it a necessary hygiene check?
You're missing the forest for the trees. The difference isn't about hybrid cases or platform features. It's about how you get paid.
Tickets are for billable work. You track them, you measure them, you report on them. Conversations are chatter. You can't invoice for a conversation.
That "necessary hygiene check" of spinning off a bug report is the whole point. It forces the work to be acknowledged and tracked. If that breaks someone's flow, their flow is the problem.
-- old school
You're right about the tracking and billing angle. That's the core of it for any managed service or consultancy.
But boiling it down to "you can't invoice for a conversation" oversimplifies the problem. A lot of chatter *leads* to billable work. If you're not tracking the source conversation where the need was identified, you lose context on why the ticket was created in the first place. That can hurt later.
A ticket without the conversational history is just a task. Sometimes you need the thread to understand the real ask.