# Support ticket triage SOP

Version: 1.0  
Owner: Support operations  
Review cadence: Monthly and after any category, policy, model, or channel change

## Purpose

Turn each new or materially updated support request into one versioned triage record. This procedure classifies the case; it does not assign an individual, send a customer reply, merge cases automatically, or make a consequential decision.

## Trigger and completion

- Start: a new source-message ID is registered or a customer reply materially changes an open ticket.
- Complete: one atomic triage record exists and either `triage.completed` or a named exception event has been emitted.
- Idempotency key: `{channel}:{source_message_id}:{triage_policy_version}`.

## Required inputs

- Original message reference and approved derived text
- Channel and source-message/thread IDs
- Trusted customer/account lookup result
- Open and recent related-ticket references
- Current intent taxonomy, priority matrix and exception policy
- Classifier version and field-specific confidence thresholds

## Procedure

1. Register the original event before transforming content.
2. Normalize a derived copy; preserve the original and attachment references.
3. Resolve trusted customer and account IDs. If missing or conflicting, restrict account data and open `identity_resolution`.
4. Check exact duplicate keys, then retrieve bounded similarity candidates. Never merge or close from similarity alone.
5. Ask the classifier for schema-bound intent, product area, language, entities, field confidence and evidence spans.
6. Derive urgency with the priority matrix using verified impact and scope. Sentiment alone cannot set severity.
7. Apply hard stops for security, safety, account-takeover, low confidence, conflicting labels and unsupported label combinations.
8. Present exceptions with the original, proposed value, evidence spans, failed rule and permitted corrections.
9. Record the reviewer correction as a new event with reason; do not overwrite the proposal.
10. Commit all accepted fields atomically with taxonomy, policy and classifier versions.
11. Emit one completion event for routing and SLA-policy selection.

## Named exception queues

- `identity_resolution`: trusted account ID absent or conflicting
- `possible_duplicate`: merge requires a coordinator
- `multi_issue_split`: person confirms proposed child cases
- `protected_urgent_review`: security, safety, threat or takeover signal
- `category_owner_review`: low confidence, conflict or unsupported combination
- `triage_system_recovery`: classifier, source-read or atomic-write failure

Each exception needs an owner, age target, reason code, required evidence and return condition.

## Quality controls

- Daily random sample of auto-accepted records during rollout; reduce only after stable evidence.
- Review every high-priority miss, protected-path miss and incorrect merge.
- Compare releases on a fixed, representative evaluation set.
- Track correction rate per field, category and channel; abstention; high-priority false positives/misses; duplicate reversals; and time to committed triage.

## Audit record

Keep intake ID, source reference, trusted identity IDs, candidates, proposed and final fields, confidence, evidence spans, rules fired, exception, reviewer, timestamps, and all model/taxonomy/policy versions. Do not place unnecessary message content or credentials in logs.

## Rollback

Disable classifier acceptance, retain deterministic intake and route every new classification to `category_owner_review`. Reprocess only from immutable intake events and only with a new triage version.