Most dashboards show you what happened, not what needs attention now
A lot of businesses have dashboards that look impressive but do very little to help run day-to-day operations.
They show revenue, monthly totals, completed jobs, average close rates or high-level KPIs. That can be useful for management reporting, but it does not necessarily help someone answer the operational questions that matter during the day:
- What is stuck?
- What is at risk of missing an SLA?
- Which approvals are holding work up?
- Which jobs cannot move because something is missing?
- Where is backlog building?
- What needs to be escalated today?
That is the difference between visibility and control.
A business process dashboard should not just tell you how the business performed last week. It should help the right people see what requires action now, what is likely to become a problem next, and where workflow is breaking down.
If the dashboard cannot help a manager prioritise work, unblock the team or prevent delays, it is probably reporting outcomes rather than supporting operations.
The difference between reporting dashboards and operational dashboards
The term "dashboard" gets used for several different things, and that is part of the problem.
Management reporting dashboards
These are typically used by owners, directors or senior managers to review business performance over time. They often include:
- revenue
- margins
- jobs completed
- quote conversion
- utilisation
- monthly trends
- team or branch comparisons
Useful, but mostly retrospective.
KPI dashboards
These are focused on agreed performance measures. They may track:
- response times
- close rates
- first-time fix rates
- average job duration
- invoice turnaround
- aged debtors
Again, useful, but often still summary-oriented.
Operational dashboards
This is where many businesses have a gap.
An operational dashboard is designed to help run work in progress. It focuses less on abstract performance and more on workflow state, bottlenecks, exceptions and immediate decisions.
A useful operational dashboard answers questions such as:
- Which jobs are active but have no next action?
- Which quotes are approved but not handed over?
- Which field jobs are waiting on parts, photos or client sign-off?
- Which approvals are overdue?
- Which tasks are blocked and why?
- Which work items are approaching an SLA threshold?
- Where is backlog growing faster than it is being cleared?
That is what makes it a business process dashboard rather than just another report.
What a business process dashboard should actually show
If the goal is operational control, the dashboard needs to reflect how work moves through the business.
That usually means showing a combination of queue health, workflow status, exception conditions and timing risk.
The exact design depends on the business, but the following categories are usually more useful than vanity metrics.
1. Queue size and backlog by stage
You need to know how much work is sitting in each stage of the process.
For example:
- new enquiries awaiting triage
- quotes awaiting review
- approved work awaiting scheduling
- jobs in progress
- completed jobs awaiting invoicing
- payroll items awaiting approval
A simple count by stage is not enough on its own, but it is a starting point. It helps identify where work is accumulating.
If one stage keeps growing while downstream stages remain stable, that often points to a capacity issue, unclear ownership or an upstream handover problem.
2. Queue age, not just queue volume
A queue of 20 items may be manageable. A queue of 20 items where half are older than five days may not be.
Age matters because it shows how long work has been waiting, not just how much exists.
Useful measures include:
- average age in stage
- oldest item in stage
- number of items over target age
- age bands such as 0 to 1 day, 2 to 3 days, 4+ days
This is often more operationally useful than raw totals.
A manager does not just need to know there are 14 approvals pending. They need to know that 6 have been waiting beyond the acceptable timeframe and are now affecting delivery.
3. Jobs or work items with no next action
This is one of the most important views in many operational environments.
Work often falls through the cracks not because nobody cares, but because the system does not clearly define what happens next. A status says "in progress" or "pending", but nobody owns the next step.
A strong dashboard should surface items where:
- there is no assigned owner
- the next action date is blank
- the record is sitting in a non-terminal status without movement
- the job is waiting, but the reason is unclear
- a handover has occurred without the receiving team accepting it
This is where dashboards start becoming genuinely useful. They expose silent failures in workflow design.
4. Overdue approvals and decision bottlenecks
Many businesses have work waiting on internal approval, customer approval or a compliance check, but the delay is not obvious until someone starts chasing manually.
A useful dashboard should show:
- approvals waiting by type
- approvals overdue by age
- who the approval is sitting with
- what downstream work is blocked because of that delay
For example, a quote approval delay is not just a sales delay if scheduling, purchasing or customer communication depends on it.
5. Blocked work and the reason it is blocked
Not all blocked work is the same.
A dashboard is much more useful when it distinguishes between different reasons, such as:
- waiting on customer response
- waiting on parts
- waiting on site access
- waiting on documentation
- waiting on technician photos
- waiting on internal review
- waiting on external contractor input
If everything blocked sits under one generic status, the dashboard will tell you very little.
The point is not just to count blocked jobs. It is to show the operational reason so you can decide what to do next.
6. Readiness gaps before work can start or continue
Many delays happen because a job technically exists in the system, but it is not actually ready.
For example, an installation may be "scheduled" even though one of the following is missing:
- scope confirmation
- site photos
- materials allocation
- permit approval
- customer access details
- final sign-off on the quote
A dashboard should be able to highlight work that is scheduled or committed but not operationally ready.
That prevents the office from discovering the problem only when the crew is already on the way, or when the customer calls asking why nothing has happened.
7. SLA risk and due-date risk
A good operational dashboard should not only show what is already late. It should show what is likely to become late soon.
This requires timing logic, not just status counts.
Useful views might include:
- work due within the next 24 hours without required progress
- jobs nearing SLA breach based on current state
- items with no activity for too long
- open work where the remaining path is longer than the remaining time
This is where dashboard design often becomes more valuable than canned reporting. The business may need rules that combine dates, status, dependencies and inactivity windows to identify risk properly.
8. Throughput and clearance rate
Backlog only makes sense when compared to throughput.
If 40 jobs entered a stage this week and 42 left it, the queue may be stable. If 40 entered and only 18 moved on, the queue is building.
A useful business process dashboard often includes:
- items entering each stage
- items exiting each stage
- backlog trend over time
- clearance rate by team or workflow
This helps distinguish between a one-off spike and a structural bottleneck.
The best metrics are tied to action
One of the simplest tests for a dashboard metric is this:
What action should someone take if this number looks wrong?
If there is no clear answer, it may be interesting but not operationally useful.
For example:
- "Monthly jobs completed" is useful for review.
- "Jobs completed awaiting invoice for more than 2 days" is useful for action.
- "Average quote turnaround this quarter" is useful for performance review.
- "Quotes awaiting technical review for more than 24 hours" is useful for intervention.
That does not mean summary KPIs have no value. It means they should not be mistaken for process control.
A business process dashboard should prioritise decision-support metrics over presentation metrics.
Why many dashboards create visibility without control
A common pattern is that the dashboard is built around whatever data is easiest to extract, not around how the operation is actually managed.
That leads to several issues.
The dashboard mirrors reports, not workflow
If the dashboard is just a visual layer over monthly reporting fields, it will tell you what closed, what sold or what was invoiced, but not what is stuck.
Statuses are too vague to be useful
If records can sit in "pending" or "active" for days without further definition, the dashboard cannot distinguish between healthy work and neglected work.
There is no source-of-truth rule
If job status lives in one system, scheduling in another, approvals in email and payroll information somewhere else again, the dashboard becomes a patchwork of incomplete truths.
Exceptions are invisible
Many operational problems happen outside the "happy path". Missing documents, partial completions, disputed extras, failed site visits and approval gaps often create the real delays. If the dashboard only reflects the ideal process, it misses the actual operational pain.
Nobody agreed on metric definitions
One person thinks "job complete" means field work finished. Another thinks it means paperwork received. Finance thinks it means ready to invoice. Without agreed definitions, the dashboard becomes an argument instead of a tool.
Definitions matter more than the chart type
Businesses often spend too much time discussing visual layout and not enough time defining what each metric actually means.
Before a dashboard can be trusted, the business usually needs agreement on questions like:
- What counts as a new job?
- When does a quote become approved?
- What does "ready for scheduling" require?
- When is a job considered blocked?
- What event starts the SLA clock?
- What event stops it?
- What counts as overdue?
- Which system owns each field?
- Who is responsible for keeping that data current?
If those rules are not defined, the dashboard may look polished but still create confusion.
In practice, this is often where good dashboard work really starts. Not in the visual layer, but in the operational definitions underneath it.
Common data sources and why integration becomes the real issue
A business process dashboard often needs data from several places, such as:
- CRM or quoting system
- job management or field service platform
- project management tool
- finance or invoicing system
- timesheets or payroll workflow
- customer communication records
- spreadsheets used to track exceptions or approvals
- forms, documents or compliance records
The challenge is usually not putting charts on a screen. The challenge is deciding:
- which system is the source of truth for each data point
- whether the required workflow states even exist in structured form
- how records match across systems
- how often data needs to sync
- what happens when one system is updated before another
- how exceptions are represented
For example, if the scheduling platform says a job is complete, but the invoicing process depends on photos, materials reconciliation and approval of variations, then "complete" may not be enough for billing control.
That is where integration design matters. Sometimes the answer is a dashboard over existing systems. Sometimes the underlying process or status model needs to be fixed first.
How often should dashboard data refresh?
The right refresh rate depends on the decisions the dashboard supports.
Not every dashboard needs live data. In some cases, near-real-time data only adds technical overhead without changing outcomes.
A practical way to think about it is:
- If the dashboard supports hourly operational decisions, frequent refresh matters.
- If it supports daily queue reviews, scheduled updates may be enough.
- If it is mainly for weekly management review, real-time is usually unnecessary.
For many operations dashboards, the real requirement is not "live" but "reliably current enough to act on".
For example:
- A scheduling or dispatch view may need very frequent updates.
- A daily approvals and backlog dashboard may only need refreshes every 15 to 60 minutes.
- A profitability or management summary may only need overnight updates.
The main question is: how stale can the data be before someone makes the wrong decision?
That is the refresh requirement that actually matters.
Signs you may need a custom internal dashboard
Not every business needs a fully custom dashboard, but there are clear warning signs when standard reports or spreadsheets are no longer enough.
You need cross-system visibility
If the decisions depend on data spread across multiple platforms, a canned report from one system will usually be incomplete.
Your key metrics depend on workflow logic, not just fields
For example, SLA risk may depend on status, age, assignment, missing documents and job type together. That often goes beyond out-of-the-box reporting.
Teams are manually reconciling the truth
If someone is exporting reports, combining spreadsheets and checking exceptions by hand every day, the reporting problem is probably really a systems problem.
The operation depends on exception handling
If delays usually come from special cases, incomplete handovers or unusual dependencies, generic dashboards tend to miss what actually needs attention.
Existing dashboards are visually clear but operationally useless
This is common. People can see counts and trends, but they still need to ask staff what is really going on.
There is constant debate about what the numbers mean
If every meeting starts with arguing over definitions, the first requirement is not a prettier dashboard. It is clearer operational logic and source-of-truth design.
Before engaging a dashboard consultant, answer these questions
If you are looking for help with a business process dashboard, a bit of groundwork makes the project far more useful.
What decisions should the dashboard support?
Be specific. Not "improve visibility", but things like:
- prioritise which overdue jobs to escalate
- identify where approvals are delaying work
- see which scheduled jobs are not ready
- monitor whether backlog is clearing
- detect SLA risk before breach
If the dashboard is not tied to decisions, it will drift into generic reporting.
Which workflows matter most?
Start with a real operational flow, such as:
- lead to quote to approved job
- approved job to scheduled work
- field completion to invoicing
- timesheet submission to payroll approval
- defect identification to resolution
A dashboard built around an actual workflow is more useful than one built around broad business categories.
What are the failure points today?
Look for places where work commonly stalls:
- handovers between teams
- missing documentation
- delayed approvals
- jobs with unclear ownership
- customer follow-up gaps
- repeated manual checks
Those are often the conditions the dashboard should expose.
Where does the data come from now?
List the systems, spreadsheets and manual steps involved. Include where people currently check information by hand.
This helps reveal whether the dashboard problem is really a data-structure issue, an integration issue or a process issue.
Are the statuses and definitions good enough?
If not, fix that first or fix it as part of the project. A dashboard built over poor workflow structure tends to preserve confusion.
Who owns acting on what the dashboard shows?
A dashboard without ownership becomes decoration. Someone needs to know which exceptions they are responsible for, and what action is expected.
What good looks like in practice
A useful business process dashboard usually has a few characteristics in common.
It shows work in progress, not just completed outcomes.
It makes exceptions obvious.
It distinguishes normal waiting from unhealthy delay.
It reflects real handovers and ownership.
It uses agreed definitions.
It pulls from the right sources of truth.
It refreshes often enough to support decisions.
Most importantly, it helps someone do something concrete.
For example, a service manager should be able to open the dashboard and quickly see:
- which jobs need intervention today
- where backlog is building
- which approvals are causing delays
- which work is scheduled but not ready
- which items are drifting towards SLA breach
- which teams or stages are not clearing work fast enough
That is a very different outcome from simply seeing a pie chart of job statuses or a monthly count of completed work.
A dashboard is only as useful as the workflow behind it
If the process is unclear, ownership is vague and data is scattered, a dashboard will not fix that by itself.
In many cases, the real work is:
- defining the workflow properly
- deciding what each status means
- identifying the source of truth
- designing the right triggers and handovers
- connecting the systems sensibly
- then building the dashboard around those decisions
That is why dashboard projects often sit somewhere between reporting, process design and systems architecture.
If your operation spans multiple teams, systems and exception paths, it is usually worth mapping the workflow before deciding what the dashboard should show. That is often where the most useful dashboard requirements become obvious, and where a business can avoid paying for attractive reporting that still leaves managers chasing answers manually.
5M Consulting helps businesses work through that definition process, especially where dashboards depend on workflow redesign, system integration or custom internal tooling rather than just another report layer.