In short
Work that can enter from any channel cannot be counted, prioritised or planned, which is why teams feel overloaded without being able to demonstrate it. Establish one front door per work type, capture the same few fields on every request regardless of who is asking, and make acceptance an explicit decision rather than a default. The point is not bureaucracy: it is that a request nobody recorded is a commitment nobody can see, and a business cannot say no to work it has never counted.
Key takeaways
- If work can arrive anywhere, the total is invisible and overload cannot be evidenced.
- One front door per work type. Multiple channels are acceptable only if they all land in one queue.
- Capture the same fields every time, including who asked and by when they need it.
- Acceptance must be an explicit yes, with a date. Silence is currently being read as agreement.
- Intake is where a capacity conversation is cheap. Every later point is more expensive and more personal.
The problem with a business that has nine front doors
Ask a team whether they are overloaded and the answer is yes. Ask them to show you the total and they cannot, because work arrived through the shared inbox, three direct messages, a corridor conversation, a comment on a document, a client call, and a decision made in a meeting that nobody wrote down.
Every one of those is a commitment. None of them is countable. The consequences are specific:
- Overload cannot be evidenced. The team feels swamped and can produce no list, so the conversation becomes about resilience rather than about arithmetic.
- Prioritisation is impossible. You cannot rank a set you cannot see, so the effective priority order is whoever asked most recently or most loudly.
- Capacity planning is guesswork. Committed work is unknown, so any plan is built on the portion that happens to be written down.
- Nothing can be declined. Saying no requires showing what it would displace, and that requires a list.
A business cannot decline work it has never counted. Every request looks small on its own, and the total exists nowhere.
One front door, several letterboxes
The instinctive fix is to forbid informal requests. It never works, because informal asking is how organisations actually function, and a rule that fights that will be broken within a fortnight by whoever is most senior.
The workable version separates how people ask from where work is recorded. People may ask anywhere. Whoever receives the request is responsible for putting it in the single queue before it is treated as accepted.
| Rule | What it achieves |
|---|---|
| One queue per work type, visible to everyone involved | The total becomes countable for the first time |
| Asking is allowed anywhere; recording is not optional | Removes the compliance fight while keeping the visibility |
| Whoever is asked does the recording | Places the small cost on the person who has the information |
| Nothing is worked on before it is in the queue | The queue stays a true picture rather than a partial one |
Per work type matters. Client delivery, internal projects and support requests have different rhythms and different deciders, and forcing them into one queue produces a list nobody can act on. Two or three queues is normal; nine channels feeding no queue is the problem.
If your current de facto queue is a shared mailbox, the ownership rules in your shared inbox is a work queue are the prerequisite, because an unowned queue records requests without progressing them.
The five fields worth insisting on
Intake forms fail in one of two directions: too long, so people avoid them and ask informally instead, or too short, so the request has to be reconstructed by conversation later. Five fields is the useful middle.
- Who is asking. Not the department. The person who can answer questions and confirm it is done.
- What outcome is needed. The result, not the task. People frequently ask for a solution they have already chosen, and stating the outcome sometimes reveals a cheaper one.
- When, and why that date. The reason is the important half. “Friday” is a preference; “Friday, because the client board meets Monday” is a constraint, and the two should be treated differently.
- What happens if it is not done. The single most effective field for separating real urgency from habitual urgency, and it is answered honestly more often than you would expect.
- What it depends on. What has to arrive from the requester before work can begin. Missing inputs are the largest cause of rework, and this field is where they are cheapest to catch.
Fields, consistently captured, is worth more than a thorough form nobody completes. Every additional field increases the chance the request bypasses intake entirely, which returns you to a business with nine front doors.
Acceptance is a decision, not a default
The step almost universally missing is the explicit yes. Requests arrive, nobody declines them, and the requester reasonably concludes the work will happen. The business has now committed to something nobody decided.
Acceptance needs three properties:
- A named decider per queue, with a stated window for responding, in the same way approvals need a clock and an owner, as covered in why decisions sit in inboxes for a week.
- A date attached. Accepting without a date is not accepting; it is deferring the disappointment.
- A visible trade when capacity is full. Not a refusal. “We can start this in three weeks, or start it now in place of X. Which?”
That third form is what makes intake politically survivable. It hands the sequencing decision back to the person requesting, rather than putting the team in the position of saying no, and it makes the cost of a new request visible at the only moment when discussing it is cheap. Later, the same conversation happens as a missed deadline and it is considerably more personal.
- Implicit acceptance
- A request treated as agreed because nobody declined it. It is the mechanism by which businesses commit to more work than they have capacity for without any single person having made a decision, and it is invisible until delivery dates start moving.
Handling the genuinely urgent
Every intake process is tested by something that genuinely cannot wait. A process with no route for that will be bypassed, and once bypassing is normal the queue stops being a true picture.
So design the bypass rather than pretending it will not happen:
- Define what qualifies, narrowly and in writing. Client outage, regulatory deadline, contractual penalty. Not “the client is annoyed.”
- Name who can invoke it. A short list. Unrestricted urgency is a queue ordered by confidence.
- Record it afterwards anyway, including what it displaced. This is the part that matters.
- Review the count monthly. If a third of work arrives as urgent, urgency is not an exception, it is your process, and it should be designed for rather than tolerated.
That last measure is one of the more revealing numbers a small business can produce. A high and stable expedite rate usually means committed dates are being set without reference to capacity, which is a planning failure appearing as a discipline failure.
What intake data tells you within a month
Four weeks of consistent capture answers questions that were previously matters of opinion.
| Question | What the data shows |
|---|---|
| How much work actually arrives? | The rate, and whether it is steady or spiky. Both change the capacity answer |
| Where does it come from? | Usually concentrated in one or two sources, which makes the conversation specific |
| How much is genuinely urgent? | Almost always a smaller share than the felt experience suggests |
| How much never gets done? | The abandoned tail, which is a list of things the business agreed to and quietly did not do |
That last row tends to be the uncomfortable one, and it is the strongest argument for intake existing. Requests that were implicitly accepted and never delivered do damage twice: the work does not happen, and the requester has spent weeks assuming it would. Counting them is the first step to either doing them or declining them honestly, which is the same choice described in too many priorities.
The Mayim Ops assessment examines how work enters the business alongside how it moves through it, because a business that cannot see its committed total will keep solving a capacity problem it cannot measure.
Frequently asked questions
What is a work intake process?
A defined route by which requests enter the business, with a consistent set of information captured for each one and an explicit decision about whether and when it will be done. Its purpose is to make total committed work visible, which is impossible when requests arrive through several unrecorded channels.
How do you stop work arriving from everywhere?
Do not block the channels; converge them. People can still ask in a message or a corridor, but the person receiving the request records it in the single queue before it is treated as accepted. Trying to forbid informal requests fails, because informal asking is how organisations work.
What information should an intake form capture?
Who is asking, what outcome they need, when they need it and why that date, what happens if it is not done, and what it depends on. Five fields is enough. Longer forms suppress requests rather than improving them, which hides demand instead of managing it.
Who should decide whether to accept new work?
One named person per work type, with a stated response window. Acceptance decided collectively drifts, and acceptance decided by whoever is asked first produces commitments the business cannot see. The decision should include a date, because accepting without a date is not accepting.
Does an intake process slow things down?
It slows down the act of asking and speeds up delivery, because the alternative is a business running more concurrent work than it has capacity for, in which everything takes longer. Where intake genuinely creates delay, it is usually because acceptance has no owner or no response window rather than because the process exists.