Custom Dashboard Requirements Checklist

A dashboard brief should name the decisions it supports before listing charts. A director deciding whether to hire needs workload and capacity; an account manager needs overdue deliverables and blockers. Combining both into one crowded screen rarely serves either well.

Write A Metric Contract

For each measure, record its definition, source, owner, refresh interval and exclusions. If revenue means invoiced value in one system and received cash in another, choose the intended meaning and label it. Define currency, timezone and how corrections affect earlier periods.

For example, an overdue-project measure needs an agreed due date, a rule for paused work and a treatment for cancelled projects. Without those details, two departments can produce different totals while both appear correct.

Specify The Action Behind Each View

A summary number should lead to the underlying records when a user needs to investigate. Define filters that match real work: team, client, period and status. Preserve the active filters in exports, and identify the extraction time so a downloaded report can be explained later.

Decide how missing data appears. Zero means a measured absence; unavailable means the system does not know. Show the last successful refresh and alert the responsible person when an important feed stops updating.

Accept Against Known Examples

Choose a small set of manually verified records and reconcile every headline total. Test a user with limited access as well as an administrator. An export must not reveal records hidden in the interface.

Build A Requirements Pack A Supplier Can Estimate

A useful requirements pack separates business questions from proposed presentation. Write each question in the user's language: which jobs will miss their promised date, which service line has capacity, or which client accounts need attention? Then identify the measure and records needed to answer it. Do not begin by requiring a particular chart just because another application uses one.

For each view, specify the intended role, frequency of use and next action. A daily coordinator may need sortable records and ownership changes. A monthly management review may need a stable historical comparison and an export. These are different workflows even when they draw from the same database.

Include representative data with sensitive details removed. A supplier estimating from a clean five-row example may miss duplicates, historical status changes and absent identifiers in the real source. Provide unusual records as well as ordinary ones, and label which problems need cleanup before the dashboard can be trusted.

Work Through An Overdue-Delivery Dashboard

Consider an illustrative professional-services team managing 24 active projects. Management wants to know whether current commitments exceed capacity. The original request is a red-and-green project dashboard, but the underlying question requires more detail than a due date comparison.

Agree that an active project excludes cancelled and completed work. An overdue deliverable has an accepted due date before the reporting date and has not been approved as complete. Paused work remains visible in a separate group with a pause reason. Otherwise, the team could improve its overdue count merely by putting difficult projects on hold.

Suppose the sample contains four late deliverables, two paused projects and one deliverable awaiting client approval. The brief must state whether awaiting approval counts as internally overdue. One useful design shows internal delivery status and client-approval waiting time separately. That prevents a manager from assigning more production effort to work already delivered for review.

The acceptance pack might contain these examples:

Ask the supplier to demonstrate these exact records. If the interface produces a different total, resolve whether the code or requirement is wrong before extending the build. This gives both parties a concrete basis for acceptance.

Specify History And Corrections

Decide whether the dashboard needs to show what was known at a past date or only the current state of records created then. Those are different questions. A project that is complete today may have been overdue last month, and a current-state export cannot necessarily reconstruct that history.

If historical reporting matters, identify the events or snapshots required. Record changes to due dates, owners and key statuses where they affect performance interpretation. Agree who can correct mistakes and whether corrections restate prior reports or appear as adjustments. The answer depends on the business use, but it must not be accidental.

Label provisional data. Marketing and operational sources can update after an initial report. Google Analytics documents differing data freshness intervals, so a dashboard drawing on it should not imply that every recent period is final. State the reporting cutoff and last refresh for each material source.

Define Access And Export Requirements

Write a role-and-data matrix. A manager may see all projects, a coordinator only their team and a client only their own approved information. Apply the same rules to search, drill-down, downloads and scheduled emails. It is easy to protect the main screen while exposing a full dataset through an export button.

Specify whether totals include hidden records. A user who cannot see another team's clients may still be allowed to see a company-wide aggregate, but that needs an explicit decision. Small groups can also reveal sensitive information indirectly, so consider what the audience actually needs.

For exports, define format, column names, active filters, time zone and generated timestamp. Decide whether the file contains raw records or summarized values. A recipient should be able to reproduce the meaning of a report after it leaves the application rather than relying on a screenshot of the original filters.

Describe Empty, Stale And Failed States

Zero activity, no matching filters and unavailable data should look different. A blank chart leaves users guessing whether business stopped or the integration failed. Provide a plain explanation and an appropriate next step, such as changing a filter or contacting the data owner.

Set freshness expectations by decision urgency. A monthly review may tolerate yesterday's data. A dispatch queue may not. Document the maximum acceptable age, how a missed refresh is detected and what users should do until the source recovers. Avoid using the word live without defining it.

Include loading and partial-failure behavior in acceptance tests. If the sales feed succeeds but the billing feed fails, the dashboard should not silently combine today's sales with last week's balances under one timestamp. A partial view can still be useful when its limits are visible.

Prioritize The First Release

Rank requirements by the decision they unlock and the cost of getting that decision wrong. Deliver the essential metric definitions, source connections and record inspection first. Decorative chart variants and broad customization usually depend on a reliable foundation and can be evaluated later.

Agree ownership after delivery: who approves metric changes, who fixes source fields and who receives connector failures? Include a short operating guide and an example reconciliation. A dashboard becomes expensive to maintain when each new question requires rediscovering its original assumptions.

The dashboard governance guide provides broader context for metric ownership. The API integration overview is useful when multiple sources need reliable synchronization. Use them to identify dependencies before requesting a fixed implementation estimate.

Frequently Asked Questions

Should every KPI refresh in real time?

No. Match refresh frequency to the decision and source capability. Faster updates can add cost without improving a weekly management decision. Prioritize accurate definitions and visible freshness before pursuing low-latency updates for every chart.

Can a spreadsheet be the source?

Yes, if its structure, identifiers and ownership are stable enough for the required use. Document who can edit columns and how corrections are handled. If staff frequently change row meaning or overwrite history, address those issues before expecting reliable reporting.

What should I bring to a planning consultation?

Bring the decisions, sample records, metric definitions, role matrix and acceptance examples. Business Automation & Integrations is relevant when dashboard data must be pulled from connected apps and systems. Confirm the dashboard build, data sources and reporting scope separately rather than assuming they are included in a general website package.