Inbound requests classified, routed, and prepared before anyone opens them.

A support and sales operation receives inbound requests through three channels: a web form, a shared inbox, and a partner referral queue. Volume is uneven, arriving in bursts, and every request has to be read by a person before it can be sent anywhere.

Reading is the bottleneck. Routing is mostly mechanical once the request is understood, but understanding it means finding out who the company is, what they already use, and whether they have contacted the business before. That takes minutes per request, and there are hundreds a week.

A team in this position is not slow because it lacks people. It is slow because the first useful action on any request requires research nobody has budgeted for, so requests sit until someone has a clear hour, and a clear hour is rare.

The visible symptom is response time. The expensive symptom is misrouting: a request that looks like a support question but is actually a procurement enquiry goes to the wrong queue, waits, and gets answered by somebody who cannot help. Everyone downstream absorbs the cost of the first misread.

Hiring for the reading is the other option. It is expensive, hard to keep staffed, and produces people whose entire job is triage. It also does not scale in bursts, which is exactly when the queue matters.

The workflow contains eleven decisions. Most of them are research steps. Two of them are consequential, and those two are the reason a rules engine failed. What kind of request is this? Who should own it, and what do they need to know before they answer?

Classification and routing are high-judgment and low-stakes: getting them wrong costs an internal hop, not a customer. That combination makes them good candidates for independent operation, provided the coworker records the reason for each decision so a person can disagree with it. The first reply to the customer is different — low judgment, high stakes, and impossible to retract — so it stays in a person’s hands regardless of how good the draft is.

The coworker would read each incoming request, research the company across the sources agreed in discovery, classify the request against the categories the team already uses, and route it to the right owner with the context assembled into a short brief. Where its confidence falls below the agreed threshold it does not guess: it escalates with a prepared summary of what it found and what it could not determine.

Everything appears in the tools the team already works in. The request lands in the same queue, with the brief attached and the owner already set. Nobody logs into anything new. Before replying, the owner reads a brief explaining why it was routed to them — who this company is, what they already use, whether they have been in contact before, and which parts of that the coworker was unsure about.

Requests would arrive already understood. The owner opens a request that has been researched, categorised, and routed, and their first action is answering rather than reading. Bursts stop being a problem, because reading no longer competes for the same hour.

Escalation volume is the number we watch first. A coworker that never escalates is either working perfectly or hiding something, and it is usually the second. Repeat escalations of the same shape tell us a category is missing or a threshold is wrong, and that is a change to the decision map rather than a bug.

Beyond that: source formats change, new request types appear when the business launches something, and confidence thresholds need adjusting as the team’s tolerance shifts. All of it is part of the monthly service.