Support Ticket Triage Automation: Intake to a Defensible Queue

# 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.

# Support ticket triage workflow blueprint

```yaml
name: support-ticket-triage
version: 1.0.0
trigger:
  events: [ticket.created, customer.reply_material]
idempotency_key: channel + source_message_id + triage_policy_version
input:
  required: [ticket_id, source_message_id, original_reference, channel, policy_version]
  optional: [authenticated_account_id, locale, attachments, related_ticket_ids]
output:
  required: [triage_id, intent, product_area, language, priority, exception_state, provenance, versions]
side_effects:
  allowed: [write_triage_record, emit_triage_event, open_named_exception]
  forbidden: [send_customer_reply, merge_ticket, close_ticket, restrict_account, issue_refund]
```

## States

`registered -> normalized -> identity_resolved -> duplicate_checked -> classified -> rules_checked -> accepted|review_required -> committed`

Terminal exception states: `identity_resolution`, `possible_duplicate`, `multi_issue_split`, `protected_urgent_review`, `category_owner_review`, `triage_system_recovery`.

## Step contracts

| Step | Type | Reads | Writes | Retry rule |
|---|---|---|---|---|
| register | deterministic | source event | immutable intake | create-if-absent |
| identity | deterministic | trusted identity service | account IDs or exception | bounded retry, no broad search |
| duplicate | deterministic + retrieval | exact keys, bounded candidates | candidate references | read-only replay |
| classify | model | approved derived text, taxonomy | labels, confidence, spans | pin version; no side effect |
| priority | deterministic | verified impact/scope, matrix | priority, fired rules | pure function |
| gate | deterministic | proposed record, thresholds | accept or named exception | pure function |
| review | human | original, proposal, evidence, failed rule | correction event | never auto-repeat approval |
| commit | deterministic | accepted fields and versions | atomic triage record/event | compare-and-set triage ID |

## Invariants

1. Exactly one committed record per idempotency key and version.
2. Every model field has confidence and evidence spans.
3. Sentiment cannot independently increase priority.
4. Similarity cannot merge or close tickets.
5. Protected signals never enter ordinary auto-accept.
6. Every correction preserves proposed and final values.

## Events

- `triage.registered`
- `triage.classification_proposed`
- `triage.exception_opened`
- `triage.correction_recorded`
- `triage.completed`
- `triage.failed`

Each event includes `triage_id`, `ticket_id`, `occurred_at`, `policy_version`, `taxonomy_version`, `classifier_version`, `actor`, and `correlation_id`.

## Acceptance tests

1. Replayed source message creates no duplicate record.
2. Missing account enters identity resolution without retrieving account data.
3. Exact source/thread duplicate is linked deterministically.
4. Similar text produces candidates but no automatic merge.
5. Two intents in one message enter split review.
6. Low-confidence intent enters category review.
7. Security phrase enters protected review regardless of general confidence.
8. Negative sentiment alone does not set P1.
9. Validation conflict blocks commit.
10. Reviewer correction preserves the proposed label.
11. Classifier timeout can replay without duplicate side effects.
12. Atomic write failure emits no completion event.
13. Taxonomy change creates a new version rather than rewriting history.
14. Logs contain references and decisions but no credentials.