Process intelligence · 5 min read

The invisible delay: how to spot it before your customer does

October 28, 2026

Cases that stall quietly, forgotten approvals, deadlines discovered too late. The problem is not the delay itself, but that nobody sees it while it can still be recovered.

The problem is not seeing the delay

A case that has been sitting in one stage for three days makes no noise. It raises no error, blocks no screen, and shows up in no report until someone asks where it went. Usually, that someone is the customer.

In a small or mid-sized company, where people wear several hats and handovers rely on emails and personal reminders, delay tends to take three familiar forms: the case that stalls in silence, the approval that slips through, the deadline discovered after it has passed. The delay itself often has a perfectly reasonable explanation. What hurts is that nobody saw it while there was still room to act.

This article is about monitoring time and ownership: how to make what is stuck visible, and how to decide who is responsible for moving it. It follows the principle we work by at FlowSharp: measure first, then automate.

What the Bain research says about decisions, and what it doesn't

Bain & Company studied “decision effectiveness” across a sample of nearly 800 companies, later developed in the book “Decide & Deliver” by Michael Mankins and Paul Rogers. According to Bain, there is a 95% correlation between companies that excel at making and executing key decisions and those with top-tier financial results, measured in revenue growth, return on capital and shareholder return. Quality and speed are two of the dimensions measured.

The limits deserve a plain statement. The responses are executives' self-assessments, and Bain itself acknowledges the possible halo effect: companies with good results may tend to rate their own decisions as good too. It is also a correlation, which does not prove that better decisions cause better results.

So we read it as a hint, not a promise: it suggests that the speed and execution of decisions matter. A stalled case is often a decision that was not made or not carried out: approve, route, reply. The figure describes the problem. It does not show that any software solves it, FlowSharp included.

Three blind spots: automation, human waits, deadlines

The first is automation that stops. A case can sit in an automatic or AI stage, for instance because no rule matches and there is no default branch, or because the AI execution failed. FlowSharp raises a persistent “Automation stalled” alert, one per case and stage, which Admins receive according to the flow's notification policy. There is also a check upstream: a process cannot be published if an automatic stage has no certain way forward, meaning a default rule, a timeout with a destination, or an SLA escalation.

The second is human work waiting in a queue. The notification policy supports timed steps with email, webhook or event, a digest per recipient, and time windows, so reminders don't turn into noise. Taking ownership happens with an explicit click on a single-use link with an expiry: “I've seen the request” becomes a recorded fact, not an impression. Admins can see both the time to take charge and the time to resolve.

The third is the deadline discovered late. With a stage timeout, a case can advance automatically to a set destination when the deadline expires, and the history labels it “Timeout” or “SLA”. The duration can use variables, for example an SLA duration shared across several flows. For cases created by an external assistant on a flow with start confirmation, the deadline is configurable, with a reminder and either automatic rejection or an expired notice.

Reading the clock: from the indicator to the single case

For the big picture, the Analytics view shows the “active SLA warnings” and “active SLA escalations” indicators, the average Lead Time, the points where cases get stuck, and the stages that take the longest. These are the numbers to check before deciding where to intervene.

Saturated stages are a complementary signal. With the WIP limit you can see admitted cases, queued cases and the saturation percentage: a growing queue is a delay in the making, visible before it becomes a missed deadline.

From the aggregate you drill down to the single case with the filters in the Cases list: overdue, diverted, queued on WIP, with stalled automation. It works as a coordinator's worklist rather than an archive: you can open it in the morning and know which cases deserve a phone call before the customer makes one.

Where to start: measure, then assign, then automate

A practical order, consistent with “measure first, then automate”. First: pick one flow where a customer has already had to ask where their case stood. Second: look at the average Lead Time and at the stages where cases stall, without changing anything yet.

Third: for each critical stage, write down three things: who is responsible, how long they have to act, and what happens when the deadline passes. Only then does it make sense to configure timeouts, escalations and notifications, because each of those rules assumes the three questions have already been answered.

There is no guarantee that delays will disappear. The realistic outcome is different: moving the moment of discovery from the customer to the team, while there is still time to decide. It is a modest ambition, and for that reason one you can check against your own data.