Measure rework caused by incomplete inputs

Where the extra work starts

Measure those return visits so the improvement targets the source of rework instead of simply making the first pass faster.

Invoice rekeying is a bounded task you can test today. Use the same invoices to compare your manual method with ParseMill, including source checks, corrections and export. The monthly plan costs $49 USD for 500 PDF processing pages and one user; judge it against the work it actually removes for you.

Use a stable case reference across all versions. File counts and message counts can increase during rework without representing additional completed requirements. The measured unit should remain the agreed package or task outcome.

A practical way to get it right

Record each touch with purpose, active minutes, evidence version and result. Mark the reason for rework in operational terms such as missing page, wrong period or unreadable file. Avoid labels that blame the client or staff when the cause is not established.

Separate normal review from repeated work caused by the incomplete input. A clarification message and second inspection may both be real effort. Keep waiting for resubmission as elapsed time outside active minutes. If another team performs a later correction, link its touch to the same case.

When comparing a revised intake process, use the same completed-case boundary and include any added upfront check. A longer initial inspection can still reduce total effort if it prevents more expensive later correction; the case log makes that tradeoff visible.

Microsoft: Calculate the difference between two times supports measuring each touch as an interval. Sum active segments while keeping resubmission waiting separate from person-minutes.

What this looks like on a real task

Synthetic example. The people, references and figures below are invented to demonstrate the method.

The case consumed 14 active minutes, not four. If the ordinary one-pass path takes six minutes, this example has eight additional minutes relative to that defined comparator. The comparison is illustrative, not a universal rework rate. Copy the touch log and include actual timestamps and source references in your own approved record.

Catch the cases that create rework

A resubmission can introduce a new problem, so do not assume the second upload is acceptable. Record every review outcome without resetting the case's age. If two staff inspect the same issue, determine whether both checks are required or whether duplication came from an unclear handoff.

Do not classify all follow-up as avoidable rework. Some clarification is inherent to the task; distinguish that from an input defect the proposed change could reasonably prevent.

Microsoft: Excel functions by category describes criteria-based totals. Sum by stable case reference and touch type to reveal rework recorded in different stages.

Decide whether the change is worth keeping

Reconcile the case log with its final evidence and ask whether any correction effort sits outside the diary. Compare total effort and completion quality before and after a targeted intake change. Track the specific missing-input causes so a generic “automation saved time” statement does not conceal that the useful improvement was a clearer request or an earlier completeness check.

The workflow audit checklist can help record the observed friction before considering a change.