AI Queue Reports: Include the Work Still Open

A queue can look reassuring when its report describes only the work that has already finished. Imagine an AI summary announcing a two-hour average completion time while two requests have each been open for a full day. The arithmetic may be correct. The report still needs to show whose experience that average represents.

For a small agency, independent creator or business owner, unfinished work belongs in the management picture. Keep completed durations and the current ages of open requests visible together. They answer different questions, and combining them carelessly can conceal the work that most needs a decision.

Use a completed duration and an open age separately

The May 2025 Kanban Guide, updated on 1 May 2025, distinguishes cycle time from work item age. Cycle time covers an item’s start-to-finish interval. Age measures time elapsed since an unfinished item started. The guide also tracks how many items remain in progress and how many finish per unit of time. These measures depend on the workflow’s agreed starting and finishing points.

Apply that distinction before asking AI to summarise a tracker. Specify the start event, the finish event and the observation time. A request entering an agreed production queue is one possible start; an approved deliverable reaching its recipient is one possible finish. These are choices for your process. Record them so a later report uses the same boundaries.

Follow the same four fictional requests

Consider a fictional studio with four requests, A to D. All enter its workflow at 09:00 on Monday. The clock runs continuously, including overnight. For this illustration, completion means the agreed deliverable has been approved and sent.

• A: finishes on Monday at 10:00 — one elapsed hour.
• B: finishes on Monday at 12:00 — three elapsed hours.
• C: remains open at 09:00 on Tuesday.
• D: also remains open at 09:00 on Tuesday.

At Tuesday’s snapshot, the mean duration of the two completed requests is (1 + 3) / 2 = 2 hours. Two of the four requests have finished. Each of the other two has an age of 24 hours.

The two-hour figure is a valid description of A and B. It cannot stand in for the eventual average across all four requests because C and D have no recorded finish yet. Report the completed average with its count, then show the two open requests and their ages.

Now advance the same example to Wednesday at 09:00. C finishes at that moment, after 48 hours. D remains open, also aged 48 hours. The completed-only mean becomes (1 + 3 + 48) / 3 = 17 hours 20 minutes.

That rise does not, by itself, identify a new slowdown or an AI failure. A long-running request has entered the completed set. Three requests now contribute to its average, and one remains outside it. Explaining that change in membership is more useful than attaching a cause to the new number without further evidence.

An unfinished request is an incomplete observation

The NIST/SEMATECH statistical handbook’s section on censoring explains the underlying observation problem through reliability tests. Some units reach the end of observation without the event being observed. Their eventual event times are unknown, while their observed run-times are available. This is a measurement analogy for unfinished requests, not a claim that a studio’s jobs follow a particular reliability model.

For C and D at Tuesday’s snapshot, the studio knows that each request has already lasted 24 hours. Their final durations are still unknown. Entering zero would contradict that observation. Entering 24 hours as a final completion time would imply a finish that has not happened.

Preserve the start time, current status and snapshot time. If a finish timestamp is blank, check whether the item is genuinely open or whether a completed event was never recorded. Those situations need different corrections. An AI summary should identify the uncertainty rather than silently choosing an interpretation.

Age also leaves the remaining workload open to investigation. A 24-hour-old request might need a short approval or substantial revision. Its age tells you how long it has been underway; establishing what remains requires looking at the request itself.

Label the group as carefully as the average

In the example, A to D form a fixed starting group: the four requests that entered together on Monday morning. Keeping that group visible lets the owner follow its completion progress across successive snapshots.

A report of everything completed during a week selects a different group. It may include requests started much earlier while excluding requests started this week that remain open. Either selection can serve a useful purpose. Name the rule, and keep it stable when comparing figures over time.

For example, “mean duration of requests completed this week” and “status of requests started this week” can sit beside each other in a report. Do not assume that they describe the same records. Keep the underlying request references available so someone can inspect the membership of each calculation.

Give the AI summary enough evidence to be useful

For a recurring review, ask for a compact report containing:

• The observation date and time, with the clock and workflow boundaries stated.
• The rule selecting the requests included in the report.
• The number finished, with any completed-duration average and its denominator.
• The number still open, with their individual ages or an inspectable age breakdown.
• Known blockers, missing records and the decisions that require an owner.

In the fictional Tuesday report, a clear summary would say: four requests in the starting group; two finished; completed mean two hours; two remain open, each aged 24 hours. That statement describes the recorded situation without inventing a completion forecast.

This reporting format is a management proposal. Ask an assistant to calculate from supplied timestamps, show which requests enter each figure and flag missing information. Check the result against the records before treating its narrative as an explanation of performance.

Use older open work to begin a practical discussion about blockers and priority. Age alone need not determine which request comes next. An urgent new commitment or a missing input may affect the decision. Record the reason and the next action so the following review can establish what changed.

Once the unfinished requests are visible, MaryChuks’s guide to finding a team’s coordination bottleneck offers a way to investigate where work waits. Keep that investigation connected to the actual open items, rather than relying on the completed average to represent the whole queue.

A useful AI queue report leaves the owner able to see both what has finished and what still needs attention. Preserve that complete picture before deciding whether the workflow is improving.

Sources

• The Kanban Guide, May 2025 edition — updated 1 May 2025; workflow definitions and flow metrics.
• NIST/SEMATECH e-Handbook of Statistical Methods, section 8.1.3.1: Censoring — undated section, checked 28 October 2026.

The studio, requests and timestamps are fictional. The reporting format is a practical proposal.