How many touches does a mortgage condition need before it clears?

A condition can clear in one exchange or take a dozen messages across three channels. The difference matters because each touch consumes attention and adds a chance for the record to drift. This protocol counts the touches a condition needs before it clears, then separates the borrower's work from the team's work and the vendor's work. The result shows where a simple condition becomes an expensive one.

Question and scope

The question is how many recorded touches a mortgage condition requires between the first request and the clearing note. The scope names the loan types, the condition categories, the channels, and the clearing definition. A team might study income and asset conditions on purchase files during the processing stage. The result describes that setting and should not be generalized to every condition or every borrower.

Define a touch before collecting data. A touch is a recorded action that moves the condition forward, such as a request sent, a document received, a review completed, or an escalation made. A status update with no action is not a touch. A note that only says still waiting is a record of time passing, not a contact.

Define clearing as the point when an authorized reviewer accepts the evidence and records the condition as satisfied. A condition that is cleared and later reopened should be counted separately, with the date of the reopening. The protocol should not merge a first clear with a re-clear because the work is different. A reopened condition should keep the original clear date and add the new work as a separate segment.

Unit of analysis

The unit is one condition on one file. A file with five conditions contributes five units, and the report should also show the file-level count. That prevents a file with many small conditions from dominating the analysis. Record the file key, the condition key, the category, the first request time, the clear time, and the touch count.

Record each touch with a timestamp, a channel, and an actor type. Actor types can be borrower, processor, underwriter, vendor, or system. A message from the borrower and a message to the borrower are different touches, even when they occur in the same thread. The actor type lets the analysis separate the work that the team controls from the work it waits on.

Keep borrower identity out of the working file. Use keys that an authorized reviewer can link back to the system of record. The loan processing support lead should approve the fields and the retention period. Touch data can look like a performance measure, so the protocol should state that the purpose is process improvement rather than individual scoring.

Defining a touch

Count a touch when the record shows a completed action with a time and an actor. A request sent through a portal counts, and so does a phone call with a written note. A voicemail with no note may count as an attempt if the calling system records it, but the protocol should say so. Ambiguous events should not be counted until the rule is clear.

Do not count automated reminders as separate touches unless the team uses them as a deliberate contact. A system that sends the same reminder every day can inflate the count without adding work. Report automated reminders separately and keep the manual touch count distinct. The reader should see both numbers.

Group touches by direction and purpose. A borrower upload, a team review, and a vendor response are different kinds of work, even when they happen on the same day. The grouping shows whether the condition is slow because the borrower is unresponsive or because the team keeps returning to the same file. That distinction is the main value of the measure.

Sampling and observation

Use consecutive conditions from a defined window, or a random sample with a recorded start. Include conditions from each category and each processor if the volume allows. If the sample includes only conditions that cleared, the result will understate the touches for conditions that are still open. Add a separate count of open conditions and their current touch count.

Record the observation end date for every condition. A condition that is still open at the end of the window has a touch count that is not final. Mark it as open and analyze it separately. Treating an open count as a final count understates the work that may still be required.

Capture the source of each touch from the system record rather than from memory. A processor may remember a call that was never logged, but the study can only count what the record shows. If the team believes the record is incomplete, add a short review sample to estimate the missing touches. Report the estimate as an estimate, not as a measured count.

Data quality checks

Check that every condition has a first request, a clear date or open status, and at least one touch. A condition with no touch cannot be scored, and a condition with a clear date before the first request has a data problem. Mark those rows separately and review the source. A high error rate may point to a workflow that allows status changes without a note.

Compare a subsample of touch counts with a second reviewer. Reviewers may disagree about whether a brief acknowledgment counts as a touch. Report agreement and keep examples of the disagreements. The mortgage operations support lead can use the examples to refine the definition before the next period.

Check for duplicate records created by the same action. A portal upload may create a notification and a file note for the same event. Counting both would double the touch. The protocol should name the primary record for each action and use the duplicate only as a cross-check.

Analysis and reporting

Report the median and spread of touches by condition category, borrower responsiveness, and actor mix. A median of three touches can hide a group of conditions that needed ten. Show the share of conditions that needed more than five touches and more than ten. Those thresholds make the tail visible without pretending there is a universal target.

Separate the touches that added evidence from the touches that only repeated a request. A condition with six touches may have only two evidence events and four reminders. The ratio shows whether the work is document collection or follow-up. That distinction helps the team decide whether to change the request, the reminder schedule, or the review step.

Compare touch count with the time to clear. A high touch count with a short clear time may be a busy but responsive process, while a low touch count with a long clear time may be a stalled file that nobody worked. Report both measures together. Neither one alone describes the condition accurately.

Limits and sources of error

The study counts recorded touches, not effort. A single call can resolve a complex question, while five short messages can add little. The count is a proxy for coordination work, not a direct measure of cost. Use the time and the evidence events alongside the count when the team discusses workload.

The sample may exclude conditions that were never requested because the processor missed them. Those conditions do not appear in the touch data, even though they affect the file. Add a count of conditions found during a file review that had no request record. That count gives the reader a sense of the work outside the measured flow.

Definitions can drift during the observation period as the team learns the protocol. Freeze the definition for the main sample and record any change. A condition scored under an old rule should be marked and analyzed separately. Mixing definitions creates false variation and weakens the comparison.

Review cadence

Repeat the protocol after a change to the request template, the reminder schedule, or the condition categories. Use the same definitions and sampling rule so the comparison is meaningful. If the touch count falls but the clear time rises, the team may have reduced reminders without improving the evidence. Report both movements.

Share the result with the people who work the conditions. Ask which categories produce the most repeat touches and what the record does not capture. A short discussion can reveal a missing field or a request that borrowers consistently misunderstand. The borrower communication support team can test a revised request on a small group.

End the report with the category that still needs the most touches and the reason the team can verify. Name the evidence needed and the owner who will bring it. The goal is a condition process that clears with fewer avoidable contacts and a record that shows what actually happened. A condition that needs many touches for a simple document is a request problem, not a borrower problem.