How to track two numbers for contract review turnaround

A single turnaround number for contract review almost always hides two different problems, and they need two different fixes. One is how long a contract sits before anyone opens it. The other is how long it takes once somebody does. Teams that only track the blended average end up fixing the wrong thing.

The file that sat for three days and took twenty minutes

Picture a vendor agreement that lands in the queue on Monday morning. Nobody opens it until Wednesday afternoon. Once a reviewer does open it, the call takes twenty minutes: standard terms, one flag on a liability cap, done. The dashboard logs that file as a three-day turnaround.

Look at that number next to a reviewer's monthly stats and it reads like a slow review, but the review itself only took twenty minutes. What ate the other three days was getting a set of eyes on the file in the first place, which is a routing and staffing question, not a reading-speed question. If the team responds by telling reviewers to work faster, or hires another reviewer to bring the average down, effort goes toward a problem that doesn't exist while the actual one, an intake queue nobody is triaging, keeps sitting there.

Split the clock into two stages

Splitting that average into two separate numbers, queue time and touch time, is what actually surfaces the problem. Queue time runs from when a contract lands to when someone, or something, actually starts working it. Touch time runs from that first look to a decision. A legal-ops reference guide lists intake-to-assignment, the time from a request being submitted to it being assigned to an attorney or specialist, as its own cycle-time metric, tracked separately from overall contract turnaround. The two stages break for different reasons and get fixed by different people, so folding them into one average erases the information you actually need.

Once you have both numbers, report them by contract type and by percentile, not just by average. A framework for measuring contract cycle time recommends reporting calendar and business days while computing the median and the 90th percentile alongside the mean, and splitting touch time from wait time. An average can look fine while a handful of contracts sit ignored for two weeks; the percentile spread is what shows you that tail. A high ratio of wait time to touch time is worth watching on its own, since it points at handoffs and idle queues rather than slow reading.

Where an AI first pass actually changes the clock

This is the part worth being honest about. An AI first pass doesn't make a reviewer read faster, and it won't rescue a contract that nobody assigns to anyone. What it can do is start the touch-time clock earlier, because it can read the document and check it against your playbook the moment the file lands, instead of waiting for a person to be free. That converts some queue time into touch time automatically, before a human ever opens the file. Treat it as a sanity check on your own numbers rather than a fix on its own: run it for a month, then look at whether your queue-time number actually moved, or whether the bottleneck was somewhere else the whole time, like an approval step downstream. Tools built around a contract review workflow can flag issues at intake, but somebody still has to watch the queue and act on what it shows.

If your queue-time number is the one that's broken, the underlying issue is usually how contracts get triaged on the way in, not how fast anyone reads once they get to it. Standard NDAs and low-risk order forms sitting in the same queue as a complex MSA, with no routing rule to tell a reviewer which one to open first, is a common way for queue time to blow up even when the team isn't understaffed.

Report both numbers before you act on either

None of this requires new software to start. Pull the timestamp for when a contract entered the queue, the timestamp for when someone first opened it, and the timestamp for the decision. Three data points, two intervals, and you can already tell whether you have a staffing problem, a routing problem, or a genuinely slow review process. Teams that have never split the two out usually find that's exactly why the fix keeps landing on the wrong stage.

Try goHeather free if you want to see what a first pass looks like against your own playbook before you decide where your queue is actually stuck.

This is legal information, not legal advice; consult a lawyer for legal advice.