What share of mortgage processor time goes to exception research?

Exception research is the quiet work that happens when a file does not fit the checklist. A borrower name differs by one letter, a bank statement covers the wrong month, or a lender's condition refers to a form nobody can find. The processor leaves the routine path and starts tracing. The time is real, but it rarely appears in a pipeline report.

This study protocol measures the share of available processor hours that goes to exception research. It separates research from routine document review, borrower follow-up, and data entry. The result is a description of one team's week, not an industry average. The protocol is designed to be repeated after a process change.

Question and scope

The study asks what share of a processor's available work time goes to exception research. Scope names the team, the loan stages, the channels, and the period. A team might study purchase files from application through condition clearance during a four-week window. The result applies to that setting and should be reported with the scope.

Define available work time before collecting data. Subtract approved leave, required meetings, and system outages from paid hours. Do not subtract lunch unless the team has a written rule that lunch is unavailable for work. The denominator should be a number the team can reproduce from payroll and the calendar.

Decide whether the study covers one processor or a pod. A pod study can show how research moves between people, but it needs a rule for avoiding double counting. If two people work the same exception, record the event once and note both participants. The time should be split only when the team can support the split with a log.

Defining exception research

Exception research is work that leaves the standard checklist to resolve a mismatch, a missing record, or an unclear requirement. The processor may search the lender guide, call a partner, compare documents, or reconstruct a file history. The activity counts when the normal next step cannot proceed without the research. A routine check that stays inside the checklist does not count.

The definition should exclude training, general meetings, and planned quality reviews. Those activities may improve exception handling, but they are not the work itself. The definition should also exclude a borrower follow-up that follows a known script. A follow-up becomes research only when the processor must investigate why the script does not fit.

Count the event when the record shows a start time, an end time, and the question being researched. A note that says "looked into it" is not enough. The note should name the mismatch and the source consulted. The protocol should state which evidence it accepts.

Building the categories

Use a small set of categories that the team can apply without debate. The set might include document review, borrower follow-up, partner follow-up, exception research, data entry, and internal meeting. Add a category for system downtime only when the time is recorded separately. Too many categories produce inconsistent coding.

Pilot the categories for two days before the main sample. Ask each participant to code five events and compare the codes. If two people disagree about the same event, rewrite the definition and add an example. A category that requires a discussion every time will not survive a busy week.

Keep the category list visible during the study. A printed card or a pinned note reduces the chance that someone invents a category at the end of the day. The study measures the existing work, not a reorganization. A category that changes daily cannot be compared across participants.

Sampling the week

Use consecutive days rather than a convenience sample of quiet days. A Monday and a Friday often look different, and a closing week can distort the result. If the team cannot sample every day, use a rotating schedule that covers each weekday at least once. If a holiday shortens the week, keep the day in the series and note the reduced hours.

Ask participants to log the start and end of each research event, not only a daily total. A daily total is easier to recall but harder to verify. A short log with a timer or a calendar entry gives the reviewer something to check. The log should take less than a minute per event.

Include the interruptions that never become a file note. A quick question from a loan officer can turn into a fifteen-minute search. The participant can log the question without recording borrower details. Use a file key or a neutral label to connect the event to the study.

Capturing the trigger

The trigger is the mismatch or question that started the research. Record the trigger type, such as name mismatch, missing page, unclear guideline, or conflicting record. The trigger type is more useful than a free-text description because it can be counted. It also points to the process fix.

Do not ask participants to judge whether the research was avoidable. That judgment invites defensiveness and distorts the log. Record the event and let the analysis separate recurring triggers from one-time events. A repeated trigger may point to a checklist gap or an unclear field.

Review the trigger list with the team after the first week. Ask which triggers were hard to classify and which ones felt too small to record. The discussion often reveals a category the protocol missed. Update the protocol once, then keep it stable for the rest of the sample.

Coding and agreement

Have a second reviewer code a subsample of events without seeing the first coder's choice. Compare the results and report agreement by category. A low agreement on exception research is a signal that the definition is still ambiguous. Keep the examples that caused the disagreement.

Resolve disagreements with a written rule, not a private understanding. For example, decide whether a call to confirm a lender's fax number counts as research or partner follow-up. Write the answer in the protocol and apply it to the rest of the sample. Apply the rule to the next ten events and check whether the coders still agree.

Do not change the definition in the middle of the sample without marking the change. A mid-study change can make the share move for reasons unrelated to the work. If the team must change a rule, start a new segment and report both segments separately. Report the first segment as the baseline.

Report the exception research share as a range, not a single decimal. Show the median across participants and the spread between the busiest and quietest week. A team with a ten percent share in one week and a twenty-eight percent share in another may have a scheduling problem rather than a research problem. With a small team, show each participant's share beside the summary.

Break the share down by trigger type and file stage. A high share of name mismatches may point to an intake rule. A high share of unclear guidelines may point to the checklist library. A high share late in the file may point to a missing condition note. The breakdown is more actionable than the total.

Pair the share with the work that was displaced. If research rises during closing week, show which reviews or document checks were delayed. The combination is more useful than the percentage alone because it connects time to a consequence. A displacement list with three items is enough to show the tradeoff.

What the number can change

A high research share does not automatically justify a new hire. It may justify a better checklist, a clearer intake field, or a faster path to a lender contact. The study should list the changes that could reduce repeat research before it recommends additional capacity. The study should separate a knowledge problem from a workload problem.

The mortgage operations support lead can test one change on a small group and rerun the same protocol. A checklist fix is easy to test because the team can compare the trigger mix before and after. The test should run long enough to cover a normal closing cycle. Keep the test group small enough that the rest of the team can continue the normal work.

If the share stays high after the change, the team may have a genuine capacity gap or a partner process that requires more time. The loan processing support team can review the escalation path and the lender contacts. The result should distinguish a workload problem from a knowledge problem. If the change does not move the share, the next step is a capacity review rather than another template edit.

Limits and sources of error

The study measures recorded time, not the value of the research. A short search that prevents a compliance error may be worth more than a long review that finds nothing. The share is a description of workload, not a judgment about which work matters. Report it with that limitation.

Recall and rounding can bias a daily log. A participant who fills in the log at the end of the day may round a nine-minute search to five or ten. Use a timer or a calendar entry when possible. Report the method so the reader can judge the precision.

The sample may miss work that happens outside the logged system. A processor who asks a colleague across the room may not record it. Add a short end-of-day prompt that asks for unlogged events. The prompt improves coverage without turning the study into surveillance.

Review cadence

Repeat the study after a change to the checklist, the staffing model, or the lender mix. Use the same categories and the same sampling rule so the comparison is meaningful. A share that falls while rework rises may mean the team stopped researching, not that the process improved. A comparison across different categories is not valid, so freeze the codebook before the second round.

Share the result with the people who recorded the time. Ask which triggers were hardest to classify and which searches felt avoidable. The discussion can reveal a checklist item that creates a follow-up or a field that nobody trusts. The next study should test one of those findings.

End with a single sentence that states the share, the period, and the main trigger the team can verify. A precise finding with a named owner is more useful than a long report. The goal is a week that spends less time searching and more time moving files. The sentence should name the trigger the team can change, not a cause outside its control.