Triage a small support batch without guessing urgency

A support triage list should help someone decide what to inspect first. It should not turn emotional wording into a severity score without a business rule.

Prepare the input

Use a small anonymized batch with stable message references. Provide your severity definitions and escalation owner. For example, an inability to access a purchased service may differ from a feature request. If no severity policy exists, ask for issue grouping rather than invented priorities.

Run the workflow

Extract the issue, affected function, evidence of impact, missing information, and suggested next step. Mark likely duplicate reports but retain their references. Separate customer claims from verified system facts.

Prompt to copy

Messages: [anonymized batch]. Severity rules: [rules].
Return: reference, issue, reported impact, rule-based priority,
missing evidence, next action, and proposed owner if specified.
Group possible duplicates without deleting references.
Do not infer an outage from one report or invent an SLA.
Put ambiguous cases in a review group.

Review a worked example

Illustrative reports include “The app is useless” and “All three people in our account cannot sign in.” The first needs context. The second contains a specific impact claim to investigate. Neither proves a platform-wide outage. Check that the list reflects evidence rather than intensity of language.

A duplicate group should not erase differences in impact. Two people reporting the same screen may have different account states or workarounds. Preserve those details for investigation. If an owner is not supplied by the routing rules, leave assignment pending instead of naming the person whose role sounds closest.

Use it again

Compare the triage with the support lead's decisions and refine unclear rules. A shared live queue requires account access, routing, and team authority beyond a personal text workflow. Explore Bot or contact Golub about that wider scope.