Triage that follows written criteria, shows its reasoning and leaves the decision with a named person.
Problem
Requests, applications and inbound opportunities arrive in more than one channel and are sorted by whoever sees them first. The criteria live in people's heads, so two people route the same request differently and nobody can say afterwards why an item went where it did.
The cost is delay at the front of every process that depends on intake, and uneven treatment of items that should have been handled the same way. Where the items are job applications or investment opportunities, uneven treatment is also a governance exposure.
Typical applications: request routing, candidate screening and deal intake.
Shape
The steps below are platform-neutral. A platform page shows which vendor capability carries each one.
- Capture every inbound item in one place, whatever channel it arrived through.
- Extract the fields the routing criteria depend on.
- Score or categorize the item against criteria the owning team has written down.
- Route it to a named owner or queue, with the reason recorded on the item.
- Apply the service level that matches its category and priority.
- Send anything the criteria do not cover, and anything below a confidence threshold, to a person.
Control set
The control set is part of the design, not a follow-up. Each control is agreed with the process owner before the build starts.
| Control | How it is met |
|---|---|
| Review | A named owner reviews routed items on a set cadence. Where the item concerns a person, such as a job application, a human makes the decision at every gate and the workflow only prepares it. |
| Data | The workflow reads the inbound item and the written criteria. Sensitive fields are listed before the build and excluded unless the owner approves their use. |
| Monitoring | Volume, category mix, reroute rate and time to first owner are tracked on a dashboard the team can see. |
| Off switch | Routing can be disabled per category. Items then fall back to a single manual queue, with nothing lost. |
| Correction | A rerouted item records who moved it and why. Reroutes are reviewed and the criteria are updated, not the individual item alone. |
Measures
Reference design. This pattern has not yet produced measured results in a C9D Consulting engagement. The targets below are examples of the shape, not results and not promises. Real targets come from the baseline measured in the diagnostic.
| Baseline | Metric | Example target |
|---|---|---|
| Time from arrival to first owner | Median time to first owner | Same working day for standard requests |
| Share of items rerouted by a person | Reroute rate | Falling over the first quarter of use |
| Items with no recorded reason for their route | Unexplained routes | None |
Handoff
At the end, the client team owns:
- The written routing criteria and the playbook for changing them
- A named owner for each category and queue
- A runbook covering the off switch, the fallback queue and the review cadence
- Trained champions who can add a category without outside help
Where it applies
| Platform | Application |
|---|---|
| monday.com | AI Enablement on monday.com |
A platform that is not listed has no published application yet. The pattern itself does not depend on any one vendor.
Engagement
This pattern is not sold on its own. It is delivered through the engagement shapes in the Engagement Specification.
- E-01 Decision Advisory. Settles whether this pattern is the right first move, on which process and on which platform. It starts with a diagnostic and ends with the playbook handoff.
- D-01 Delivery Engagement. Where the client wants the workflow built, the build ends with working software and its playbook.
Read the Engagement Specification, or request a conversation.