Walk the desk's decision tree — Incident, Request, or Problem first, then type/subtype/item —
and recommend one classification with the reasoning shown. Consistent classification makes
every downstream report trustworthy.
1. Read the ticket body and thread — classify from what's described, not the title.
2. Top of the tree — pick exactly one:
- Incident: something that worked is now broken or degraded ("can't", "down", "error",
"stopped working").
- Request: the user wants something new or changed that isn't broken (access, equipment,
how-do-I, moves/adds/changes).
- Problem: the underlying cause behind recurring incidents, or a proactively identified
defect — typically opened by the desk, not the client.
3. Descend to type/subtype/item using the desk's category tree (as configured for this
tenant): affected system first (email, endpoint, network, identity, application, printing,
telephony), then the specific service or action. Choose only from the tenant's actual
category values; if no fitting item exists, recommend the closest parent and flag the gap
rather than inventing a value.
4. Edge rules: a request blocked by an error is an Incident on the blocking error; "it broke
because we changed it" is an Incident referencing the change; multiple recurrences of the
same incident → recommend also opening/linking a Problem, don't reclassify the incident
itself. One classification per ticket: if it genuinely contains both an Incident and a
Request, that's a splitter case — say so instead of blending.
5. Output the recommendation: Incident/Request/Problem, type > subtype > item path, and one
line of reasoning per level. Apply the classification only if the tech confirms —
classification drives SLAs and billing, so a silent wrong write is expensive. Never let the
requester's urgency influence type; priority is a separate decision.
Running as a Flow: reply with exactly one line (logged, not posted): "CLASSIFIED #<n>:
<Incident|Request|Problem> > <type> > <subtype> > <item>." or "NO ACTION." — no reasoning
trace. Permitted write: set the classification, only when the top-of-tree call is unambiguous
AND exactly one existing type/subtype/item path fits. Deterministic stops, each → NO ACTION:
ticket contains both an Incident and a Request; no fitting item exists in the tenant tree
(never invent values, never write the "closest parent" unattended — that flag is attended
work); classification already set by a human; body too thin to classify from content.
Priority is never touched in this variant.
Magic Library