Intake is a designed system, not an inbox

How work enters a team decides how the team runs. A web team can have a beautiful roadmap and still be reactive if requests arrive through side channels, get accepted informally, and jump the line based on who asked. Intake is not administration; it is the control surface for the whole operating model.

One front door. Every request enters through the same structured channel with the same required fields: the requesting team, the business goal, the metric the work is expected to move, the deadline, and the dependencies. The form is the first prioritization filter, because a request that cannot name its goal is not yet ready to be work.

Rank with one model, applied in the open. Score every request the same way and publish the ranking. The specific scoring model matters less than its consistency: a defensible ranking everyone can see beats a clever one applied behind closed doors, because the visible version ends relitigation.

Separate the two kinds of work at the door. A page composed from existing components and a new integration are different work with different costs, and they should never share a queue. Routing them separately means a quick page change never waits behind a platform project. This is also where a governed component library pays for itself: the more work qualifies as self-serve, the less competes for engineering capacity.

Reserve capacity for the genuinely urgent. A standing carve-out for fast-turn requests, with a clear bar for what qualifies, protects the roadmap from death by exception. When urgency is a defined lane instead of a negotiation, stakeholders stop needing to inflate their requests to get attention.

Close the loop with requesters. Intake earns trust when every requester can see where their item landed and why. Most stakeholders can accept not being first; what they cannot accept is silence.