Philippines staffing blog ·
Check incident scope before linking help desk tickets
Use evidence and impact to decide whether a request belongs to a wider incident while keeping the individual ticket useful.
Direct answer
The operating answer
Before linking a help-desk ticket to an incident, compare affected service or function, symptom, first-observed time, geography or account segment, version or environment, known workaround behavior, and the incident owner's current inclusion criteria. A matching error phrase alone is insufficient. Record whether the relationship is confirmed, probable and under review, or rejected.
The individual ticket must retain its customer's impact, evidence, promise, and communication owner even after linking. The incident record owns shared investigation and confirmed broad facts; it should not replace customer-specific verification or closure.
Field definitions
Terms to define in the workflow
- Incident inclusion rule
- The current observable conditions a ticket must meet to be treated as part of the shared event.
- Correlation evidence
- Facts connecting the ticket to the event, such as timing, function, region, version, or a confirmed event identifier.
- Relationship confidence
- Confirmed, probable, possible, or rejected, with the person or evidence that supports the label.
- Individual impact
- The customer's blocked task, affected users, business consequence, and verified workaround status.
- Shared fact
- A statement approved by the incident owner for reuse across linked customer communication.
- Unlink trigger
- Evidence that requires separate triage, such as different behavior, unaffected environment, or persistence after recovery.
Decision table
Incident scope matching matrix
| Dimension | Matches incident | Needs review | Likely separate |
|---|---|---|---|
| Affected function | Same operation named in inclusion rule | Adjacent feature with shared dependency | Different service or user task |
| Time | Begins within confirmed event window | Customer provides approximate time | Clearly predates event or begins after verified recovery |
| Environment | Included region, version, or account segment | Environment data unavailable | Known unaffected environment |
| Symptom | Observable behavior matches approved description | Only broad error wording matches | Different result or failure stage |
| Workaround | Confirmed incident workaround behaves as expected | Not safe or possible to test | Workaround succeeds or fails in a contradictory way |
Swipe or scroll sideways to read every column.
Use a versioned inclusion rule
Incident scope changes as evidence arrives. Store the rule with an effective time and owner: for example, save requests in region East returning error E17 from 12:00 UTC. A later expansion to all regions should not make an earlier support claim appear verified retroactively. Specialists need the current rule and a place to route non-matching evidence.
When evidence is incomplete, choose under review rather than force a binary decision. Preserve the next check and customer checkpoint. Do not ask customers to perform unsafe retries or expose sensitive logs solely to prove correlation. A service owner may confirm the relationship from internal telemetry while support maintains the permitted customer record.
Keep shared investigation and individual service distinct
Linking should reduce repeated technical work. It should not close the ticket, erase unique impact, or turn an incident restoration into proof that the customer's requested outcome is complete. After the incident owner announces recovery, verify the individual function through the lightest appropriate method and route persistent symptoms separately.
Review false links and missed links after closure. False links are tickets attached without sufficient evidence; missed links required duplicate investigation despite matching scope. Examine whether the defect was intake wording, stale inclusion criteria, missing environment data, or slow incident-owner communication. Update the scope rule and examples rather than training specialists to trust broad keywords.
Worked example
Worked example: similar export errors with different scope
An incident is confirmed for PDF exports in version 6.4 in the Europe region beginning 11:20 UTC. Ticket A reports PDF export error E52 in Europe on 6.4 at 11:33; it matches and can be linked as confirmed. Ticket B reports CSV export error E52 in Europe but has no version; it is under review because the function and environment do not fully match.
Ticket C reports PDF failure in North America on 6.3 that began the previous day. It should remain separate despite sharing the error text. For A, the shared incident record owns investigation, while the ticket keeps the customer's monthly-report impact and 13:00 update. After recovery, A still requires an outcome check; C continues independent triage, and B needs the permitted version fact.
Implementation checklist
Review before the workflow goes live
- Read the incident owner's current, time-stamped inclusion rule.
- Compare function, symptom, time, environment, and workaround behavior.
- Record correlation evidence and confidence instead of keyword matching.
- Use under review when a decisive permitted fact is missing.
- Keep customer impact, evidence, and checkpoint in the individual ticket.
- Reuse only customer-safe facts approved for the incident scope.
- Unlink or retriage contradictions and symptoms persisting after recovery.
- Review false links and missed links to improve the scope rule.
Cautions
Boundaries to keep visible
Do not tell a customer that a known outage caused the issue until the relationship and wording are confirmed by the responsible incident path.
Do not expose one customer's information through a shared incident record. Shared technical facts and individual customer evidence need different access boundaries.