Loan-processing rework log: find and fix recurring causes

A loan-processing rework log should distinguish a correction to previously completed work from a new request or a changed requirement. Without that distinction, a brokerage can label every returned file an error and draw the wrong conclusion about its support team. Record what changed, why the work returned, and what evidence supports the explanation.

This guide provides a practical method for learning from repeat work. It is an operational improvement tool, not an individual performance ranking or a credit-quality assessment. The examples are fictional and the categories should be adapted to your own workflow.

Define rework before counting it

Use a working definition: rework is additional effort to correct an output that did not meet the agreed requirement when it was first completed. Keep new information, later scope changes and requests that were never included in the original instruction in separate categories. They consume capacity too, but they do not prove that the first operator made a mistake.

Capture the acceptance requirement that applied at the time. If the team cannot locate it, the issue may be an unclear instruction rather than a failure to follow one. Avoid writing “processor error” as the default reason; describe the observable mismatch first.

The quality-assurance sampling guide helps identify findings. This log takes the next step: tracing repeat effort, testing causes and checking whether a corrective action worked.

Record a small amount of useful evidence

Log field	Useful entry
Task reference and stage	Anonymous file reference and point where work returned
Expected output	Acceptance requirement and instruction version
Observed difference	Specific missing, incorrect or unclear item
Classification	Correction, new information, changed scope or unresolved
Extra effort	Estimated or measured minutes, labelled accordingly
Cause hypothesis	Possible explanation plus evidence still needed
Action and follow-up	Owner, proposed change and review date

Link to evidence in the approved file system rather than copying sensitive content into a separate analysis sheet. Record enough context to investigate, but do not turn the log into a second customer file. Keep a clear distinction between what someone observed and what they inferred.

Investigate the process, not just the last person who touched it

The American Society for Quality describes root cause analysis as a family of approaches for identifying causes of problems. For this workflow, use a simple evidence chain: what happened, what condition allowed it, what supports that explanation, and what change could test it.

Consider several possible causes. The instruction may be ambiguous, the source input may be incomplete, the template may be outdated, the task may have been interrupted, or the reviewer and operator may use different acceptance standards. These are hypotheses until checked. Asking “why” repeatedly should not turn an unverified assumption into a fact.

Invite the people involved to reconstruct the sequence. A useful question is “What information was visible when the task was completed?” rather than “Why did you miss this?” The aim is to identify a change that reduces recurrence while preserving fair, specific accountability.

Work through a fictional recurring return

Suppose twelve preparation tasks return over a fortnight. Five contain the same missing cover-sheet field, four reflect information received after preparation, and three have unrelated issues. Counting all twelve as identical defects would hide the actionable pattern.

The team examines the five matching corrections. The current SOP requires the field, but the template linked from the task board is an older version without it. The cause hypothesis is a stale template link. The owner replaces the link, removes the obsolete shortcut from the active instructions and asks a colleague to complete a fictional task using only the updated route.

The next ten comparable tasks contain no repeat of that particular omission. That is useful early evidence, but a small sample does not establish a permanent cure. The team keeps the check in place for the next review period and watches for another way the old template could re-enter the workflow.

Calculate rates with a meaningful denominator

Show the number of correction events alongside the number of comparable tasks reviewed. If five of fifty reviewed preparation tasks required correction, the observed correction proportion is ten per cent for that sample. It is not automatically the rate for every file, every worker or every month.

Track events and affected tasks separately when one task returns more than once. Three returns on one task are three rework events but one affected task. Also show extra minutes where useful: several minor corrections and one major reconstruction may create very different workloads.

Do not compare people whose queues differ without examining task complexity, input quality and review coverage. Use the balanced processor scorecard for broader operational reporting instead of converting this learning log into a single league table.

Choose a corrective action that can be tested

Prefer a specific process change to “be more careful”. Examples include replacing an obsolete template, adding a missing input check, clarifying an acceptance rule or changing the handoff point. State the expected effect and the evidence you will collect. Assign one owner and a date.

1. Confirm the repeated pattern and the evidence behind it.
2. Select one plausible cause to test.
3. Make a bounded change with a recoverable version history.
4. Review a comparable later sample.
5. Keep, revise or reverse the change based on the result.

If the change creates extra work elsewhere, include that cost in the review. A new check that prevents one error but adds an unnecessary review to every task may need a narrower trigger. Improvement should be evaluated across the workflow, not only at the point where the original defect appeared.

Close the loop at the weekly review

Bring three items to the meeting: the most repeated cause, the largest rework effort and any corrective action awaiting evidence. Keep unresolved classifications visible. A log is useful when it changes the next week’s work, not when it merely accumulates reasons after the fact.

If repeat work is consuming the capacity intended for new files, discuss your support workflow with Mortgage Talent. Bring the pattern and the accepted task definition so the conversation can distinguish a process problem from a staffing requirement.