Goal
Turn a set of incoming support tickets into a consistent, explainable triage queue without losing urgent, repeated, or high-impact issues.
Success Criteria
- Priority is based on customer impact and urgency, not tone alone.
- Each ticket has a category, owner or routing destination, and next action.
- Possible incidents, security issues, duplicates, and missing evidence are flagged.
- Customer-facing commitments are not invented.
Inputs
- Ticket text, timestamps, account context, and attachments
- Priority definitions and service targets
- Product areas, routing rules, and owner map
- Known incidents, problems, and recent changes
- Security, privacy, and escalation policy
- Existing related tickets
Constraints
- Minimize exposure of personal, secret, payment, or security-sensitive data.
- Do not diagnose beyond the supplied evidence.
- Do not lower priority because a customer is calm or raise it only because they are angry.
- Preserve the original customer problem in the summary.
Instructions
- Summarize the reported problem, expected behavior, actual behavior, and impact.
- Identify missing reproduction details or evidence.
- Classify category, affected area, impact, urgency, and proposed priority.
- Check for incident indicators, security or privacy concerns, and duplicates.
- Route to the correct owner or queue and define the next action.
- Draft a short acknowledgement when enough facts are available.
Output
- Triage queue ordered by priority
- Per-ticket summary, classification, rationale, owner, and next action
- Incident, security, privacy, and duplicate flags
- Missing information requests
- Draft acknowledgements where appropriate
Quality Check
Apply the same priority rules to every ticket, confirm that urgent flags have evidence, and verify that routing and next actions are explicit.
Stop Rules
Escalate suspected security, privacy, safety, or broad service incidents immediately under the supplied policy. Do not close tickets, promise resolution times, or expose sensitive data.