How often do borrower documents need a third request before they arrive?

Borrower document requests often look simple in the file and messy in practice. A processor asks for a bank statement, the borrower sends a screenshot, and the processor asks again for the full statement. By the third request, the file has lost several days and the borrower is frustrated. The team may remember the pattern but rarely measures it.

This protocol measures how often a document reaches a third request before it arrives in an acceptable form. It treats the request as the unit of analysis and tracks each round with a date, channel, and reason. The result is a description of one team's borrower journey, not an industry benchmark. It is designed to be repeated after a change to the request script, the portal, or the review rule.

Question and scope

The study asks what share of requested documents require a third request before an acceptable version arrives. Scope names the team, the loan stages, the document types, and the period. A team might study income and asset documents from application through condition clearance during a six-week window. The result applies to that setting and should be reported with the scope.

Define the population before sampling. Include every document request sent to a borrower during the period, not only the requests that eventually arrived. Excluding the documents that never arrived would overstate the team's success and hide the hardest cases. The denominator should be a count the team can reproduce from the system.

Decide whether the study covers one channel or all channels. A portal request and a phone request can produce different behavior, and the mix may change during the year. If the team uses several channels, report the share by channel as well as the total. A single blended number can hide a channel-specific problem.

Defining a request round

A request round begins when the team sends a clear request for a specific document and ends when the team sends the next request for the same document. The round includes the borrower's response, the review, and the reason for the next request. A request that is sent but never delivered should be marked separately rather than counted as a round. Keep the round boundary in the log so a second reviewer can see where one request ended and the next began.

The request must name the document and the reason. A message that says "send your documents" is too vague to count because the borrower cannot know what is missing. A request for the July bank statement for account ending 4412 is specific enough. The protocol should include examples of acceptable and unacceptable requests.

A document is acceptable when it passes the first review under the written standard. The standard should name the required pages, the date range, and the legibility rule. If the reviewer rejects a document for a reason outside the standard, the rejection should be flagged as a review exception, not counted as a normal round. This distinction keeps the measure about the request process rather than individual reviewer preference.

Counting rounds consistently

Count each document once and assign the highest round it reached. A document that arrived after two requests is a second-round document, even if the borrower sent several partial files. A document that required a third request and then arrived is a third-round document. A document that never arrived after three requests is a non-arrival and should be reported separately.

Do not count a reminder as a new round unless it contains a new request. A system reminder that repeats the same link is a nudge, not a round. A message that clarifies the document or changes the deadline is a new round because it gives the borrower new information. Write the distinction into the protocol before collecting data.

Count the rounds from the first request, not from the first response. A borrower who responds quickly but with the wrong document still belongs in the round count. Counting from the response would make a fast but incomplete reply look like a success. The measure is about the number of requests needed for an acceptable document.

Sampling the borrower journey

Use consecutive weeks rather than a convenience sample of quiet days. Document behavior can change around a closing date, a holiday, or a month end. A sample that misses those periods will understate the problem. If the team cannot cover every day, use a rotating schedule that includes each weekday at least once.

Include files from different loan types and channels. A purchase file with a real estate agent involved may move differently from a refinance file. A first-time borrower may need more explanation than an investor. The sample should reflect the team's actual mix, and the report should show the mix so the reader can judge the comparison.

Record the request date, the channel, the document type, the borrower response date, and the review outcome. Add the reason for the next request in a short category such as wrong document, missing page, illegible scan, or expired statement. The reason is more useful than a free-text note because it can be counted. Keep the note short enough that the processor can complete it during the review.

Separating channel from behavior

Channel effects are easy to confuse with borrower behavior. A portal request may produce a faster upload because the borrower can see the document list. A phone request may produce a faster answer but a slower upload because the borrower has to find the document later. The study should report the channel beside the round count.

Compare the same document type across channels where possible. A bank statement requested by portal and by phone can be compared if the team has enough volume. The comparison should include the elapsed days and the rejection reason. A difference in one document type is a clue, not proof of a channel effect.

Do not attribute a third request to the borrower without checking the request quality. A vague request, a broken link, or a portal that rejects a valid file can cause the same behavior as a forgetful borrower. The study should sample a few request messages and review them against the standard. The result may show that the team, not the borrower, is driving the repeat.

Measuring the interval between requests

The interval between requests is a useful companion to the round count. A third request that follows the second within an hour may mean the first review was incomplete. A third request that follows after five days may mean the borrower needed a reminder. The interval helps the team choose the right fix.

Report the median interval and the range, not only the average. A few very long intervals can pull an average away from the typical experience. The median shows what most borrowers experience, and the range shows the outliers. With a small sample, show each interval rather than a single summary.

Pair the interval with the borrower's response time. A team that sends requests quickly but reviews slowly will look different from a team that reviews quickly but sends unclear requests. The pair of measures separates the two problems. It also gives the team a fair basis for changing the script or the review sequence.

Reporting with limits

Report the share of documents by round, the share that never arrived, and the share that needed a third request. Break the third-request share down by document type, channel, and reason. Show the sample size and the period beside every number. A percentage without a denominator is not a finding.

State the limits clearly. The study measures recorded requests, not every conversation. A processor who asks for a document in passing may not log it, and a borrower who sends a document to a personal email may not appear in the portal. The result is a lower bound on the true repeat rate in some cases and an upper bound in others.

Do not compare the result with an industry average unless the definitions match. Most public mortgage data does not report request rounds, and a comparison with a different definition would be misleading. Compare the team with itself over time, using the same protocol and the same categories. Keep the historical result visible so a future change can be judged against a stable baseline.

What the number can change

A high third-request share does not automatically justify more staff. It may justify a clearer request template, a better portal, or a review checklist that catches missing pages before the request goes out. The study should list the changes that could reduce repeat requests before it recommends additional capacity. The team should separate a communication problem from a workload problem.

The mortgage operations support lead can test one change on a small group and rerun the protocol. A request template with a document checklist is easy to test because the team can compare the round count 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 population that needs more support. The loan processing support team can review the follow-up script and the channel mix. The result should distinguish a communication problem from a workload problem. A measure that leads to the wrong fix is worse than no measure at all.