A business dashboard describes what has happened or is happening. Predictive analysis estimates what may happen next, and a causal claim asks what would change if you took a particular action. These are different decisions with different data needs. Start with the decision you need to make, then choose the simplest evidence that can support it.
Dashboard: show the data you have and when it was updated.
Prediction: test the estimate against unseen records and explain its limits.
Invented shape for explanation only. No values, accuracy or business result are claimed.
Name the decision first
Imagine a fictional repair shop that wants to plan its weekly staffing. Its owner asks, “How many jobs are waiting, and how long have they been open?” A dashboard can group current jobs by status and show their age. It can help the owner see a queue building up, but it does not explain why the queue grew or say how many jobs will arrive next week.
Write the question in a way that identifies the action, time period and responsible person. “Show open jobs by status each Monday” is a reporting request. “Estimate next week’s incoming jobs so I can prepare staffing” is a forecast request. “Would adding a second intake shift reduce waiting?” asks about an intervention and needs evidence that can separate its effect from other changes.
Check what the records can support
Before commissioning a dashboard or model, list the fields already captured, who enters them, how often they change and what is missing. For the hypothetical shop, a usable table might contain:
| Field | Meaning | Question to resolve |
|---|---|---|
| Job reference | Identifier for one accepted job | Are duplicates or cancelled requests included? |
| Received date | When the request entered the queue | Is the date recorded consistently, including older spreadsheet rows? |
| Status and status date | Current stage and when it changed | Are past changes retained, or only the latest status? |
| Job category | Type of requested repair | Are categories stable and used consistently? |
| Completed date | When work was finished | Are unfinished jobs distinguishable from missing entries? |
These are proposed fields in a fictional example, not collected business data. Missing dates, changing status definitions, duplicate records or a short history can make a trend misleading. Record the gaps and decide whether staff can repair the source data before treating a chart or estimate as decision evidence.
Separate description from forecast
A descriptive dashboard summarizes recorded facts: open jobs today, jobs received by week, or completion time for jobs with a recorded start and finish. Agree on definitions first. For example, “waiting” might exclude jobs paused for customer approval. Show the period covered, refresh timing, missing-data limits and who checks the figures. A dashboard built from inconsistent records can present a precise-looking but unreliable total.
A forecast estimates a future value, such as weekly incoming jobs. It needs enough relevant history recorded in a consistent way, a clear forecast horizon and an outcome that can be checked later. Before fitting a model, choose a simple baseline, such as carrying forward the recent average. Compare both against later periods held out from model development, in chronological order. Do not randomly mix future and past rows: information from the future can then leak into the evaluation. Select an error measure that fits the decision, and inspect errors by period and relevant category.
Even a forecast that compares well with its baseline can fail when demand patterns change, records are incomplete, or the business changes its intake process. Agree who reviews forecast errors, when the estimate will be refreshed and when people should ignore it and use judgment instead. Synthetic examples can show a proposed layout or calculation, but cannot establish predictive accuracy for a real shop.
Treat cause as a separate question
A chart showing that weeks with more staff also had shorter queues does not prove that extra staff caused the improvement. Job mix, seasonal demand or a change in intake may explain both. To assess an intervention, define what changed, what outcome matters and what comparison could represent what would have happened otherwise. A simple before-and-after view may be useful for monitoring, but it cannot by itself rule out other explanations. The suitable design depends on how the business operates and what records exist; causal conclusions should not be inferred from a dashboard or forecast alone.
Keep the work owned
Assign a business owner to define measures and resolve exceptions, and an operational owner to check data refreshes, access and corrections. Confirm where the source records live, who may see them, how long they are retained and who updates definitions when the workflow changes. If the data cannot answer the question yet, improving consistent recordkeeping may be the useful first step.
Public-source competitor analysis is a separate option when the decision concerns competitors’ published offers or customer-facing information. It needs a bounded list of sources, dates and comparison questions; those observations do not substitute for your own operational records or predict your future sales. For custom reporting or a tool built around an existing process, see web application development. To scope a question, bring the decision, a sample of existing fields and known data gaps to contact.