Reporting request intake: stop building dashboards nobody owns
A dashboard request is not yet a project. Before committing analytics capacity, turn “Can you build me a report?” into a decision, an accountable owner and a testable outcome.
28 September 2026 · For UK finance, operations and analytics leaders
A reporting demand queue
Gate: every scheduled item has a decision owner and acceptance measure.
Review rhythm: weekly triage · monthly portfolio review.
The request is usually a symptom, not the requirement
“I need a dashboard by Friday” can mean the current report is slow, definitions are disputed, a customer meeting is approaching or somebody cannot access an existing answer.
If the team accepts the requested output before understanding the decision, it inherits hidden scope. New measures appear during testing. Nobody knows who can approve definitions. The source data turns out to be late or manually corrected. After release, the requestor likes the dashboard but no operational meeting actually uses it.
Capture a decision contract before a specification
A useful intake record is short enough to complete, but strong enough to expose missing ownership and evidence.
Decision and action
Ask what decision will change, which action follows and how often it occurs. Record the current workaround and what becomes difficult when the answer is late or wrong.
Owner and audience
Name one business owner who can approve definitions and acceptance. Identify the users, their locations, access constraints and the person who will support adoption.
Evidence and timing
Link the current report or manual file, candidate sources and sample outputs. Separate a genuine business deadline from a preferred date, and state the consequence of missing it.
Microsoft’s BI solution-planning guidance recommends involving the right stakeholders, defining the problem collaboratively, clarifying scope and documenting business metrics and attributes.
Use one intake record for the whole conversation
Keep the request, decisions and evidence together. Avoid a form submission that immediately becomes disconnected email and meeting notes.
| Field | What good looks like | Why it matters |
|---|---|---|
| Request title | A business problem, not a proposed visual. | Keeps discovery open to reuse, process change or an existing solution. |
| Decision and action | “Approve overtime by site each Monday” rather than “weekly dashboard”. | Makes the outcome and cadence testable. |
| Business owner | One named person with authority to approve meaning and acceptance. | Prevents design by committee and abandoned content. |
| Audience and scope | Roles, sites, approximate users and data sensitivity. | Influences delivery, security, support and governance. |
| Definitions | Known measures, filters, grain and unresolved disagreements. | Surfaces semantic work before visual development. |
| Sources and evidence | System owners, sample records, existing files and known quality issues. | Separates an idea from a feasible delivery candidate. |
| Deadline and consequence | A real event, obligation or decision date plus the impact of delay. | Stops every request being labelled urgent. |
| Acceptance measure | A task completed, reconciliation passed or cycle time improved. | Defines success beyond “the report is published”. |
| Route and next action | Named route, responsible person and review date. | Gives the requestor a visible answer even when work is deferred. |
Route the need before ranking the build
The right outcome is not always a new Power BI report. Triage should choose the smallest responsible response to the need.
Send it back with the exact question that must be answered. Keep its place and history in the register.
Time-box a conversation and data check. Produce a decision contract, not a hidden mini-project.
Confirm definitions and access, then guide users to the approved content. Record what was reused.
Provide governed data, a template or coaching. State who owns the result and its support boundary.
Move it into solution planning with scope, stakeholders, owner, acceptance and an initial delivery approach.
Record the reason, evidence needed to reconsider and a review date where appropriate.
Score priority only after the gates pass
A score helps compare qualified candidates. It should structure judgement, not replace it.
| Factor | 0 points | 1 point | 2 points | 3 points |
|---|---|---|---|---|
| Decision impact | No decision identified | Convenience or local visibility | Material team or departmental decision | Strategic, customer, financial or safety decision |
| Deadline or risk | No consequence stated | Time-sensitive improvement | Documented obligation or material risk | Not used |
| Audience and reuse | One-off personal use | Repeat use by one team | Reusable across teams or decisions | Not used |
| Data readiness | Unknown source or unresolved ownership | Source exists with known gaps | Accessible source, owner and sample evidence | Not used |
| Delivery confidence | Large unknowns or dependency | Moderate discovery still required | Bounded scope and plausible route | Not used |
Two non-negotiable gates: a named business owner and a defined decision/action. If either is absent, the request returns to clarification regardless of its score.
Illustrative interpretation: 9–11 is a strong scheduling candidate; 6–8 needs comparison or bounded discovery; 0–5 is returned, routed elsewhere or parked. Capacity, dependencies and portfolio balance can still change the decision. Publish the reasoning with the score.
Govern the queue without creating a bureaucracy
Use controls in proportion to audience, sensitivity and decision criticality. A team tracker and an enterprise finance model should not face identical oversight.
Separate business and delivery ownership
The business owner approves definitions, priority and acceptance. The delivery owner manages discovery, design and release. The source owner confirms access, meaning and known quality limitations.
One person can hold more than one role, but the responsibilities must remain visible.
Protect the service boundary
State what enters the queue: new reports, material changes, data extracts, access requests or source-quality work. Give small support requests a faster route so triage does not become a bottleneck.
Set a service target for the next decision, not an unrealistic delivery date for every submission.
Make exceptions inspectable
Executives may legitimately override priority, but record who decided, what moved and why. Otherwise the published model loses credibility and urgent work silently displaces committed value.
Review ageing requests and recurring exception patterns with the portfolio sponsor.
Microsoft notes that governance varies with ownership, delivery scope, sensitivity and importance to critical decisions. Its adoption roadmap also distinguishes business-led self-service, managed self-service and enterprise ownership rather than prescribing one model for everything. See content ownership and management.
Implement a lightweight Microsoft 365 front door
The process should work before you automate it. Start with a shared register, disciplined views and one accountable triage meeting.
Microsoft Lists for the record
Create structured columns for the intake fields, status, route, owner, score, next action and review date. Use views such as New, Waiting for requestor, Discovery, Ready to schedule and Ageing.
Keep evidence as governed links or attachments and control who can see sensitive requests.
Teams for the conversation
Pin the register and operating guidance in the analytics or improvement channel. Discuss the item, but write the decision and next action back to the record so the queue remains authoritative.
Publish triage dates, entry criteria and the route for urgent incidents.
Automation only for real hand-offs
A List rule can notify somebody when an item changes. Use Power Automate when the process genuinely needs multi-service notifications, reminders, approvals or escalation.
Give flows an owner, failure monitoring and a recovery route. Avoid automating an unclear status model.
Microsoft documents that Lists rules can notify when list data changes, while the Power Platform supports broader automation and applications. See Automate a list. The intake structure above is original operating guidance, not a built-in Microsoft template.
Run triage as a decision meeting
A 30-minute weekly meeting can work if incomplete items are handled before the call and decisions are recorded during it.
| Moment | Owner | Required outcome |
|---|---|---|
| Before triage | Intake coordinator | Check duplicates, required fields and obvious routes; return incomplete submissions with a precise question. |
| At triage | Business and delivery representatives | Choose return, discovery, reuse, self-service, delivery or park/decline. Assign the next person and date. |
| After triage | Named action owner | Update the requestor and complete the next action. Do not let meeting notes become the only record. |
| Monthly | Portfolio sponsor | Review capacity, ageing, overrides, duplicate demand and the balance of strategic versus reactive work. |
| Quarterly | Analytics leadership | Revise criteria and service boundaries using evidence from delivered, declined and abandoned requests. |
Microsoft’s tactical-planning guidance recommends prioritising the solution backlog and defining initial scope, timelines and responsible teams. This intake process creates the evidence needed to make those decisions before solution planning begins.
Measure flow, value and honesty
A shorter queue is not automatically better. You need evidence that the organisation reaches decisions faster without lowering quality.
Operational measures
Track time to first decision, time waiting for requestor information, discovery age, percentage routed to reuse or self-service, scheduled work without a named owner, and priority overrides.
Use medians and age bands as well as averages. Separate active work from waiting time so the team sees where delay actually occurs.
Outcome measures
After release, confirm whether the intended decision occurs, whether users complete the task, whether definitions reconcile and whether the owner still needs the output. Record changes, support demand and retirement candidates.
A published report is an output. Adoption and better decisions are outcomes that still require evidence.
Is this request ready for portfolio review?
Select only statements supported by the request record. Both critical gates must pass before a score or deadline can make the item ready.
Frequently asked questions
Should every request need a formal business case?
No. Use proportionate evidence. A small team improvement may need a short decision contract; a sensitive enterprise solution needs deeper discovery, governance and approval.
Who should own the reporting request?
A named business owner should own the decision, definitions and acceptance. Delivery and source owners have separate responsibilities for implementation and data.
Does the highest score always get built first?
No. The score supports transparent comparison. Dependencies, capacity, regulatory obligations and portfolio balance can change the sequence, but the reason should be recorded.
Can Microsoft Lists replace a full project tool?
It can provide a practical intake register for many teams. If delivery needs complex dependencies, resource planning or engineering workflows, link the approved request to the appropriate delivery tool.
Turn reporting demand into a portfolio you can defend
Smart Statistics helps UK organisations clarify reporting needs, prioritise analytics investment and build solutions with visible ownership. Start with the next request before it becomes another dashboard nobody maintains.