What share of mortgage files have two owners in the same week?

Two people can work the same mortgage file without either of them knowing. One updates a condition from the queue, another answers the borrower from a personal inbox, and the system shows activity without showing a conflict. The file may still close, but the duplication wastes time and makes the record harder to trust. This protocol measures how often a file has more than one active owner within a week.

Question and scope

The question is what share of active mortgage files have two or more owners recorded in the same seven-day window. The scope should name the loan types, the processing stages, the team, and the systems that count as ownership records. A team might study purchase files between application and underwriting across a loan origination system and a shared queue. The result describes that setting and should not be read as a company-wide ownership rate.

Define the observation window before collecting data. A calendar week is easy to explain, but a rolling seven-day window may fit a team that works weekends. The important point is that every file gets the same window length and that the window is recorded. A file observed for three days cannot be compared with one observed for seven.

Separate ownership from participation. A loan officer who answers a question is participating, while a processor who is assigned the condition is owning the next action. The protocol should count only the people who are responsible for moving the file, not everyone who touched it. Without that distinction, every file will look like it has several owners.

Unit of analysis

The unit is one file in one observation window. Record the file key, the stage at the start and end of the window, the owners, and the actions that establish ownership. A file that changes stages during the window may legitimately have a new owner, so the protocol should distinguish a planned handoff from an overlapping assignment. A planned handoff should be marked so it is not counted as an accidental overlap.

Count an owner only when the record shows a named assignment or a completed action that belongs to the role. A comment that mentions a person is not enough unless the person is also assigned or acts. This rule keeps the measure tied to work rather than communication. It also reduces the chance that a courtesy copy looks like a second owner.

Keep the borrower and property out of the analysis file. Use a file key that an authorized reviewer can link back to the system of record. The mortgage operations support lead should approve the fields and the retention period. Ownership data can reveal performance, so the protocol should state how the results will be used before collection starts.

Defining ownership

Write a short definition for each role that can own a file stage. A processor owns the condition queue, a closer owns the closing schedule, and an underwriter owns the decision. A team lead may own an escalation without owning the routine work. The definition should match how the team actually assigns work, not an ideal org chart.

Decide whether the system owner field or the recorded action is the primary source. The owner field is easy to query but may be stale, while the action is closer to the work but harder to extract. Use the owner field as the starting point and the action as the check. A file where the field says one person and the actions say another is a finding about data quality.

Record the time of each ownership change. A handoff at noon is different from two owners working in parallel for four days. The timestamp lets the analysis separate a planned transition from a genuine overlap. It also shows whether the overlap is short and intentional or long and accidental.

Sampling and observation

Use all active files in the window, or a random sample with a recorded start. If the team has more files than it can review, stratify by stage so one busy stage does not dominate. Record the number of files excluded because the ownership record was incomplete. Excluding those files without reporting them will understate the problem.

Capture the owner at the start of the window and every change during it. Do not rely on a single end-of-week export, because a file that had two owners on Tuesday and one on Friday will look clean. The change log is the main evidence for the measure. If the system does not keep a change log, the team has found a data limitation worth fixing.

Ask the people who work the files to identify overlaps the system may miss. A short review at the end of the week can surface informal ownership that never reaches the queue. Record those cases separately and describe the source. The combination of system evidence and staff review gives a more honest picture than either alone.

Data quality checks

Check that every file has an owner at the start and end of the window. A file with no owner is not the same as a file with two owners, and both need separate counts. Report the no-owner count beside the overlap rate so the reader can see the full ownership picture. A team can have a low overlap rate and a high unowned rate at the same time.

Verify a subsample of ownership changes against the source records. A change may be a system reassignment, a manual update, or an automatic rule, and those have different meanings. Record the change type so the analysis can separate a planned handoff from an unexplained duplicate. The loan processing support workflow should name the approved handoff points.

Check for shared accounts and generic logins. If two people use one account, the system will show one owner even when two people work the file. The measure cannot see that overlap, so the report should state the limitation. A team that relies on shared logins may need a different observation method before trusting the result.

Analysis and reporting

Report the number of files observed, the share with two or more owners, and the median overlap duration. Add a breakdown by stage and by owner pair. A repeated pair may indicate an unclear role boundary, while a random pair may indicate a queue that is easy to pick up without assignment. The pattern matters more than the overall rate.

Separate the overlap that was planned from the overlap that was not. A closing handoff may intentionally place two people on the file for a day, while a condition queue overlap is usually accidental. Report both counts and the reason recorded in the change log. A single combined rate hides the difference between good coordination and duplicated work.

Compare the overlap rate with the rework rate and the file cycle time. If overlapping files take longer or generate more corrections, the team has evidence that the duplication costs something. If they do not, the overlap may be harmless or even useful. Avoid assuming that every overlap is a defect before the data shows a cost.

Limits and sources of error

The study measures recorded ownership, not actual work. A person can work a file without an assignment, and a person can hold an assignment without touching the file. The result should be described as recorded overlap. Use the staff review and the action log to estimate how much work is invisible to the system.

The week window can cut through a legitimate handoff. A file that changes owners on Friday and again on Monday may show two owners in one calendar week without any real overlap. Use the timestamps to exclude changes that occur at a normal stage boundary. Record the exclusion rule so another analyst can reproduce it.

Ownership definitions may change during the study if the team reorganizes. Freeze the definitions for the observation window and record any change. A file scored under an old definition should be marked and analyzed separately. Mixing definitions creates false overlap and makes the comparison unreliable.

Review cadence

Repeat the protocol after a role change, a queue redesign, or a new assignment rule. Use the same window and definitions so the comparison is meaningful. If overlap falls but the no-owner count rises, the team may have tightened assignment without covering the gaps. Report both movements and the stage where they occurred.

Share the result with the people who work the queue. Ask which overlaps were useful and which were confusing. A short discussion can reveal a handoff that the system records as an overlap but the team experiences as normal. Update the definition only when the evidence supports the change, and note the date.

End the report with one ownership question the team still cannot answer. Name the stage, the evidence needed, and the person who will bring an answer. The mortgage operations support lead can use that question to decide whether the next step is a training note, a queue change, or a system fix. The answer should change one assignment rule or one handoff note, not only produce a number.