Closing forty requests can look productive. It tells you little about the request that has been waiting nineteen days.
A queue needs two views side by side: throughput and aging. Throughput says how much moved. Aging says what didn't. If your dashboard shows throughput without aging, inspect the waiting work separately before deciding what the activity count means.
Start by defining the events. When does a request enter the queue? What counts as closed? Write both definitions down, because everything downstream depends on them. Include returned and reopened work in the counts, and state the business-hour definition the ages use.
Then segment. Not all requests need the same handling, and a single aging number across mixed work types misleads. Group by request type, then look at age bands within each group: how many are under a day, under a week, over two weeks old. Pull the five oldest unresolved items and read them individually.
For example, an illustrative week shows fifty arrivals and forty closures. Outstanding work grows by ten before reopens or cancellations. The oldest item sits at nineteen days, waiting for a decision nobody owns. A higher close count next week could still leave that item untouched.
Now find the recurring wait. Separate waiting for input, waiting for a decision, and waiting for capacity. Each points to a different intervention: clearer intake requirements, a named decision owner, or real capacity. Choose one experiment, not three.
Do not infer individual productivity from unadjusted case counts. The numbers describe the queue's behavior, not the team's effort.
At your next operations meeting, review the oldest five unresolved requests alongside the closed count, and name which wait each one represents.