Four numbers that tell you if a review cycle is healthy

Ask an ID team how the project is going and you will usually get a count. Six of eight modules drafted. Four storyboards in review. Twelve revision items open.

Counts describe output. They do not explain why the launch date keeps moving. A team can draft six modules on schedule and still miss the date because every module goes through four review rounds instead of two, and nobody was measuring rounds.

These are the four numbers worth tracking. Each one isolates a different failure, and each implies a different fix.

1. Review round count

How many times does an asset go back to the same reviewer before approval?

This is the single most useful number in the ID workflow and almost nobody tracks it. Two rounds is healthy. Three is normal on complex or high-stakes content. Four or more means something upstream is broken, and the rounds themselves are the symptom rather than the disease.

When round count is high, the cause is usually one of three things. The review brief did not define scope, so each round surfaces a new category of feedback. The asset went to review before it was ready, so round one is doing the job preflight should have done. Or the reviewer is being asked to judge things outside their expertise, so their feedback wanders.

The fix depends on which. But you cannot pick a fix until you are counting rounds, and counting rounds costs nothing.

2. SME response latency

How long between sending an asset and receiving feedback?

Track the median, not the mean. One SME who disappeared for three weeks while on leave will drag a mean into uselessness and tell you nothing about the typical case.

Latency is the number most likely to be the real constraint on your schedule and the one IDs are least empowered to fix. That is exactly why it is worth measuring: it converts "reviews are slow" into "median SME turnaround is nine days against a project plan that assumed three", which is a sentence a project sponsor can act on. Without the number, the ID team absorbs the slip and looks slow.

Watch for the pattern where latency climbs across a project. It usually means SME fatigue, and SME fatigue means the quality of the feedback is dropping at the same time as the speed.

3. Rework rate

What fraction of revision items get reopened after being marked done?

A reopened item means the revision did not match what the reviewer wanted. Some of that is unavoidable. Above roughly one in ten, it points at a specific and fixable problem: the feedback was captured as a paraphrase rather than as what the reviewer actually said.

This is the number that makes the case for verbatim capture and source citation better than any argument. When an ID works from "SME wants slide 7 clarified", they are guessing at what clarified means. When they work from the SME's own words, they are matching a target. Teams that move to cited feedback typically watch rework rate fall without anything else changing.

High rework rate also inflates round count, which makes it easy to misdiagnose. If rounds are high, check rework before you go rewriting your review brief template.

4. Blocked ratio

What fraction of open revision items cannot be started because they depend on an unanswered question?

Most teams have one revision list and treat every item on it as workable. They are not. An item that depends on legal confirming compliance language is not work, it is a waiting.

When the blocked ratio is high, the ID team looks busy and unproductive at the same time, which is corrosive to morale and to the PM's trust. Splitting the list into actionable and blocked does two things immediately: the real capacity becomes visible, and the blocked items become a specific escalation list with names attached rather than a vague sense that things are stuck.

If your blocked ratio is above about a quarter, the bottleneck is not ID capacity and hiring another ID will not help.

What not to track

Word count, slide count, and hours logged are noise. They measure activity, not progress, and they reward the wrong behavior the moment anyone knows they are being watched.

Resist per-reviewer scorecards too. The instant an SME believes their turnaround time is being reported to their manager, you will get fast, shallow feedback, which is worse than slow and thorough. Track latency to manage the schedule, not to rank people.

Start with two

Do not instrument all four at once. Round count and blocked ratio are the two that pay for themselves fastest, and both can be tracked in a spreadsheet by hand for a single project. Run them for one project. If they do not change a decision you make, stop tracking them.

The point of these numbers is not the dashboard. It is that "the review cycle feels slow" is not an actionable statement, and "median SME turnaround is nine days and a third of our open items are blocked on legal" is. The first gets sympathy. The second gets a decision.

Where the tooling helps

StorySync tracks revision items with their status and their source citation, so round count, rework, and blocked ratio come out of the workflow rather than out of someone maintaining a tracking spreadsheet beside it. The audit trail is a byproduct of doing the work, not extra work.

A spreadsheet is genuinely fine for one project with one SME. It stops being fine somewhere around the point where you have parallel review cycles on different modules and the spreadsheet becomes a second job. But start with the spreadsheet. If the numbers do not change what you do, better tooling for collecting them will not help either.