One of the more uncomfortable realisations for operations leaders is that a busy team and an effective team can look identical from the outside.
Cases are being worked. Emails are being sent. Calls are being made. Staff are occupied. From a management perspective, the operation appears to be functioning. The problem only becomes visible when case resolution times are measured, when a backlog surfaces unexpectedly, or when a customer complains that nothing seems to have moved despite multiple contacts.
The distinction between activity and progress is one of the most important and most overlooked in regulated operations.
What activity looks like
Activity in a regulated case process tends to generate its own momentum. A document is requested. The customer does not respond. A follow-up is sent. The customer responds with the wrong document. Another request goes out. A note is added to the case. The case has had several touches, several communications, several staff interactions.
From a workload perspective, all of that activity is real. It took time. It required attention. It looks like progress because something was always happening.
But the case has not moved. It is in exactly the same position it was in before the activity started, except that more time has passed and more resource has been consumed.
This pattern is not unusual. It is a structural feature of case processes that were not designed to distinguish between work that advances the case and work that results from the case not advancing.
Why the distinction matters
The difference between activity and progress matters for several reasons, but three stand out in regulated operations.
The first is capacity. A team that is generating significant activity on cases that are not progressing has less capacity for cases that could. The activity is consuming resource that is not producing resolution. If the team is measured on touches or contacts rather than resolutions, this problem can persist for a long time without becoming visible.
The second is service quality. Customers experience the activity — the requests, the follow-ups, the contacts — without experiencing the progress. In competitive regulated markets, a customer who has been contacted multiple times and is still waiting for a resolution is a customer who is forming a negative view of the business regardless of how hard the team is working.
The third is compliance. In regulated lending and financial services, there are often requirements around how long a case can remain open, how frequently certain steps must be completed, and what must happen before a case can be closed or escalated. A case that looks active but is not progressing may be drifting toward a compliance breach without anyone noticing.
What progress actually looks like
Progress in a regulated case has a simple definition: the case has moved to a new stage in the process, or a decision has been made that resolves or closes it.
Everything else is either preparation for progress or a response to the absence of it. Requesting a document is preparation. Following up because the document did not arrive is a response to absence. Neither of those is progress in itself. Progress happens when the document arrives, is assessed, and the case moves to the next stage on the basis of that assessment.
Designed well, a case process makes this distinction visible. Cases that have genuinely progressed look different from cases that are in a chase loop. Exceptions that need a human decision are surfaced separately from cases that are waiting on something the system could handle automatically. Operations leaders can see at a glance not just how many cases are open, but where they are in the process and why they are there.
Building for progress rather than activity
The operational change required is not complex, but it does require deliberate design.
It starts with being precise about what constitutes a stage change in each case type, and making sure the case process only records progress when a stage change actually occurs rather than when activity occurs. It continues with identifying the most common causes of cases stalling at each stage and building specific responses to them into the process rather than leaving them to individual judgement.
It means distinguishing between cases that are waiting on an external input — a customer response, a provider decision, a third-party check — and cases that are waiting because no one has taken the next action. The first category may be unavoidable. The second almost never is.
And it means giving operations leaders visibility at the case level, not just the team level. Knowing that the team handled two hundred cases this week is less useful than knowing how many of those cases advanced to a new stage, how many are in a chase loop, and how many are waiting on an internal action that has not yet been taken.
That visibility is what allows operations leaders to manage outcomes rather than activity. And it is what separates a team that looks effective from one that actually is.
