When an asset has been waiting for review, another reminder can feel like the obvious next action. Sometimes it is useful. Sometimes it simply adds another message to a queue whose real problem is unclear ownership, missing context or a decision that the nominated reviewer cannot make.
I would look at the waiting work before increasing the volume of reminders. My question is not only how long an item has waited. I also want to know what changed while it waited, which commitment it now affects and what would allow the next decision to happen.
The example below is a fictional creative-delivery queue containing a training script, an interview edit and a campaign thumbnail. It illustrates my proposed approach; it is not a report of a client project. The objective is a useful review conversation with an owner and an outcome, rather than a dashboard that merely counts overdue work.
I define when the review clock starts
I would not start the review clock just because a file exists. A reviewable submission needs the correct version, working access, enough context and a clear request. If a reviewer cannot open the file, the work is blocked before meaningful review has begun.
For this queue, I would record both the submission time and the time the review was ready to proceed. Keeping both prevents an access problem from disappearing from the history. It also helps distinguish a delay in preparing the submission from a delay after the reviewer received a usable request.
The May 2025 Kanban Guide distinguishes the age of unfinished work from the elapsed time of completed work, with start and finish points defined by the workflow. My review-queue age is a narrower, explicitly labelled measure for one stage, not a substitute for the whole item's age. The Kanban Guide.
I read the oldest item before interpreting the average
An average waiting time can hide an item that has been stuck much longer than the rest. I would look at individual rows and their histories before deciding that the queue is healthy. A recently added set of quick reviews can make the average look better without helping the oldest work.
In the fictional queue, the training script has waited four calendar days, the interview edit two and the thumbnail one. Those numbers do not determine priority by themselves. The script may block recording, while the thumbnail has several days of flexibility. I would show the downstream commitment beside the age.
I would also label the unit. Calendar days and working days are different measures, especially around weekends and public holidays. If the team changes its convention, I would explain the change rather than compare the new number with an incompatible historical baseline.
I ask whether the reviewer owns the requested decision
The training script might be waiting because the nominated reviewer can comment on tone but cannot accept the technical explanation. Sending that person a stronger reminder would not solve the authority gap. I would identify the appropriate subject-matter reviewer and clarify who consolidates the response.
For the interview edit, the unanswered question could be much smaller: does a particular quotation retain its intended meaning after the cut? I would include the relevant timecode and the version rather than ask someone to watch the entire project history again.
I would keep a single named next decision on the queue row. Several people can contribute, but an item labelled “with everyone” leaves nobody clearly responsible for moving it forward. If the decision belongs to a group, I would name the person who brings the group's answer back into the project record.
I separate missing information from lack of capacity
A reviewer who lacks context needs a better submission. A reviewer who lacks time needs a capacity decision. Those problems require different responses, so I would not group them under one generic overdue status.
My check would ask whether the reviewer has the correct file, the question, the acceptance criteria and the agreed response date. I would then ask whether the estimated review effort fits the person's available time. A five-minute approval and a detailed factual review should not be treated as interchangeable calendar entries.
If capacity is the constraint, I would bring options to the person responsible for the commitment. We might resequence the work, agree a qualified deputy, reduce the review batch or change the delivery date. I would not silently reduce the review standard to make the dashboard look current.
I make the escalation easy to answer
My escalation would contain the item and version, the specific decision required, the effect of waiting and a proposed next step. It should be short enough to act on without reopening every message in the conversation.
For the training script, I might propose: the demonstration sequence in version three needs a factual decision before recording; the current review owner is unavailable; either a named qualified deputy reviews it by the agreed time or the recording slot moves. The recipient can then decide between concrete options.
I would distinguish a proposed deadline from an accepted commitment. Writing a time in a message does not establish that the reviewer has agreed to it. The queue should reflect the actual agreement, including any uncertainty, rather than turn my request into an invented promise.
I check what happens after the reminder
Once the decision arrives, I would record it against the reviewed version and identify any resulting work. “Feedback received” is not necessarily the same as approval. If changes are requested, somebody needs to own the revision and the next review step.
I would retain the original submission and decision times so that the completed review can inform future planning. Where the same cause keeps appearing, I would test a small process change: a clearer submission form, smaller batches or a reserved review slot, for example.
For me, an ageing queue is an invitation to investigate the work. The useful result is not a higher reminder count. It is a decision made with the right context, by the right person, in time to support the next commitment.
Research and example note
Prepared from sources available on 2 November 2026 for a 3 November publication slot. The queue, roles and timings are fictional. The proposed method uses the distinction between unfinished and completed work to support a practical review process; it does not claim that a single metric diagnoses every delay or that the example is a complete Kanban implementation.
