How much of a mortgage processor's week goes to status updates?

Status updates feel like a small part of mortgage processing until the team writes down the week. A processor can spend hours repeating the same date to borrowers, loan officers, and title partners. The question is not whether those conversations matter. The question is how much of the available week they consume and what work they displace.

Question and scope

The study asks what share of a processor's available work time goes to status updates. Scope names the team, the loan stages, the channels, and the period. A team might study purchase files between application and closing during a four-week window. The result describes that setting and should not be presented as an industry average.

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 updates move between people, but it needs a rule for avoiding double counting. If two people attend the same call, the call is one event with two participants. Record the event once and note the participants separately.

Defining a status update

A status update is a communication whose main purpose is to report where a file stands or when the next action will occur. The message may go to a borrower, a loan officer, an agent, or an internal partner. It can be a call, an email, a portal message, or a note that replaces a call. The definition should exclude a request for a missing document unless the message also reports status.

Count the update when the record shows a completed communication with a time and a recipient type. A draft that was never sent is not an update. A voicemail with no note may count as an attempt if the phone system records the time and number. The protocol should state which evidence it accepts.

Separate proactive updates from reactive updates. A proactive update is sent on a schedule or at a milestone before someone asks. A reactive update answers a question that already arrived. The split shows whether the team is spending time managing expectations or repairing uncertainty.

Building the time categories

Use a small set of categories that the team can apply without debate. The set might include document review, borrower request, partner follow-up, status update, data entry, exception research, and internal meeting. Add a category for waiting only when the person is actively monitoring a system. Waiting is usually not work time.

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 new category at the end of the day. The study is measuring the existing work, not asking people to reorganize it. A category that changes every day cannot be compared across participants or months.

Sampling the week

Use consecutive days rather than a convenience sample of quiet days. A Monday and a Friday often look different from a Tuesday, 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 rather than dropping it.

Ask participants to log the start and end of each event, not only the total at the end of the day. 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 borrower call that lasts four minutes still consumes the week. The participant can log the call without recording the borrower's personal details. Use a file key or a neutral label to connect the event to the study.

Capturing interruptions

Interruptions are the most undercounted part of a processor's week. A quick question from a loan officer can turn into a fifteen-minute explanation. Ask participants to log the interruption, the person who raised it, and the work that stopped. The last field is the one that shows the cost.

Do not ask people to judge whether the interruption was necessary. That judgment invites defensiveness and distorts the log. Record the event and let the analysis separate recurring patterns from one-time events. A pattern of repeated questions may point to a missing reference or an unclear status field.

Review the interruption log with the team after the first week. Ask which events were hard to classify and which ones felt too small to record. The discussion often reveals a category that 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 status updates 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 message that confirms receipt of a document counts as a status update or a document acknowledgment. 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 and describe the change in a short note.

Report the status 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 12 percent share in one week and a 30 percent share in another may have a scheduling problem rather than a communication problem. With a small team, show each participant's share beside the summary so one heavy week is visible.

Break the share down by recipient type and trigger. Borrower updates, loan officer updates, and partner updates may have different causes. A high share of loan officer updates may point to a pipeline visibility problem. A high share of borrower updates may point to an unclear milestone message.

Pair the share with the work that was displaced. If status updates rise 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 without turning the report into a time audit.

What the number can change

A high status share does not automatically justify a new hire. It may justify a better status field, a scheduled update window, or a single source of truth that partners can read. The study should list the changes that could reduce repeat updates before it recommends additional capacity. The study should separate a visibility problem from a workload problem before it recommends a staffing change.

The mortgage operations support lead can test one change on a small group and rerun the same protocol. A scheduled update window is easy to test because the team can compare the share 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 borrower communication process that requires more time. The borrower communication support team can review the message templates and the timing. The result should distinguish a workload problem from a wording 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 conversation. A short call that prevents a complaint may be worth more than a long review that catches 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 seven-minute call 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 answers a question in a hallway or a chat thread 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 update process, the staffing model, or the partner 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 communicating, 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 events were hardest to classify and which updates felt avoidable. The discussion can reveal a template that creates a follow-up question or a status 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 driver 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 repeating status and more time moving files. The sentence should name the driver that the team can change, not a cause that sits outside its control.