Table of contents
Rework is easy to feel and hard to prove. A processor resends a document, a reviewer rejects a condition, and the file loses a day. Without a log, the team remembers the loudest complaint and misses the quiet pattern. A rework log gives those repeated corrections a shape and a cause.
The log only helps when it separates a preventable error from a guideline change and from a borrower event. Those three causes call for different responses. Mixing them produces a report that blames the team for a lender update or excuses a fixable mistake as bad luck. The separation is the core design decision.
Define rework before counting it
Count rework as work that repeats a step already marked complete. A condition reopened after a reviewer rejection is rework. A document requested again because the first upload was incomplete is rework. A file that moves to a new stage with ordinary new requirements is not rework, even when it creates more work. The definition should be written before the first entry.
Ask the team to log the step that had to be repeated, the original completion date, and the reason for the repeat. A log without the original date cannot show the delay. A log without the step cannot show where the process broke. Keep the fields short enough that people actually use them.
Split causes into three lanes
The first lane is a preventable error, such as a missing page, a wrong borrower name, or a condition closed without evidence. The second lane is a guideline change, such as a lender updating a form or adding a requirement after the file started. The third lane is an external event, such as a borrower changing jobs or a title company discovering a lien. Each lane has a different owner and a different fix.
Do not let a single entry carry two lanes. If a guideline change exposed a missing page, log the guideline change as the trigger and the missing page as a separate preventable error. Split entries make the counts honest. They also prevent a team from hiding a fixable error inside a legitimate external event.
Record evidence, not blame
Each entry should name the document, the condition, or the message that shows what happened. A screenshot or a file link is better than a description. The evidence should be enough for a reviewer who was not there to understand the repeat. Do not record personal opinions about who caused the problem.
Use role labels rather than names when the log is shared beyond the immediate team. The goal is to fix the process, not to build a performance file. A log that feels like surveillance will produce vague entries and missing rows. A log that feels like a tool will produce specific ones.
Review the log weekly with examples
Set a thirty-minute weekly review with the processors and one reviewer. Read two or three entries aloud and ask what would have prevented the repeat. The discussion should end with one change, one owner, and one date. A review that only counts entries will not change the work.
Choose examples from different lanes so the group sees the whole picture. A preventable error may need a checklist change, while a guideline change may need a template update. The external event may need a borrower communication script. The mix keeps the meeting from becoming a general complaint session.
Set a threshold for process change
Do not rewrite a process for a single entry. Set a threshold, such as three similar entries in a month or a repeat that delayed a closing. When the threshold is met, open a short process note that names the cause and the proposed change. Test the change on a small group before rolling it out.
The threshold protects the team from chasing noise. It also gives a clear answer when someone asks why a familiar step changed. A process change without a logged cause is hard to defend and easy to undo. A change tied to evidence survives a busy month.
Keep guideline changes in their own view
Report guideline changes separately from preventable errors. A lender update can raise the rework count without any decline in team quality. If the two are combined, a manager may push for retraining when the real need is a faster checklist update. The separate view keeps the response proportionate.
Track the lag between the lender's announcement and the team's template update. A long lag is a process risk even when no file has failed yet. The mortgage operations support lead can own that watch and flag changes that affect active files. A short lag reduces rework before it appears.
Share the pattern with the lender partner
When the same guideline ambiguity causes repeated rework, raise it with the lender contact. Bring three examples with file dates and the exact requirement. Ask for a written clarification that the team can attach to the checklist. A clarification is more durable than a verbal answer on a call.
Keep the lender conversation factual and narrow. The goal is a usable rule, not a debate about fault. If the lender cannot clarify, record the team's interpretation and the date so future reviewers understand the choice. The loan processing support team can maintain that record as part of the checklist library.
Close the loop on the top cause
At the end of each month, pick the single largest cause and confirm whether the fix held. Compare the count before and after the change with the same definition. If the count did not move, the fix was probably aimed at the wrong step. If it moved, write a short note so the team knows the change worked. The Consumer Financial Protection Bureau's mortgage rules and the Fannie Mae Selling Guide both show how often requirements can change. A rework log is not a substitute for those sources, but it helps a team see where a source change reached the work. The best log ends with fewer repeated steps and a clearer reason for the ones that remain.