Demand intake and triage · lesson 2 of 5
Triage: urgent, important, or noise
In this lesson
- Apply a consistent triage routine to the incoming queue
- Separate genuine urgency from loud requesters
On a typical Monday your queue holds a dozen new requests. Two are genuinely urgent, several are important but not yet ready, and a few are speculative demand that may never convert. Triage is the discipline of telling them apart quickly and only once.
The two questions
For each request, ask: when does it actually start, and how likely is it to happen? Everything else is secondary at this stage.
Start date within two weeks and confirmed work: urgent lane, shortlist today. Start date beyond a month: important lane, schedule it for the weekly meeting. Attached to an unwon opportunity below your firm’s probability threshold: pipeline lane, visible for capacity planning but consuming no fulfilment effort yet.
Urgency versus volume
The loudest requester is rarely the most urgent request. A partner chasing daily about a role starting in six weeks is a communication problem; a quiet request starting Monday with no candidates attached is a resourcing problem. Triage on the fields, then manage the humans separately. If you find yourself reordering the queue because of who is chasing, the lane labels have stopped meaning anything and every requester learns to chase.
Labelling and moving on
ProFinda’s request statuses are your lanes. Set the status when you triage, add a one-line triage note (what you decided and why), and do not revisit the decision unless the facts change: the start date moves, the opportunity is won or lost, the scope shifts. A queue where requests bounce between statuses is a queue nobody trusts.
What noise looks like
Some requests are neither urgent nor important: duplicates raised by two people on the same engagement, placeholders with no dates “to get something in the system”, or fishing expeditions (“who do we have with pharma experience?”) dressed as requests. Duplicates get merged, placeholders go back to the requester with a note about what is missing, and fishing expeditions get redirected to search, which is the right tool for that question. Clearing noise is not admin; it is what keeps the queue readable for the requests that matter.
Key takeaways
- Triage on start date and win probability, not on who shouted
- Speculative demand belongs in the pipeline view, not the active queue
- A request triaged twice is a triage failure; decide once and label it