A dashboard to see where work is stuck

Direct answer

A bottleneck dashboard answers one question: where is work waiting, and for how long? Totals such as orders received or tasks closed tell you volume. They do not tell you that eleven items have sat in the same stage for two weeks. The core of this dashboard is age-in-stage: for every open item, how long it has been in its current stage and who currently holds it. Everything else (blocked flags, handoff delays, alerts) builds on that.

LATYNEX builds these as custom web dashboards, delivered directly and remotely, in English. This is different from a general KPI dashboard covered on the dashboard development page and from automating recurring reports, which is what manual reporting automation is about. Here the focus is stuck work.

Stages and owners come first

The dashboard is only as good as the process model behind it. Write down the stages an item passes through, in the order it actually happens, and the role or person who holds the item in each stage. If two stages share an owner but different handoffs, keep them separate; if a stage has no clear owner, that is itself a finding.

• Use a small number of stages that people recognise, not a full process map
• Define what marks entry into and exit from each stage, in terms of an event a system or person records
• Give each stage one accountable owner or queue at a time
• Decide how items that go backwards (rework, returned for information) are counted, so they do not silently reset their age

Age and SLA

For each open item, calculate time in current stage from the recorded entry event. Then compare it against a threshold you set per stage: this can be a service commitment you have with clients, an internal target or simply a level that your team agrees is too long. The threshold values are yours to decide; we do not supply benchmarks.

Show ages as a distribution rather than an average. An average hides the few items that are badly stuck; a list sorted oldest first, with a count above and below the threshold per stage, surfaces them immediately. Also consider whether waiting time should be measured in working hours or calendar days, because a weekend can make a healthy stage look late.

Blocked items

Distinguish between waiting because nobody has acted and waiting because something specific is missing. A blocked flag with a reason (waiting for client documents, waiting for a supplier, waiting for internal approval, missing information) makes the dashboard actionable, because each reason has a different owner and a different fix.

Blocked items should not disappear from view. Keep them visible with their reason and how long they have been blocked, and count time blocked separately from time in process so the team can see both the work they control and the work they are waiting on.

Handoff delays

Many delays hide in the gap between two people rather than inside one person's work. Measuring the time from the moment an item leaves one stage to the moment the next owner actually starts on it reveals handoffs that lose time: queues nobody watches, notifications missed, work batched until a weekly meeting.

Show handoff delay separately from working time in each stage. When the biggest delays turn out to be handoffs rather than effort, the fix is usually a rule or an alert, not more people.

Data sources

A bottleneck view needs timestamps of stage changes. Where they come from decides how reliable the dashboard is.

• An existing system that already records stage changes with dates: the cleanest source, connected where it offers an API, scoped per project
• A spreadsheet or shared file updated by hand: workable, but stage dates are only as good as the discipline of updating them
• Several systems, each holding part of the journey: possible, but requires an agreed item identifier so records can be joined
• No timestamps at all: the first step is to start recording them, sometimes through a small internal tool, before any dashboard can be honest

Alerts

A dashboard people must remember to open is weaker than one that nudges. Alerts should be few and tied to a decision: an item crossing its stage threshold, an item blocked longer than agreed, a queue growing beyond a set size. Send them to the owner of that stage, not to everyone. Too many alerts train people to ignore them, so start with two or three rules and add only when a genuine miss justifies it.

What it will not show

Be clear about the limits so nobody over-reads it. The dashboard shows where time is spent waiting; it does not explain why by itself. It cannot see work that never got recorded in a stage, and it will reflect any gaps or late updates in the source data. It is not a productivity ranking of individual people, and we advise against using it that way, since it tends to distort behaviour and the recorded data. It also does not replace judgement: an old item may be old for a good reason.

For costs and scope of dashboards in general, see dashboard development cost. If the underlying problem is that requests arrive in inboxes with no record at all, an internal request portal may need to come first, and the automation opportunity finder can help you spot which manual steps create the delays.