The ticket is a useful abstraction borrowed from IT service management: a discrete unit of work with a status, an owner and a closure event. It works beautifully for internal infrastructure requests. It works considerably less well for a customer who has been talking to your company for three years.

What ticket-shaped thinking optimises for

Because tickets are closed rather than resolved, every incentive in a ticket-first system pushes towards closure. Agents close threads that have gone quiet. Automation closes threads after a timer. Dashboards celebrate throughput. Meanwhile the customer's underlying problem may be entirely unsolved, and the record of it is now three closed tickets nobody will read together.

The conversation model

In a conversation model the primary object is the ongoing dialogue with a person, and work items hang off it. A conversation can be idle without being closed. It carries the full cross-channel history. Escalations, tasks and internal notes attach to it rather than replacing it.

  • Idle instead of closed: a thread with no pending action goes quiet but stays reachable, so the customer's reply lands in context rather than starting from zero.
  • Tasks are separate from threads: an engineering investigation gets its own work item with its own owner and SLA, without holding the customer conversation hostage.
  • Ownership is explicit: exactly one person is accountable for the next customer-facing action at any moment.

Queues built for a conversation model

Once conversations are the unit, queue design changes shape. Instead of one giant unassigned pool sorted by age, you get a small number of intent-based queues with clear entry criteria and a single triage owner per shift. Priority becomes a function of the customer's stated deadline, account context and sentiment, rather than the accident of arrival order.

Metrics that survive the change

Resolution rate and first response time still work. Average handle time gets less useful, because a conversation may legitimately span days. Replace it with two measures: time to first useful response, and total customer-perceived waiting time, the sum of the gaps where the customer was waiting on you. The second number is the one customers actually experience, and almost nobody reports it.

Migrating without chaos

Run both models briefly and deliberately. Keep tickets as the internal work-item type, introduce conversations as the customer-facing spine, and move reporting to the conversation level last, once agents trust the new view. Teams that flip reporting first tend to lose confidence in the numbers at exactly the moment they need it most.