Zendesk Ticket: Fields, Statuses and Merging Duplicates

What is a Zendesk ticket made of, beyond the message in it?

A zendesk ticket is a record, not a transcript. The visible conversation — the back-and-forth between a customer and an agent — is only one part of it. Underneath sit the fields that decide how the ticket sorts, reports and routes: a status, a requester, an assignee, a group, a priority, a type, a set of tags, whichever ticket form was used to create it, and any custom fields your account has added on top of Zendesk’s defaults.

For a $3M–$30M Shopify Plus or comparable subscription-platform operation, this distinction matters because reporting is built entirely on the fields, not the conversation. A dashboard showing tickets by status, by group, or by custom field value is only as accurate as those fields are consistently set — and at real ticket volume, consistency is the first thing that slips. An agent who solves a ticket correctly but forgets to set its type, or leaves a custom field on whatever it defaulted to, hasn’t made an error a customer will ever see. They’ve made an error your weekly reporting will carry silently for as long as nobody audits it.

Most Zendesk content skips this part, because it’s written for the person deciding whether to buy the product, not the person three months in trying to work out why last month’s numbers don’t add up. This article covers what the status values mean and where solved and closed diverge, how custom fields drift from what reporting expects, when and how to merge duplicate tickets without losing history, and the three failure modes in the ticket lifecycle that quietly break reporting at volume.

What the ticket status values mean, from New to Closed

Zendesk’s default status set is New, Open, Pending, On-hold, Solved and Closed, and each one is a claim about who’s holding the ball, not just a label. New means the ticket exists and nobody has acted on it yet — a fresh submission sits here whether it came from email, a web form, an API call, or a converted chat. Open means an agent has picked it up and it’s actively being worked. Pending means the agent is waiting on the customer for a reply — this is the status that should be moving tickets out of an agent’s active queue without marking them resolved. On-hold typically means the agent is waiting on someone internal, such as fulfilment confirming a warehouse issue, rather than on the customer.

Solved means the agent considers the issue resolved. This is the status most reporting treats as the meaningful endpoint — resolution rate, time-to-resolution and most SLA-style measures key off the move into Solved, not into Closed. Closed is the final, typically irreversible state: a ticket that’s been Solved for long enough, based on a setting your account controls, moves automatically to Closed, after which it generally can’t be reopened by a customer reply the way a Solved ticket can.

Some accounts rename these labels or restrict which ones agents can set manually — a ticket form can, for instance, prevent an agent from setting Closed directly, reserving that transition for the automatic timer. Don’t assume your account uses the stock labels and stock behaviour without checking Admin Center; this is exactly the kind of account-specific configuration that varies enough between installs that describing an exact default number of days, or an exact permission set, here would be guessing rather than reporting.

Why solved and closed are not the same thing, and why your reporting cares

The gap between Solved and Closed is where a surprising amount of reporting goes wrong. A ticket sitting in Solved is still technically live: a customer reply typically reopens it, moving it back to Open, and an agent can still see it as an active thread. A ticket that’s reached Closed is locked: no further replies from the customer reopen it, and any follow-up on the same issue has to become a new ticket instead of continuing the old thread, which has its own consequences for how you merge and count tickets.

Satisfaction surveys usually key off this transition too: most accounts send a CSAT survey shortly after a ticket moves to Solved, not after it moves to Closed, and only within a window your account controls. A ticket that gets solved and reopened multiple times before finally closing can end up sending zero surveys, one, or several, depending entirely on how your triggers are built — this is worth checking directly rather than assuming survey volume matches ticket-solved volume one-to-one.

The reporting risk sits in treating “solved” as a stable, final number. A ticket solved on Monday and reopened by the customer on Wednesday still counts in Monday’s “tickets solved” report if that report is a point-in-time snapshot rather than a query re-run against current status. Anyone using a solved-ticket count as a resolution-rate metric needs to know whether that count is being re-verified against current status or frozen at the moment it was first solved — the two numbers diverge every time a ticket bounces back, and at real volume some percentage always will.

Keep custom fields from drifting away from what reporting expects

Custom fields are how a Zendesk ticket carries anything specific to your business that isn’t in the defaults — order number, return reason, product category, subscription plan tier, whatever your support model needs to sort by. They’re also the part of the ticket record most likely to quietly stop matching what your saved views and reports expect, because changing a field is easy and updating every downstream report that depends on it is a separate, un-forced step.

The most common drift: a dropdown field’s options get renamed or reordered by an admin cleaning things up, without anyone checking which saved views, triggers or automations filter on the old option values. Those filters don’t error — they just silently stop matching anything, or start matching the wrong tickets, and a report that used to show forty return-reason tickets a week starts showing zero, with no alert telling anyone why.

Inconsistent agent use causes a second, slower kind of drift, separate from any admin change to the field itself. A custom field that isn’t required at ticket-close time gets left blank by agents under time pressure, especially once ticket volume rises past what a single team can carefully triage. At low volume, a manager might catch and backfill these by hand. Past a certain point, nobody does, and the field’s reported completeness rate — the percentage of tickets where it’s actually filled in — degrades gradually enough that it’s rarely raised as a problem until someone builds a report that depends on it and finds half the data missing.

The fix is process, not a Zendesk setting: treat every custom field change — rename, reorder, addition, removal — as a change request that includes checking every saved view, trigger and report that references it, in the same change rather than as a follow-up. And where a field genuinely needs to be filled for reporting to work, make it required on the ticket forms that use it, accepting that this adds friction for agents in exchange for data you can trust later.

Decide when two tickets should be merged instead of left separate

Merging exists for one situation: the same customer, the same unresolved issue, reported more than once — usually because they emailed, then also used the chat widget, or submitted the contact form twice because the first submission didn’t show a confirmation. Merging combines these into a single ticket so an agent isn’t working the same problem twice and a customer doesn’t get two different answers from two different agents unaware of each other.

Merging isn’t for every ticket that shares a customer or an order. A customer who asks a sizing question before buying, then opens a separate ticket three weeks later about a return on that same order, has raised two different issues that happen to share context — not one issue reported twice. Merging those muddies the resolution history for both: the sizing question’s resolution gets buried inside a ticket that’s really about the return, and reporting on “sizing questions solved” now undercounts because one instance is hiding inside a merged ticket tagged for something else.

The practical test: would resolving the first ticket also have resolved the second? If yes, they’re duplicates and belong merged. If the second ticket exists regardless of how the first was resolved, they’re related but distinct, and should stay as two tickets — cross-referenced by order number in a custom field if you want the connection visible, not combined into one thread.

Merge duplicate tickets without losing the history

Zendesk merges one ticket into another — a source into a target — not a batch of many at once, so combining three duplicate submissions of the same issue takes two separate merge actions. Pick the target deliberately: usually the ticket with the most relevant context already in its thread, or the one a specific agent has already started responding to, rather than defaulting to whichever ticket happens to be older or newer.

What actually happens on merge: the source ticket closes and is linked to the target, and its comment content is added into the target’s thread — typically as an internal note rather than a message the customer sees again, so the target’s future replies don’t confuse the customer with a duplicated conversation. The source ticket’s own ID still exists afterward and can still be looked up directly; it’s closed and linked, not deleted, which matters if any external system had already referenced that ticket’s ID.

What doesn’t automatically happen: the source ticket’s custom field values don’t transfer onto the target. If the source had an order number, return reason, or any other custom field filled in that the target doesn’t, an agent needs to manually copy that across during the merge — it’s a step you have to remember to do, not a default the merge performs for you. Skipping it is how a well-organised support team ends up with a target ticket missing exactly the field value a report needed three weeks later.

At volume, the historical reporting risk is specific: once a source ticket is merged and closed, any report that counts activity by ticket ID stops accumulating events against that ID, because the conversation continues on the target’s ID instead. A report built to track “tickets per customer” or “time to resolution” by counting distinct ticket IDs over a period will, if it doesn’t account for merges, either double-count the issue (once under the closed source, once under the target) or undercount it (if it filters out closed tickets entirely, losing the source’s earlier activity). Whoever owns your reporting needs to know whether merged tickets are being handled correctly in whatever tool or query produces those numbers — this is not something to assume works by default.

What ticket data syncs from your store, and what doesn’t

A Zendesk ticket, on its own, knows nothing about your store. Order number, product, order value, subscription status — none of it exists on a ticket unless something puts it there. What typically does that work is a separate ecommerce integration or app that reads the requester’s matched email and pulls relevant order data into the ticket’s sidebar or into custom fields, either at ticket creation or on demand when an agent opens the ticket.

What syncs reliably, assuming that integration is installed and working: the requester’s identity, matched by email, and whatever order or customer data that specific integration is built to surface — this varies by which integration you’re running, so check its current documentation for exactly which fields it pulls rather than assuming coverage.

What doesn’t sync without deliberate configuration: anything not covered by that integration’s scope. A subscription pause date, a loyalty tier, a warranty registration — any data point specific to your stack that the integration wasn’t built to read — has to be added through a custom field populated by a separate automation, or looked up manually by the agent. And nothing pushes data the other direction by default: solving a ticket doesn’t update an order’s status or a customer’s record in your store unless you’ve built that as an explicit action, not an assumption Zendesk makes for you.

The three failure modes in the ticket lifecycle nobody documents

First: solved-but-reopened tickets double-count resolution rate. A ticket solved, reopened by a customer reply, and solved again shows up as one Solved event to a point-in-time report, but as an entirely different picture to a report re-run against live status — and if your resolution-rate metric doesn’t distinguish first-solve from re-solve, a support team’s real first-contact resolution rate is invisible inside a headline number that looks fine. This gets worse at volume specifically because reopen rate tends to rise with ticket complexity, and complexity tends to rise as a brand’s product range or order volume grows — so the metric degrades exactly as the business scales, without an alert telling anyone it’s happening.

Second: custom field drift after a rename breaks reports silently. This failure mode compounds when it happens repeatedly and nobody tracks a change log, rather than as a single isolated event. A field renamed once might get caught. A field that’s been renamed three times over two years, with saved views built and abandoned in between, leaves a reporting layer where nobody can say with confidence which filters are still matching real data and which are quietly matching nothing.

Third: merged tickets break historical reporting because the source ID stops accumulating events. This is the one that surfaces latest and costs the most to unwind, because it’s invisible until someone runs a report spanning a period that includes merged tickets and the numbers don’t reconcile against a manual count. By the time that’s noticed, the merges that caused it may be months old, and reconstructing accurate historical figures means manually tracing every merge in the affected period — work that scales with how long the drift went unnoticed.

Fix each of the three ticket lifecycle failure modes

For reopen double-counting: build or request a report that separates first-solve events from re-solve events, using the ticket’s status-change history rather than its current status alone — Zendesk retains status-change timestamps, so this is a data availability problem, not a data existence problem. Track reopen rate itself as a metric, not just resolution rate, since a rising reopen rate is often the earliest sign that agents are marking tickets solved to clear a queue rather than because the issue is actually resolved.

For custom field drift: keep a simple change log for every custom field — when it was added, renamed, or had options changed, and by whom — reviewed whenever a report using that field looks off. Some ecommerce-focused support platforms, including Gorgias, market fewer custom fields and more native ecommerce-specific ones out of the box as a way to reduce this exact class of drift; that’s a vendor-reported product claim from its own case studies, not an independently measured reduction, and it only applies if that’s the platform you’re running rather than standalone Zendesk.

For merge-driven reporting gaps: confirm, before relying on any “tickets per customer” or historical volume report, whether the query or dashboard behind it accounts for merged tickets correctly — specifically, whether it counts activity against the target ticket’s full history including merged-in source tickets, or only against events that happened after the merge. If you don’t know the answer, treat any historical count spanning a period with meaningful merge activity as approximate rather than exact until it’s checked.

Who shouldn’t trust raw ticket counts for reporting

If your support volume is low enough that one person can recall, from memory, roughly how many genuine issues came in last week, none of this granularity is worth building — the overhead of change logs and reopen tracking outweighs the reporting risk at that scale, and a manual spot-check catches what a dashboard would have caught anyway. This detail matters once ticket volume is high enough that reporting is the only way anyone sees the whole picture, which for most brands lines up with the $3M+ revenue floor this article assumes rather than an earlier stage.

It’s also worth saying plainly what raw ticket count never tells you, however cleanly the record is kept: it doesn’t tell you why volume is rising, whether it’s concentrated in a few issue types, or whether a customer service AI reading ticket content could have resolved a meaningful share of it without a human touching the queue at all. The ticket record answers “what happened and when” reliably once it’s kept honest. What to do about the pattern it reveals — where automation belongs and where a wrong answer costs more than a human minute — is the actual decision, and it’s the one Pointerflow’s customer service automation work starts from.