Two things clutter a support queue more than volume ever does. The first is work that is genuinely waiting on something: a shipment, a release, a customer who said they would check next week. The second is the same question arriving twice because two people asked, or one person asked twice, or a chat became a ticket that already existed.
Snooze and merge are the tools for those two problems, and both are easy to use badly. This guide is about what each one actually does to a ticket, which is not always what teams assume, and about the habits that stop either from turning into a way of losing work quietly.
Snooze is a promise with a date on it
Snoozing sets a wake time on a ticket. The time has to be at least a minute in the future, which sounds like a technicality and is actually the whole point: you are being asked to name a moment when this becomes your problem again.
That framing is the useful part. A ticket you cannot name a wake time for is not waiting, it is stuck, and stuck tickets need a different intervention: an escalation, a decision, or an honest close. The discipline of choosing a date turns a vague sense of later into a commitment, and a queue where every waiting ticket has a date is a queue you can trust.
Pick the date from the thing you are waiting for, not from your own comfort. If a supplier said Thursday, wake on Friday morning, not in a week. If a customer said they would test it over the weekend, wake on Tuesday, which gives them Monday and gives you a reason to follow up that does not sound impatient. And say the date out loud in your last message before you snooze, because a customer who knows they will hear from you on Friday does not send three chasing messages before then. That single sentence removes more inbound volume than most automation does.
What snooze actually changes
Be precise about this, because assumptions here cause real misses.
Snoozing records the wake time on the ticket, writes an entry in the activity log naming the time, and raises an event that integrations can subscribe to. The queue gains a Snoozed filter with a count, so you can look at everything currently waiting as its own list. When the wake time passes, the snooze clears itself the next time the ticket is read, and that clearing is logged as a system action rather than attributed to a person.
What snooze does not do, in the current build, is hide the ticket from your main list. The Snoozed chip is an additional view rather than a subtraction from the default one, so a snoozed ticket is still there among the rest, ordered by when it was last updated. If your mental model was that snoozing sweeps something out of sight until Friday, adjust it: the value you are getting is the recorded intent, the filterable list and the activity trail, not an empty queue.
That turns out to be a reasonable trade in practice. Teams that hide waiting work eventually stop looking at it, and a queue that is honest about its own size is easier to staff. But it does mean that snooze alone will not create the tidy view some teams expect, and if a clean working list is what you need, that comes from assignment and status discipline rather than from snoozing. There is a manual unsnooze for the case where the thing you were waiting for arrives early, and using it is better than editing the wake time.
The reply that arrives while you wait
Here is the case worth designing around: you snooze a ticket for a week, and the customer replies the next morning.
Their reply is recorded, the ticket updates, and its wake time stays exactly where you set it. Nothing about a customer message cancels a snooze. The ticket does move to the top of a list ordered by recent activity, so it is not invisible, but nothing announces that a waiting ticket has become an active one, and nobody is going to notice it if the whole team has silently agreed that snoozed means handled.
Two habits cover this. First, whoever works the queue should scan for updated-recently rather than only for unassigned, because the ticket that changed while nobody was watching is the one most likely to have gone quiet on a customer. Second, if you run integrations, subscribe to the requester-replied event and route it somewhere a human sees, which turns a scanning habit into a notification. Both of these are cheap, and either one prevents the specific failure where a customer answers your question within an hour and hears nothing for a week.
If you use a reply from the customer as your signal to pick something up, the same care applies to reopening resolved conversations, where the distinction between a new issue and a continuation of an old one decides whether your metrics tell the truth.
Merge without moving anything
Merging is what you do when the same issue exists twice. In many tools, merging means one ticket's messages are physically moved into another, which is tidy right up until you need the audit trail.
Here it works differently, and knowing that changes how you use it. A merge is non-destructive: no messages or history are moved between the two tickets. The source ticket is closed and gains an activity entry recording that it was merged into the other one. The target gains a matching entry recording what was merged into it. Both records stay readable, both keep their own identifiers, and each side points at the other, so anyone reading either one later can follow the link.
The practical consequence is that a merge is a statement about relationship, not a rewrite of history. Nobody loses a permalink, no attachment is orphaned, and the audit trail of what happened where stays intact. It also means the target does not suddenly contain the source's messages, so if there is something in the older ticket the assignee genuinely needs, quote it or summarise it in a comment on the target rather than assuming it travelled.
Choose the target deliberately. The convention that causes least confusion is to merge into whichever ticket has the most context and the right assignee, not automatically into the older one. Then say so to the customer in a single sentence if both tickets were theirs, because two threads collapsing into one without explanation reads like a message was ignored.
The rules a merge will refuse
A handful of merges are rejected outright, and each refusal is protecting something.
A ticket cannot be merged into itself, which is the kind of thing that only happens by mis-click but is worth failing loudly. Both tickets have to belong to the same account, so there is no path by which one customer's history joins another's. The target cannot be a closed ticket, because dumping live work onto an archived record is how it stops being seen. And a ticket that has already been merged cannot be merged again, which keeps the trail readable: one source, one destination, one entry on each side.
If you hit that last one, the fix is not to force it but to work with the chain you have. The already-merged ticket points at its target, and that target is the live record; merge into that instead. When three or four duplicates arrive over an afternoon, merging each of them into the single canonical ticket keeps every trail one hop long, whereas merging them into each other in a chain produces something nobody can follow a month later.
Duplicates are a signal, not just a chore
The instinct with duplicates is to merge them and move on. Do the merge, but notice the pattern first, because a run of duplicates usually means something specific.
The same customer opening two tickets in a day generally means the first one felt unanswered. Look at the response time on it before you merge; if it was slow, the duplicate is feedback and the merge alone does not address it. Many different customers filing the same issue within an hour means an incident, and that deserves a status update far more than it deserves tidy queue hygiene. A chat that became a ticket that duplicates an existing one usually means the handoff is not looking up the customer's open items, which is a process fix rather than a per-ticket one.
Recording why you merged, in a sentence on the target, is what turns this from a chore into data. Three months later, the difference between merged as duplicate of an outage and merged because the customer did not get a reply is the difference between a story you can act on and a number you cannot. The broader queue-shaping habits in managing the queue build on exactly this kind of note, and the transcripts and history features are where the trail ends up.
What to measure
Count snoozed tickets as a proportion of open ones. A team where a third of the queue is waiting on something external is not slow; it is blocked, and that is a completely different problem with a completely different fix.
Watch how often a snooze is extended rather than resolved. One extension is life. Three on the same ticket means the thing you are waiting for is not coming, and the honest move is to tell the customer that and close it rather than to keep the promise alive by moving the date.
Track your duplicate rate over time, not per incident. It should be low and boring. A rise usually points at one of three causes, all of them fixable: an outage nobody announced, a contact form that people submit twice because it gives no confirmation, or a handoff between chat and tickets that is not checking what the customer already has open.
Merging is not the only way two tickets can be joined. When they are genuinely separate but belong in each other's context, linking them instead keeps both threads intact and still shows each one the other's current status.