The 40-Second Intake That Breaks the Triage Queue
A 14-person customer success team collects onboarding requests through a form. The form has 22 fields, including a free-text 'Describe your request' box and a single-select 'Priority' with options Low/Medium/High. Submissions land in a project's default section, and a coordinator manually reads each one and moves it to one of four sections (Tier 1, Tier 2, Escalation, On Hold). Volume is 60 submissions per week. The coordinator spends roughly 40 seconds per request triaging, and 3 of the last 30 requests were misrouted - two Escalation items sat in Tier 1 for two days. The team wants to keep the free-text box but wants routing to happen without the coordinator. They also want to be able to see, six months later, why a given request was routed where it went.
1. The team proposes a single rule: 'If Priority is High, move to Escalation.' Evaluate this against the observed failure mode and propose a routing design that fixes the misroutes without removing the free-text field.
Read the worked answer
The proposed rule only handles one axis and reproduces the failure. The two Escalation items that sat in Tier 1 were presumably not marked High by the requester - requesters under-classify their own urgency, which is exactly why a coordinator was reading the free text. So priority-only routing inherits the requester's optimism.
A workable design separates classification from routing:
- Add structured fields that predict tier reliably (e.g., a single-select 'Request type' with a small, mutually exclusive option set, and a 'Contract tier' or 'Account value band' field). These are what rules can branch on.
- Keep the free-text box, but treat it as context for the human, not as a routing input.
- Build a small rule set that routes on combinations - e.g., Request type = Billing escalation OR (Request type = Access issue AND Contract tier = Enterprise) → Escalation. Multi-condition rules are what catch the cases a single priority flag misses.
- Leave a deliberate default: anything unmatched stays in Tier 1 with the coordinator notified, so unknowns are visible rather than silently misfiled.
The misroute symptom is a signal that the inputs to routing were too thin, not that the rule engine was wrong.
2. Address the audit requirement: six months later, the team must be able to explain why a specific request was routed where it was. What must be true of the design for that to be possible?
Read the worked answer
Routing decisions must leave a durable, per-task record. Three things have to be true:
- The rule inputs must be stored on the task, not just consumed. If a rule branches on 'Contract tier = Enterprise', that field must still hold its value (or its history) at review time. Free-text parsing that isn't persisted as a field leaves no trace.
- The routing action must be attributable. The task's story/history should show the section change and that it was made by automation rather than a person. If the team later edits or deletes the rule, the historical record of the move should survive - which argues for not relying solely on the current rule definition as the explanation.
- The rule set must be small and named legibly. A reviewer reconstructing 'why' needs to map the task's field values to a rule they can read. Ten overlapping rules with vague names make the audit a forensic exercise.
A practical addition: have the automation post a short comment on the task naming the rule that fired (e.g., 'Routed to Escalation by rule: Enterprise access issues'). That converts an inference into a recorded fact and survives rule edits.