Before commissioning a dashboard for “completed work,” decide what completion means. Does a technician close the job, does a supervisor accept it, or does another system issue a billing document? All three counts may be valid. They describe different events. Approve a definition card for each metric before drawing charts, then test it against records the operational owner can explain.
This guide starts after the business has decided a dashboard is justified. The remaining problem is semantic agreement, not choosing between spreadsheets and software. Internal Operations Portals & Dashboards can bring an agreed workflow, permissions and operational data together without implying a replacement ERP or a new accounting system.
Start with the decision the number will support
“Management needs a dashboard” is too broad. A more useful requirement is that the dispatch lead needs to identify overdue work before allocating tomorrow’s visits. That immediately raises questions about the definition of overdue, the freshness deadline and the detail needed to identify each job. If the reader cannot change assignments, the appropriate action may be escalation rather than an editing button.
Give every number a question and an intended use. A total helps describe workload, but does not identify a blocker. An exception table might be more valuable than another chart. The GOV.UK guide to user stories links the actor, need and goal to acceptance outcomes. Here, apply that principle to a specific operational decision rather than filling in a template mechanically.
What belongs in a metric definition card?
Keep a concise record that is accessible from the dashboard or its documentation:
- Display name, decision supported and accountable definition owner.
- Unit counted: request, visit, service line or distinct customer.
- Formula, including numerator, denominator and treatment of missing values.
- Relevant event, date field, time zone and period boundaries.
- Exclusions, such as cancelled work and test records.
- Authoritative source, stable record identifier and refresh schedule.
- Last successful update and the permitted route from a total to its underlying records.
“Current month” needs a date rule. It could mean jobs opened this month or jobs completed this month. Also decide what happens when an older record is corrected. A report may continuously reflect the latest source data, or preserve a closed-period snapshot with an amendment record. Either can be useful. An undisclosed mixture makes historical comparisons unreliable.
Worked hypothetical: three valid numbers
Suppose a maintenance team opens 120 work orders during an illustrative month. It completes 90 of those orders within that month and leaves 30 open. It also completes 20 orders carried over from the preceding month.
The count of orders opened during the month is 120. The count completed during the month is 110. The completion rate for the newly opened cohort is 90 divided by 120, or 75%.
Dividing 110 by 120 produces approximately 91.7%, but that is not the new cohort’s completion rate. It compares two flows with different membership. Management might use that comparison for another purpose, provided the label says so. If only 80 completed jobs have passed a later approval step, do not quietly redefine completed work as 80 because another department reports approvals.
Build a small acceptance dataset containing a new order completed this month, an older order completed this month and a new order still open. The operational owner specifies the expected result under each filter before the developer checks the calculation. These quantities are illustrative, not a client result or a maintenance-industry benchmark.
Reconcile at a level that explains the difference
Choose one period, source extract and set of filters. Record the extraction time and dashboard refresh time. Comparing screenshots produced on different days does not establish a defect.
When totals differ, identify extra records, missing records, date differences, state differences or duplication introduced by joins. Do not add a fixed adjustment simply to make today’s totals match. That conceals the cause and usually creates a new discrepancy later.
The scope of API Integration & Development should include field meanings, access boundaries and delayed updates, not just a successful connection. Data that has not arrived is not automatically zero. A visible stale-data state prevents the reader from interpreting a failed refresh as a collapse in business activity.
Corrections need ownership too. If a metric definition changes, document its effective date and whether earlier comparisons are recalculated. If the source is wrong, do not silently repair it inside the chart. Preserve an explanation of where the correction belongs and who approved it.
Specify what the business will accept
Product Discovery & Requirements can establish the metric dictionary, source map, filters, reader roles and unresolved decisions. Software Quality Assurance turns that agreement into acceptance evidence: expected calculations, period-boundary cases, missing data, unavailable sources and restrictions on underlying details.
Ask the operational owner to explain three displayed numbers and trace them to their causes without developer assistance. Check that exports apply the same filters and definitions, that refresh information is visible and that unresolved differences have an owner and a disposition. A visually polished chart does not close an unexplained data issue.
A useful handover also names who can revise a metric, how the change is approved and which readers are informed. Otherwise the first new department request can quietly undermine the agreement that made the dashboard trustworthy.
Frequently asked questions
Must the dashboard match every old report?
Only when definitions, periods and sources match. Keep an explained difference when an old report answers a different question. Establish one definition for each intended use rather than forcing unlike numbers to agree.
Is real-time updating necessary?
Choose freshness around the decision. A daily dispatch meeting may need a reliable update before the meeting, not continuous refresh. Specify an acceptable age and a visible delay state.
Who signs off the formula?
The operational decision owner, working with the data owner. The technical team implements and tests the formula, but should not independently decide what completion or exclusion means.
What if a required field is unavailable?
Change the question, improve collection or defer the metric. Presenting an estimate as a confirmed total creates confidence without dependable evidence.
Start with one disputed metric and a small set of its source records. An agreed definition and reconciliation example provide a stronger brief than a screenshot of a dashboard you admire.
Method reference
- GOV.UK: user stories and acceptance criteria, reviewed 26 October 2026. The definition card and worked example are original planning illustrations.