On this page
Two tickets with the same subject line may describe one repeated request, two different customers affected by an incident, or separate problems on the same account. Merging them because they look similar can hide unresolved work or expose information to the wrong people.
Treat merging as a deliberate record change. Confirm that the cases belong together, understand what the support platform will preserve and notify, and choose the destination record carefully. When the relationship is uncertain, a controlled link between tickets is often more appropriate than combining them.
Establish identity through the normal support process
Check who submitted each request and which account or organization it concerns. A matching display name or email subject is not enough. Use the service's approved identity and authorization checks, especially when the record contains private account information.
Do not ask a requester to reveal passwords or authentication codes to prove that two tickets are theirs. If the requests came through different channels, reconcile identity using the supported account and contact process.
If two people represent the same organization, that does not automatically authorize each to see the other's conversation. Their roles, permissions, and the information in the tickets still matter.
Compare the unresolved outcomes
Read beyond the opening sentence. Determine what each requester needs, which transaction or device is affected, and what remains unresolved. A second message may add evidence to the first problem, but it may also introduce a new request that deserves separate tracking.
For example, two reports that a single upload failed may be duplicates. A request to restore the upload and a separate request to correct a resulting invoice may involve related but distinct outcomes. Combining them without preserving both actions can lead to premature closure.
Use the help desk priority guide to assess impact and urgency separately from duplication. A newer ticket is not less important merely because a similar older record exists.
Distinguish a shared incident from a shared conversation
Many customers can experience the same outage while each has a separate account, impact, and communication history. Link those cases to the common incident or problem record using the platform's supported relationship features.
Do not merge unrelated customers into one conversation just to reduce the queue count. The incident record can hold shared technical updates while individual tickets retain private details and customer-specific follow-up.
The customer service escalation matrix helps route the shared problem to its owner. Linking should make coordination easier without erasing who still needs a response.
Read the platform's merge behavior first
Merge behavior differs by product and configuration. Zendesk, for example, documents that merges are permanent and cannot be undone. Its rules also describe how requesters and CCs can move, which comment is included, and which ticket fields are not carried across.
Those details mean a merge is not simply concatenating two histories. The destination can retain different field values from the source, and a solved destination may not reopen automatically. Check the current documentation for the exact system and status combination you use.
If the platform displays a preview of recipients or comments, read it before confirming. Do not rely on memory from another help desk product or an older version of the same interface.
Inspect privacy and notification consequences
Review the participants, public comments, private notes, attachments, and organization access on both records. Determine what the merged conversation will reveal and to whom. A technically permitted merge can still be inappropriate for the information involved.
Check whether requesters or copied participants will be added to the destination and whether a notification will be sent. Avoid including sensitive details in a public merge explanation when a short neutral reference is sufficient.
Follow the organization's data-handling rules. The FTC's information-protection guidance supports limiting access to legitimate need; it does not provide a product-specific merge procedure or make every same-organization disclosure appropriate.
Choose the destination for continuity
Select the record that best preserves the active ownership, customer communication, and unresolved work. The oldest identifier may be useful for continuity, but age alone should not override the correct requester, permissions, or workflow state.
Check the destination's priority, type, status, owner, linked work, and commitments. If the merge process does not carry important fields across, record the necessary information in the destination through the approved workflow before the source becomes unavailable for editing.
Avoid creating a second unofficial summary outside the support system. Keep the rationale and cross-reference where the next agent can find them with the appropriate access.
Preserve every outstanding action
List the tasks that remain after the merge, including promises made in either conversation. A duplicate report can contain a new deadline, attachment, or customer response that changes the next step.
Confirm that there is one clear owner for the combined work and that the destination remains in a state appropriate to its unresolved outcome. A merge should not accidentally mark an open need as solved.
The support shift handover guide provides a useful structure for transferring current state, commitments, and next actions. Apply that level of clarity when combining records, even if the owner does not change.
Use linking when merging would remove useful distinctions
Link records when the causes are related but the outcomes, customers, permissions, or responsible teams differ. State the relationship: possible duplicate, same incident, dependent request, or follow-up issue. Do not label a suspected relationship as confirmed without evidence.
Keep each ticket's closure criteria explicit. A fix to the shared system may resolve one customer's request while another still needs data recovery or billing follow-up. The relationship should help coordinate those tasks rather than force them into one status.
If the system lacks a suitable relationship feature, use a controlled internal reference and follow the organization's process. Avoid adding private ticket URLs to customer-visible messages unless the recipient is authorized to access them.
Verify the result after the action
After an authorized merge, inspect the destination's recipients, status, fields, visible comments, ownership, and remaining tasks. Confirm that the source reference is traceable and that any expected notification accurately describes the next step.
If something went wrong, do not assume an unmerge button exists. Follow the platform's support guidance and the organization's incident or privacy process as appropriate. Preserve the facts of the mistake rather than editing the record to conceal it.
The decision is sound when one combined case accurately represents the work and its permitted audience. A lower ticket count is a consequence of that decision, not the reason to make it.
Sources and further reading
Primary and contextual sources used to verify definitions or give readers a relevant next resource.
- Zendesk: Merging tickets Merges are permanent; requester and CC behavior, comments, fields, and ticket status have specific rules that must be checked before merging.
- FTC: Protecting personal information Businesses should understand the personal information they hold and limit access and retention according to legitimate need.