A team has twelve active projects, a full improvement backlog and several deadlines already at risk. Then another request arrives marked “urgent”.
It sounds important. A senior stakeholder is asking. The email mentions a meeting next week. Nobody wants to appear unhelpful, so the team starts immediately.
Two days later, a genuinely time-critical request appears. Work stops again. The original task joins several half-finished items, while the team spends more time switching priorities than delivering them.
The problem is not a lack of effort. It is the absence of a shared intake and prioritisation system.
Why this matters
When work arrives through emails, meetings, chat messages and corridor conversations, the queue becomes invisible. The loudest requester can receive attention before the most valuable work. People accept more than the team can finish because every request is assessed on its own rather than against existing commitments.
This creates predictable problems:
- Important work starts late
- Staff carry too many tasks at once
- Requesters receive inconsistent answers
- Teams cannot explain why one item moved ahead of another
- “Urgent” becomes a way to bypass normal planning
- Low-value work survives because nobody clearly declines it
Good prioritisation is not about finding a perfect formula. It is about making trade-offs visible and repeatable.
The GOV.UK Service Manual recommends making priority decisions regularly, using a clear method and drawing on performance information, user research and stakeholder input. The Australian Government’s Digital Service Standard begins with clear intent: define the user problem, expected outcome, risks and strategic context before jumping to a solution.
Those principles work for everyday workplace requests too. A team should understand the problem and compare it with other work before promising delivery.
What a work-intake system does
A work-intake system is a simple front door for new requests. It collects enough information to decide whether the work should be accepted, clarified, deferred, redirected or declined.
It has four parts:
- One visible place for requests
- A small set of required information
- Agreed prioritisation criteria
- A regular decision meeting with clear authority
This does not require expensive software. A form feeding a spreadsheet or shared board can be enough. The discipline matters more than the tool.
Step 1: Create one front door
Choose one place where normal work requests enter the team. It might be a Microsoft Form, a service portal, a shared list or a structured email template.
The rule is: if a request is not in the intake list, it has not entered the queue.
Define a separate path for genuine incidents or emergencies. An operational outage, safety issue or legal deadline should not wait for the weekly backlog meeting. However, “a senior person asked” or “we would like it before our meeting” is not automatically an emergency.
Step 2: Ask for seven useful pieces of information
Keep the form short enough that people will use it. Ask for:
- Problem: What is happening now?
- Outcome: What would be better if this work succeeded?
- Users: Who is affected and how?
- Timing: When is it needed, and why that date?
- Consequence: What happens if it is delayed or not done?
- Effort: What is the rough size or complexity?
- Owner: Who can clarify the need and accept the result?
Do not begin with “What solution do you want?” A request for a dashboard, automation or new field may hide a different problem. The Digital Service Standard advises teams to frame the problem and avoid committing to a technical solution before validating it.
Step 3: Separate importance from urgency
Urgency asks: how soon must action occur?
Importance asks: how much does the work contribute to a meaningful outcome?
A request can be urgent but low impact, such as changing presentation formatting before a meeting. Another can be important but not immediately urgent, such as removing a recurring source of errors before volumes increase.
Use four simple criteria:
- Impact: How strongly will this improve an agreed outcome for users, staff or the organisation?
- Urgency: Is there a real time constraint, and what creates it?
- Obligation or risk: Is the work required for safety, law, policy, audit, security or service continuity?
- Effort and readiness: How much capacity is needed, and are the information, decisions and dependencies ready?
Step 4: Use priority bands, not fake precision
A score of 73 versus 71 can look scientific while hiding weak assumptions. For most team-level intake, four bands are easier to understand:
- Expedite: Immediate action is justified by a serious incident, fixed obligation or material risk.
- Next: High-value, time-sensitive work that fits available capacity.
- Planned: Valuable work to schedule when current commitments allow.
- Park, redirect or decline: Weak outcome, insufficient information, low relevance or work owned elsewhere.
If too many requests land in “Next”, compare them directly. Ask which delay would cause the greater harm, which delivers the stronger outcome and what currently committed work must move.
Step 5: Run a 30-minute weekly triage
Bring together the intake owner, someone who understands team capacity and the accountable decision-maker. Invite specialists only when their knowledge is needed.
Use a short agenda:
- Review new requests for completeness
- Separate emergencies and mandatory work
- Compare remaining requests against the criteria
- Confirm available capacity and current commitments
- Accept, clarify, defer, redirect or decline each request
- Record the reason, owner and next review date
- Communicate the decision
Step 6: Make capacity visible
A ranked backlog is not a commitment to complete everything. It is an ordered set of choices.
Show how much work the team can realistically carry. This might be a limit on active initiatives, available staff-days per fortnight or a simple “not started, active, blocked, done” board with a work-in-progress limit.
Reserve some capacity for unplanned work if the team regularly supports operations. The exact allowance should reflect evidence from previous weeks, not a generic percentage.
When a new high-priority request arrives, show the displacement explicitly: “We can start this on Monday if Request B moves to next month.” That turns a hidden overload into a governance decision.
Step 7: Use AI as an assistant, not the decision-maker
AI can help summarise long submissions, identify missing information, group similar requests or draft a comparison table. It can also help turn vague language into questions for the requester.
It should not make the final priority decision. Intake data may be incomplete, and the trade-off can involve public impact, workforce consequences, privacy, safety or policy obligations. Accountability remains with the authorised people.
If AI is used, do not enter sensitive or restricted information into an unapproved tool. Review summaries against the original request and record the human decision and rationale.
A realistic fictional example
A service-improvement team receives four requests in one week:
- Add new colours to an executive dashboard before a presentation
- Correct a form problem causing repeated incomplete submissions
- Prepare evidence for a fixed external assurance deadline
- Build an AI summary tool suggested during a workshop
Previously, each requester called their work urgent.
Under the new intake system, the assurance request is expedited because the deadline and consequence are fixed. The form correction is placed next because it affects many users, creates daily rework and is ready to implement. The dashboard change is planned only if small capacity remains. The AI idea is parked for discovery because the user problem, data access and governance requirements are not yet clear.
The system did not say the lower-ranked ideas were bad. It made the reasons and trade-offs visible.
Common mistakes and risks
- Letting requesters assign final priority. They provide evidence; the accountable team compares the work.
- Creating a long form. Collect only information that changes the decision.
- Using one queue for incidents and improvements. Define an emergency route with narrow criteria.
- Scoring without checking capacity. Ranking work does not create more people or time.
- Treating seniority as the main criterion. Escalation may signal importance, but it does not replace evidence.
- Never removing old requests. Review the backlog and close items that are obsolete, duplicated or no longer valuable.
- Hiding declined work. Record and communicate why it will not proceed.
- Letting AI infer missing facts. Use it to identify questions, not invent evidence.
Try This This Week
- Choose one place for all normal work requests.
- Create a short intake form using the seven fields above.
- Define your emergency route and what qualifies for it.
- Agree on impact, urgency, obligation and effort as the comparison criteria.
- Set the four priority bands.
- Book a 30-minute weekly triage with a named decision-maker.
- Review current work before accepting anything new.
- Tell requesters when and how they will receive a decision.
Key takeaway
A useful intake system does not eliminate difficult choices. It makes them honest.
When requests enter through one place, carry decision-ready information and are compared against outcomes and capacity, teams can stop treating every interruption as a new top priority.
The most useful question is not “How quickly can we start this?” It is “Compared with what we have already promised, why should this come next?”
Connect with Raf on LinkedIn for practical ideas on project delivery, responsible workplace AI and continuous improvement. Read more at rafsanga.com.
AI tools assisted with research and drafting. The final article was reviewed and approved by the author.
Comments
Post a Comment