AI Drafts Are Faster. Is Your Review Queue?

A small design studio starts using AI to draft replies to project enquiries. The drafts take seconds, and by Friday there are twice as many replies ready for review. Yet clients wait longer to hear back. The person who checks budgets, deadlines and promises still has the same amount of time. The drafting step improved; the handover to the client did not.

If you lead a small team, it is easy to measure the part of the job that suddenly moves faster. Look instead at the work between “ready for review” and “a decision has been made”. How much sits there? How long does it stay? Those questions can tell you whether to improve the drafts, change how you admit work for review or give reviewers more time.

Count the work inside one boundary

John D. C. Little’s 1961 paper on queues proved the relationship now known as Little’s Law. As Little explains in his 2011 retrospective, the average number of items in a system equals the average rate at which items enter multiplied by the average time they spend there, under the relevant conditions. In a stable workflow over a representative period, the inflow and outflow rates will be close. That lets you use the rate of completed reviews as an estimate of how fast work passes through the review stage.

Consider a hypothetical studio that averages 12 replies inside its review stage and resolves six a working day. If the stage is broadly stable, that points to an average of about two working days inside it. A second stable arrangement with the same completion rate and an average of 24 replies inside the stage points to about four working days. The arithmetic describes a relationship between averages. It does not mean every client waits that long or that limiting the queue will automatically make people review faster.

Choose a boundary you can observe. At the studio, a reply enters when it reaches the review list and leaves when someone sends it or makes a final decision not to send it. A reply being checked still counts as inside. One sent back for a correction still counts if the case remains open. If it leaves the stage for revision and later enters again, decide whether you are counting review visits or unique enquiries. Either view can serve a purpose; mixing the two makes the figures hard to interpret.

Watch for a backlog that is still growing

Now imagine that eight replies enter review every day and only six leave. The studio adds two unfinished cases each day. In that situation, dividing today’s list by six gives a rough sense of how much work is already there at the current pace. It is not a reliable forecast for each new client, and the growing backlog is the more useful signal. Compare entries with exits first. Check whether the gap narrows after a short burst or persists across ordinary working days.

Keep an eye on the oldest open case as well. Suppose the studio clears the simplest replies first. It may close a respectable number of cases while the client with the most complicated brief hears nothing. Track time since entry for unresolved work alongside the time that completed cases spent in review. A completed-only average can look better simply because the slower cases are still waiting. If you count in working days, use that same clock throughout; if clients expect a response over the weekend, track elapsed time for that promise separately.

Run a small trial before buying more speed

• Record the baseline. For a working week, log when each enquiry enters and exits review, why it exits and how many cases are open at the same time each day. Fixed-time snapshots are a practical approximation; if the queue fills and drains between snapshots, sample more often.
• Find out what reviewers are doing. Look at a few cases that took longest. Were people correcting invented promises, waiting for price information or simply waiting for someone with authority to make a decision? Each explanation points to a different change.
• Change one thing. Try a smaller intake batch or require the owner to attach confirmed availability and pricing before the reply enters review. If you cap the review list, keep upstream waiting visible so that the cap does not merely move the queue out of sight.
• Check what clients experience. Compare time from enquiry to sent reply as well as time inside review. Keep cancellations and decisions not to send visible. A shorter queue achieved by closing more cases without replies may be a poor result.

If the trial shows that difficult cases need a person with specific authority, protect that person’s time before generating more drafts. If reviewers spend most of their time checking the same missing detail, put that detail in the brief. And if the workflow depends on a single colleague, a manual fallback drill can show what the team can still handle when the tool is offline.

The useful sign of progress is a reply reaching the client sooner with its promises checked. You can still measure how quickly the AI drafts it. Just make the review queue visible alongside that number, so the team knows whether it has saved time for the person who is waiting.

Sources

• John D. C. Little, A Proof for the Queuing Formula: L = λW, Operations Research (June 1961).
• John D. C. Little, Little’s Law as Viewed on Its 50th Anniversary, Operations Research (June 2011).