Project Intake: Turning "Can You Just..." Requests Into a Managed Queue

“Can you just pull a quick report for the board?” “Can you just add a column for the new region?” “Can you just…” Each request sounds like ten minutes. Together they consume your team’s week, and the work that was actually planned slides another sprint to the right.

Most teams track these requests in a spreadsheet, if they track them at all. Someone keeps a tab called “Requests”, half the rows say “in progress”, and the real queue lives in the team lead’s head. Here is how to replace that with something people can see and trust.

The real problem is invisible demand

Hallway requests are not the issue in themselves. Colleagues need things, and helping them is the job. The problem is that ad-hoc requests are invisible. Nobody can see how many there are, how long they take, or what got bumped to make room for them.

That invisibility hurts everyone. Requesters do not know whether their ask is being worked on. The team cannot push back because it has no evidence of its load. Leadership sees missed deadlines without seeing the 40 small favours that caused them.

A managed queue fixes visibility first. Prioritisation and speed follow.

One front door

Every request comes in through the same place. That usually means a short form that creates a record in your intake tool. Not an email, not a message in your chat tool, not a tap on the shoulder.

Keep the form short. Forms Are the Front Door: Designing Intake Forms That Get Complete Information goes deeper, but for intake you need roughly this:

• What do you need? One sentence, in plain words.
• Why? What decision or outcome does it support?
• By when, and what happens if it is late? This separates real deadlines from hopeful ones.
• Who else is affected?
• Size guess: quick (under an hour), small (under a day), or bigger.

The “what happens if it is late” question does more work than any other. “The board meets on the 14th” is a deadline. “Sooner is better” is not.

You will still get hallway requests. The response becomes a friendly script: “Happy to help. Pop it in the request form so it doesn’t get lost.” Say it every time, including to senior people, and within a month the form becomes the habit.

Triage rules, written down

Triage means deciding what a request is and where it goes, quickly, before anyone starts work. Do it on a schedule, such as twice a week, rather than whenever a request lands.

Write the rules down so triage does not depend on one person’s mood:

Every request ends triage with a status and a reason. “Declined: we already publish this report weekly, link here” is a far better experience than silence.

Exception Handling: Designing for the Cases That Don’t Fit is worth a read for the genuinely urgent cases, such as a regulator’s deadline or a system outage. Allow an “expedite” path, but make the requester state the reason, and review how often it is used. If half of all requests are urgent, none of them are.

Make prioritisation visible

Here is the part spreadsheets handle worst. Once requests are records with statuses, you can publish a live view of the queue in priority order, readable by anyone who submits a request.

Visible prioritisation changes conversations. When the sales director asks why their report is not done, you can show the list: “It’s fifth. Above it are the audit prep and three items for your own team. Want to swap one?” The trade-off becomes theirs to make, with full information, rather than yours to absorb.

Simple scoring helps when the list grows. Rate each request on impact (1 to 3) and urgency (1 to 3), multiply, and sort. It is crude, and that is fine. The point is a consistent, explainable order, not a perfect one.

Close the loop with requesters

Requesters stop using a queue if it feels like a black hole. Build in a few touchpoints:

• An automatic confirmation with the request ID when the form is submitted.
• A notification when the status changes: accepted, declined, in progress, done.
• A requester-facing view where they can see their own requests and where each sits.

Say your team of four handles 25 requests a month. If each one generates two or three “any update?” messages today, that is 50 to 75 interruptions you remove just by making status visible.

Measure the load, then use it

After a couple of months you will have something you never had before: real data on demand. Look at:

• Requests received per month, by team and by type.
• Time from submission to triage, and from triage to done.
• Share of requests that were “quick” versus bigger.
• Percentage declined, and the most common reasons.

This is the evidence that lets you have grown-up conversations. If one department generates 40 per cent of requests, maybe they need their own analyst. If most requests are for the same three reports, publish them as live dashboards and the requests stop. Service Levels for Internal Processes: Setting and Tracking Turnaround Times covers how to turn turnaround times into commitments.

Where to start this week

1. Build the five-question intake form and connect it to a simple list with statuses.
2. Back-fill the open requests currently living in inboxes and your chat tool, so the queue starts complete.
3. Write your triage rules on one page and book two short triage slots a week.
4. Share the queue view with everyone who asks you for things, and start using the “pop it in the form” script.