Classifying support requests
A bounded classifier can suggest routing while exceptions remain reviewable. Expected disposition: Proceed with controls.
Task boundary
Classifying support requests is assessed as a specific task and workflow, not as a general endorsement of AI for the surrounding job. A bounded classifier can suggest routing while exceptions remain reviewable.
Assumptions
- The output suggests one label from a documented routing taxonomy.
- Misrouting delays service but does not itself decide safety, eligibility, refunds, or account sanctions.
- Low-confidence and sensitive cases can enter a staffed exception queue.
Decision
- Disposition: Proceed with controls
- Pattern: Tool workflow
- Inherent risk: medium
Rules that drive the decision
- Repeated classification at volume favors a bounded tool workflow with a fixed schema.
- Because classification changes routing, the workflow needs fallback and monitoring rather than free-form generation.
Why alternatives were rejected
- A free-form prompt is inconsistent at volume.
- An agent is broader than the task.
Controls
- Validate labels against the allow-list and prevent the classifier from closing or replying to tickets.
- Route unknown, multi-intent, and sensitive requests to human triage.
- Monitor error rates separately for each label instead of relying on aggregate accuracy.
Acceptance threshold
These are example starting thresholds for a bounded pilot of this workflow, not universal benchmarks. For classifying support requests, the accountable owner should make them stricter when the task, consequence, or policy requires it.
- A representative set reaches at least the owner-defined per-label precision and recall, with no safety-critical ticket bypassing human triage.
- All out-of-taxonomy and low-confidence examples reach the exception queue.
Reassess when
- A label begins triggering refunds, sanctions, emergency advice, or account changes.
- The taxonomy, customer population, or supported languages materially change.