Where does idle time collect in a distributed mortgage processing team?

A distributed mortgage team can look busy in every status update while files wait for a decision. The processor is at the desk, the queue is open, and the next action belongs to someone in another time zone. Idle time in this setting is often a coordination gap rather than a personal slowdown. This protocol helps a team locate where waiting accumulates without turning the study into surveillance.

Question and scope

The question is where idle time collects across a defined mortgage processing workflow. The scope should name the queue, the roles, the working hours, and the observation period. A team might study one document review lane across four weeks of business days. The result describes that lane and should not be used to compare individual productivity.

Define idle time as a period when a role is available to work but cannot proceed on the next item because of a dependency. Waiting for a borrower, a vendor, an underwriter, or a system is idle under this definition. Time spent on training, scheduled breaks, or unrelated administrative work is not idle. The distinction keeps the measure focused on the workflow.

Unit of analysis

The unit is one waiting interval tied to a work item. The interval starts when the item becomes blocked and ends when the dependency clears or the item is reassigned. Record the item key, the role, the blocking reason, the start time, and the end time. A single item may have several waiting intervals if it moves between queues.

Keep the analysis at the item level rather than the person level. The goal is to find where work waits, not to rank specialists. A person-level report invites defensive behavior and makes the data less reliable. Use role labels instead of names in the working file, and keep the crosswalk in an approved location. The mortgage operations support lead should state this purpose before observation begins.

Defining activity states

Use a small set of states that an observer or a system can apply consistently. Ready to work, working, waiting on borrower, waiting on vendor, waiting on internal review, and waiting on system access are a practical starting set. Add a category for blocked work with no known owner. Each state should have a clear entry and exit condition.

Do not use a single busy or idle flag. It hides the difference between a processor who is waiting for an underwriter and one who has no work at all. The first is a coordination problem, while the second is a capacity or demand problem. The report should separate them because the fixes are different.

Add a state for work that is ready but unassigned. A queue can have plenty of items and still leave a specialist idle because no one has matched the items to the available role. That state looks like no work in a simple dashboard, but it is really a dispatch problem. Recording it separately gives the team a different conversation than asking people to stay busy.

Sampling and observation

Use consecutive work items from the chosen queue, or a random sample with a documented start. Capture the state changes from the system of record where possible, and use a short manual log where the system does not record them. Do not ask specialists to self-report every minute, because the logging burden will change the work. A short observation window with a trained observer is usually less intrusive than a full-day timer.

If observation is manual, sample short windows rather than the whole day. A few timed observations per role per day can show the pattern without creating a full-time timekeeping task. Record the observation window and the number of samples. The loan processing support lead should review the method for privacy and fairness before data collection.

Data quality checks

Check for intervals with no clear start or end. A waiting interval that begins before the item was assigned is probably a data error. Check for overlapping intervals on the same item and for items that appear in two queues at once. Those duplicates can make the waiting time look longer than it was. Keep the raw state log so a reviewer can see how the interval was built.

Compare the manual log with the system timestamps for a small sample. If the two disagree often, use one source consistently and report the limitation. Also check whether the observation period included an unusual event such as a system outage. That event may explain a large share of waiting and should be reported separately. A note about the event keeps a temporary problem from looking like a permanent pattern.

Analysis and reporting

Report total waiting time by reason, the median interval, and the share of items with at least one wait. Add the number of items and the number of roles in the sample. Show the result by queue and by dependency owner. A table with counts and medians is more useful than a single percentage. Include the longest interval so the reader can see whether one case drives the total.

Separate the waiting that the team can fix from the waiting that depends on an external party. A vendor delay may need a different escalation path, while an internal review delay may need a coverage change. The CFPB's supervision and examination resources emphasize documented controls, and a waiting log is useful only if it leads to an owned change. Add a proposed owner and a review date for the largest category before the report is shared.

Report the result in a way that protects the team. Use aggregate counts and role-level medians rather than individual rankings. If a manager needs to see a person-level pattern, handle it in a private conversation with the specialist and the work context. The study should improve the queue, not create a reason to hide from it. That distinction determines whether the next measurement gets honest data.

Limits and sources of error

Distributed teams may have different time zones, and a timestamp without a zone can distort the interval. Normalize all times to one zone and record the original zone. A handoff at the end of a shift can look like a long wait when it is really an overnight gap. Mark those intervals separately so the team does not try to fix a schedule that is working as designed.

The study measures waiting, not the quality of the work or the effort of the specialist. A team with little waiting may still have accuracy problems. A team with long waits may be protecting quality with a careful review. The report should avoid implying that less waiting is always better without looking at the outcome.

Review cadence

Repeat the protocol after a change to the queue, the review coverage, or the vendor escalation path. Use the same state definitions and sampling method so the comparison is meaningful. If total waiting falls but rework rises, the team may have removed a needed check. Report both the waiting and the quality measure. A balanced result is more useful than a fast queue with more errors.

Keep the state definitions, sample notes, and exceptions in one place. A later reviewer should be able to see why an interval was assigned to a reason. The borrower communication support team may also use the result to see whether borrower response time is a hidden constraint. That conversation is more productive when the data is about the workflow rather than about individuals.

End the review with one change and one measure. The change might be a named backup for a dependency, a new checkpoint in the queue, or a clearer owner for an unassigned state. The measure should be simple enough to repeat next month. Without that pairing, the study becomes an interesting report that nobody uses. A short follow-up note at the next review closes the loop.