Philippines staffing blog ·
Detect duplicate help desk tickets without losing customer context
Link related requests only when the owner, impact, and work path match closely enough to reduce duplicate handling safely.
Direct answer
The operating answer
Treat two tickets as duplicate candidates only when they describe the same underlying request, affected object, time window, and desired outcome. Similar wording is a search signal, not proof. Before merging, a reviewer should compare requester or affected account, service, symptom, impact, chronology, current owner, linked incident, privacy boundary, and customer promises.
Prefer linking over destructive merging when separate customers, evidence permissions, or communication obligations exist. Choose one canonical work record, preserve a visible relationship from every source record, and state which ticket owns investigation versus customer follow-up.
Field definitions
Terms to define in the workflow
- Duplicate candidate
- A record similar enough to review, but not yet confirmed as the same request.
- Canonical ticket
- The record that owns the shared next action; it is selected for completeness and ownership, not simply because it is oldest.
- Linked companion
- A separate record that keeps its customer impact and communication while referencing shared technical work.
- Affected object
- The account, order, device, workspace, service, or event to which the request actually applies.
- Collision window
- A documented period in which repeated submissions are likely to concern the same event; it varies by request type.
- Merge reversal
- The approved way to restore records if later evidence shows that two requests were incorrectly combined.
Decision table
Duplicate decision rubric
| Evidence pattern | Disposition | Reason | Preserve |
|---|---|---|---|
| Same requester, object, symptom, and goal within minutes | Merge if policy permits | Likely repeated submission | Original channel, timestamps, attachments, and promises |
| Different customers, same confirmed incident | Link, do not merge | Technical investigation is shared but impact and communication differ | Each customer's impact, consent, and checkpoint |
| Same account and wording, different transaction IDs | Keep separate pending review | One answer may not resolve both objects | Distinct evidence and outcomes |
| Forwarded email duplicates an existing portal ticket | Merge after identity and scope match | Two channels contain one request | Email provenance and portal ownership |
| Similar error text but different service or time | Reject duplicate | Text similarity cannot establish cause | Separate triage and route |
Swipe or scroll sideways to read every column.
Score identity of work, not similarity of words
A practical review uses four decisive dimensions: same affected object, same requested outcome, overlapping event, and compatible ownership. Requester and symptom support the decision but are not sufficient. One administrator may submit separate access requests for several users; several customers may report one incident. A text matcher can surface candidates, while a trained reviewer confirms the operational relationship.
Set request-specific collision windows. Two identical password-reset submissions five minutes apart may be duplicates, while the same request a week later may be a genuine recurrence. Document why the window fits expected completion and customer behavior. Never let an automated confidence score silently merge records that contain security, identity, payment, or sensitive evidence.
Choose what becomes shared and what remains individual
The canonical record owns the common investigation, approved action, and technical status. A companion record retains its original request, impact, customer communication, verification result, and closure evidence. This split prevents a broad incident record from erasing a customer's unique loss or a customer-specific record from exposing details to unrelated requesters.
After combining records, recalculate ownership and promises. Notify the customer only if the change affects where replies appear or what checkpoint applies. Closing a source ticket with duplicate is insufficient if no link, canonical owner, or next update remains visible. Maintain an unmerge path so a later mismatch can be corrected without recreating history from memory.
Worked example
Worked example: three checkout reports
Ticket A reports that order 8021 failed at payment confirmation at 12:04 UTC. Ticket B, from the same customer, was emailed two minutes later with the same order and screenshot. Ticket C, from another customer, reports a different order failing at 12:06 with the same visible message. Monitoring later confirms a checkout incident beginning at 12:00.
A and B can be merged after confirming the email and portal request share the same goal and no unique promise is lost. C should remain separate and link to the incident because its customer, order evidence, and follow-up are distinct. All three may share the technical incident timeline, but each customer ticket must keep its impact, permitted identifiers, update checkpoint, and confirmation of outcome.
Implementation checklist
Review before the workflow goes live
- Compare affected object and requested outcome before text similarity.
- Check time window, channel provenance, service, and current owner.
- Look for unique impact, attachment, promise, approval, or privacy restriction.
- Select a canonical record for completeness and ownership, not age alone.
- Link separate customer records to shared incidents instead of merging them.
- Preserve source timestamps, communications, and evidence references.
- Reassign next action and customer checkpoints after consolidation.
- Sample false merges and missed duplicates, then adjust the candidate rule.
Cautions
Boundaries to keep visible
Do not optimize ticket counts by collapsing ambiguous records. A smaller queue can hide unresolved customers, distinct approvals, or evidence needed for later review.
Do not copy one customer's details into another customer's ticket when linking shared work. Relationship metadata should preserve separation and approved access.