The problem with running a shared services team that serves multiple business lines isn’t a shortage of project ideas. It’s that every stakeholder group believes their project is the most important one, most of the time. Without a structured intake process, the team ends up reactive: whoever is loudest or most senior gets their request picked up next, the backlog becomes a political negotiation, and delivery predictability collapses.
I’ve managed a roadmap of 140+ tracked initiatives across seven internal stakeholder groups — Sales, Operations, Marketing, Finance, Technology, Training, and Support. The quarterly intake process described here is what keeps that pipeline moving without every item becoming urgent and without the BA and BI teams spending half their time in prioritisation arguments instead of building things.
It’s not a sophisticated system. It’s a disciplined one. The value comes from running it consistently, not from optimising the methodology.
Why Intake Breaks Down Without Structure
Most shared services teams start with informal intake: someone sends a Slack message or raises a request in a meeting, it gets added to a list, and someone picks it up when capacity allows. This works when the team is small and the request volume is low. It breaks down quickly when you’re serving seven teams with competing priorities and a backlog that grows faster than it depletes.
The failure modes are predictable. Without a formal intake gate, every request arrives as high priority — because from the requester’s perspective it is. Without a scoring framework, prioritisation is determined by relationship and persistence rather than business value. Without a quarterly review cadence, the backlog becomes a graveyard of stale requests that nobody has formally declined but nobody is working on either.
“Without structured intake, you don’t have a backlog. You have a list of things people mentioned that nobody has said no to.”
The Four-Stage Intake Process
The Scoring Framework in Practice
The four scoring dimensions and what each level means:
| Dimension | 1 — Low | 3 — Medium | 5 — High |
|---|---|---|---|
| Business Impact | Nice to have; no clear metric improvement | Measurable improvement to one team’s efficiency or output | Revenue impact, retention risk, or cross-org efficiency gain |
| Strategic Alignment | Unrelated to current strategic priorities | Supports a secondary strategic objective | Directly enables a primary strategic objective or OKR |
| Complexity (inverse) | Multi-month, multiple integrations, new data sources | 4–8 weeks, known approach, existing data available | Under 2 weeks, clear requirements, no new integrations |
| Urgency | No time dependency; backlog is appropriate | Meaningful business event in next 1–2 quarters | Regulatory, contractual, or revenue deadline within 30 days |
A total score of 16–20 typically jumps to the next available sprint slot. 10–15 enters the normal quarterly review. Below 10 goes on the backlog with a documented reason. The framework isn’t perfect — there will always be edge cases where a low-scoring item needs to move up for political reasons you can’t always put in a spreadsheet — but it gives you an objective foundation for every prioritisation conversation and reduces the “why isn’t mine next?” calls significantly.
Managing the Seven-Group Dynamic
The hardest part of multi-stakeholder intake isn’t the process. It’s the politics. Seven teams competing for the same delivery resource will, without structure, default to influence and persistence as the primary allocation mechanism. Here’s what actually helps:
Publish the backlog. Make the full ranked backlog visible to all stakeholder groups, not just their own items. When Sales can see that their project is sitting behind three Operations requests that scored higher, the conversation shifts from “why isn’t my thing next” to “can I make a case that my score should be higher.” That’s a constructive conversation. It also prevents the perception that items are disappearing into a black box.
Separate the intake meeting from the delivery update. The quarterly review has two distinct halves and they should not blur together. The first half is a retrospective: what did we commit to last quarter, what did we deliver, what carried over and why. The second half is prospective: here is what we’re proposing for next quarter, here is the rationale. Blending them creates a situation where delivery failures contaminate the priority discussion.
Carryover is a data point, not a failure. Items that roll to the next quarter should be tracked explicitly and the reason documented. Carryover because of scope growth is different from carryover because of resource constraints, which is different from carryover because the business requirement changed. The delivery metrics I track include carryover rate as a leading indicator of capacity pressure — if more than 20% of committed items are rolling quarter to quarter, something structural needs to change.
What This Looks Like at 140+ Items
At full scale, the backlog has A-priority items in active sprints or committed for next quarter, B items queued for when A capacity opens up, and C items bundled into maintenance cycles. The quarterly review takes about 90 minutes with all seven stakeholder groups in the room. The preparation — scoring new items, updating existing scores for anything that’s changed, producing the delivery retrospective — takes about half a day.
That preparation investment is what makes the meeting productive. When every item has a score and every stakeholder has seen the backlog before the meeting, the 90 minutes is spent on the three or four genuinely contested prioritisation decisions — not on relitigating items that the framework already answered.
The core principle of effective backlog management applies here: the backlog is only useful if it reflects real capacity and real priority. A backlog that grows without constraint, where nothing is ever formally declined, isn’t a planning tool — it’s a list of promises nobody intends to keep. The quarterly intake process is what keeps it honest. For shared services teams dealing with similar multi-stakeholder dynamics, CXMaster.biz covers the leadership side of managing competing internal customers.
Related reading
- Blog: The BRD-to-Delivery Pipeline — measuring what the team actually produces
- Blog: Acceptance Criteria — the section most BRDs get wrong
- Process Improvement pillar — the full BRD methodology and delivery framework
- Case study: OLA Framework Design — internal SLAs that make intake commitments deliverable
- CXMaster.biz — managing competing internal customers in shared services