A business intelligence dashboard gives an audience a focused view of the information needed for a decision. Begin with that decision, then define the measures, inputs and follow-up actions. A clean display helps only when its numbers mean what readers think they mean.
Start with the decision and its owner
A fictional web team meets each Monday to decide which content work needs attention. Its manager needs to know the open release backlog, whether maintenance reviews are overdue and how many releases were completed. These are operating measures; they do not establish that readers successfully completed their tasks.
Microsoft's dashboard design guidance recommends considering the audience and the metrics that support decisions. Apply that principle before selecting charts or software. Decide what action an unusual value should prompt and who will investigate.
Write the reporting period and time zone explicitly. Use a snapshot for a current queue and a defined interval for completed work. Mixing the latest backlog with an unlabeled all-time release total makes comparison difficult.
Write a metric dictionary
| Metric | Definition | Action supported |
|---|---|---|
| Open backlog | Items in queued, draft or review status at the snapshot; excludes published and canceled. | Assign or unblock work. |
| Overdue reviews | Published items with review_due earlier than the snapshot date. | Ask owners to check facts. |
| Completed releases | Items with a release date inside the inclusive reporting interval. | Understand delivered work. |
| Unknown review dates | Published items whose review_due value is missing. | Repair incomplete maintenance data. |
Keep the source table, grain and owner with each definition. In the sample, each row is one content item and contains at most one recorded release. That simplification means the release count cannot represent multiple releases of the same item. A real activity report may need a separate release-event table.
Read the worked dashboard
The overdue rate uses only the three known dates and displays the missing case alongside it. Reporting two of four as an unqualified 50% would hide uncertainty about the fourth item. A review due exactly on October 4 is due today under this definition, not overdue.
Check the inputs before interpreting change
Download the sample data, metric dictionary and calculation instructions. All records are fictional. The instructions specify the snapshot, date boundaries, allowed statuses and formulas in plain language.
Check duplicate identifiers, impossible dates, missing extracts and stale timestamps. Keep missing values distinct from zero. If the refresh fails, retain the last successful timestamp and mark the display as stale instead of making an empty extract look like a cleared backlog.
Reconcile headline values with the underlying records. When a definition changes, document the change and determine whether older periods can be recalculated comparably. Never average departmental percentages without considering their denominators.
Choose a display and a follow-up routine
Use a compact table or a few clearly labeled numbers for the initial weekly view. Add a trend only when several comparable periods are available. Let a reader reach the records behind a count, subject to their access. Keep time periods, units and filters visible.
Separate observation from explanation: a larger backlog could reflect incoming work, slower completion or a scope change. Investigate before assigning a cause. Compare dashboard tools using the same content, refresh needs, access model and operating costs; old vendor cost rankings cannot answer a current procurement question.
At each review, record the decision, owner and follow-up date. Combine these operating measures with reader-task evidence so the team can judge usefulness as well as output.