Glossary
What is work intake?
Work intake is the point where work requests enter an organisation, and the bar a request must clear there to become decidable: what needs to change, plus who is affected or why it matters now.
Intake collects; it does not decide — deciding is demand management. The common failure is over-building the door: category pickers, priority fields and sizing questions ask the requester to answer things that belong to a later stage, at the exact moment their patience is shortest. Two required questions and visible movement afterwards beat a twelve-field form.
The work intake process in four steps
A work intake process (some organisations call it project intake) has four steps, and none of them is a meeting. The first two are intake itself; the last two are what makes the door worth using.
The first is one door. Every request is entered at the same place, whatever channel it was first spoken in: requests will keep arriving by chat, by email and in the corridor, and whoever receives one enters it. That is the moment it starts to exist on the record. Without a single door there is a shadow queue — some requests in a tracker, some in a spreadsheet, some only in a senior engineer's memory — and every prioritisation is built on a partial list.
The second is two questions. A request enters when it says what needs to change, and either who is affected or why it matters now. The first cannot be missing: impact and urgency attached to no stated need is pressure with nothing to decide. A request below the bar is not rejected. It goes back the same day with the one question that would clear it, while the requester still has the context.
The third is triage with four recorded exits, and it is where intake hands over to deciding. Someone with the authority to refuse decides what happens next, and every request leaves the step with one of four answers on the record: plan it, run a time-boxed discovery, park it with a review date, or decline it with a reason the requester can read. A weekly meeting that re-orders the queue and hands out priority labels is sorting, not triage, and a sorted item comes back the following week.
The fourth is visible movement. The requester can see where the request stands — arrived, being shaped, parked until a named date and why — without asking anyone. A requester who sees nothing chases, or escalates, because escalation is the only lever that visibly works on a black box. Visibility also keeps a wait honest. A request held up by one unanswered question is not merely old: it is waiting on that question, and the record shows who was asked and when to follow up.
What to ask at intake — and what to leave for later
Ask two things: what needs to change, and either who is affected or what happens if nothing is done. That is the minimum a request needs to be decidable, and it is answerable by someone who does not work in delivery. Everything else — team, priority, size, category, target date — is either a guess the requester cannot make or a decision that belongs to the people who will do the work.
A request that arrives as a bare topic (SSO, reporting, onboarding) is not a small request, it is not a request yet. Holding the bar at the door costs the requester one sentence; recovering the missing sentence three weeks later costs a meeting.
Why the intake form is the wrong place to be thorough
Every extra field is charged at the moment of least patience, to the person with the least context, in exchange for a benefit that accrues to somebody else. Long forms do not produce better requests; they produce fewer requests through the front door and more through the side channel — a DM, a corridor, a meeting — which is where the untracked commitments come from.
The right generosity is on the other side of the door: reply, shape it with the requester, and show them the decision when it is made. A short form followed by visible movement earns more usable input than a thorough form followed by silence.
Related terms
- Triage
Request triage is the decision about what happens next to each incoming request, with four recorded exits: plan it, run a time-boxed discovery, park it with a review date, or decline it with a reason.
- Backlog bankruptcy
Backlog bankruptcy is the deliberate closure of an oversized backlog by finally making the decisions it contains — each item leaving as a recorded decline with a reason, a park with a review date, or a survivor someone will still argue for out loud.
- Shaping
Shaping turns a raw request into something decidable: the problem stated apart from the proposed solution, the intended outcome, what is known versus assumed versus unknown, and a likely owner.
This definition comes from building DeliverySheet — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date.
$189/month per workspace, unlimited members. 7-day free trial — card required, cancel before it ends and you're not charged. I answer the support email myself.