Request triage

What this problem is

Request triage is the work of taking an inbound customer message, deciding what it is, how urgent it is, and who should act — then passing it on with enough context that the next person does not start again.

Is this your problem?

• The same request arrives by email, phone, and chat and is treated as three jobs
• Priority is whoever shouts or whoever emailed last
• People re-investigate because the last handler did not leave notes
• Urgent issues sit next to password resets in one inbox
• Nobody can say median time to a useful first response

Current workflow

Requests arrive across a shared inbox, personal inboxes, a phone, and sometimes a portal. A coordinator or whoever is free opens the newest message, decides what it is, asks the customer for missing detail, then forwards it. Status lives in the email thread. When the thread is long, people skim and miss the actual ask.

Where it fails

• No shared definition of request types or severity
• Forwarding strips attachments or the original timestamp
• VIP or safety issues use the same queue as routine questions
• The help desk or CRM is updated after the work, so reporting lies
• Out-of-hours coverage is informal, so mornings start with a pile

How to measure the baseline

For two weeks, tag every inbound request with type, channel, arrival time, first useful response, and resolution or handoff. Count duplicates and reopened tickets. Use cases_per_week, lead_response_minutes or resolution_minutes, minutes_per_case, rework_hours_per_week, and exception_rate_pct. Observed timestamps beat recollection.

Metrics that matter

• Cases per week — Volume of discrete items (leads, invoices, tickets) in a typical week. (cases/week)
• Resolution time — Minutes from intake to the case being closed or handed off as complete. (minutes)
• Minutes per case — Average handling time from pickup to completion of one case. (minutes)
• Rework hours per week — Time spent correcting errors or re-doing work in a typical week. (hours/week)
• Exception rate — Share of cases routed to human exception handling. (%)

Root causes

• The team never agreed what “urgent” means
• Tools are inboxes, not a queue with types
• Knowledge lives in senior staff, so junior triage guesses
• There is no exception path, so everything is a special case
• Success is “inbox zero”, not time-to-useful-response

What should be automated

• One intake that creates a case regardless of channel
• Suggested classification and priority from the message and customer record
• Routing to a queue or named owner using written rules
• A first acknowledgement that does not pretend the issue is solved
• Surface of existing open cases to reduce duplicates

What should remain human-controlled

• Safety, legal, complaints, and anything that could harm a person or the relationship
• Priority overrides when the customer context is not in the system
• The actual diagnosis and the reply that commits the business
• Changing categories and SLAs when the service catalogue changes

Example intervention architecture

Illustrative only — not a client result. Channels write to one case store. Classification suggests a type and severity with a confidence score. Above a threshold, the case joins the right queue; below it, a human triages. Acknowledgements can be automatic. Responses that change commercial or safety outcomes require a named person. The original message remains attached.

Failure modes

• A bot replies with a wrong resolution and the customer stops writing
• Everything is tagged “other”, so the queue is worse than email
• Priority rules that hide quiet-but-serious issues
• Staff bypass the queue because it is slower than tapping reply
• Personal data from the wrong customer attached to the case

When not to automate

• Volume is low and one experienced person already triages well
• Request types change weekly and cannot be listed
• There is no customer record to route against
• Most work is genuinely unique professional judgement, not repeating categories
• The organisation will not adopt a queue — people will stay in private inboxes

Sources

• ICO guidance for organisations (UK data protection)
• Service standard (GOV.UK)