What share of borrower document requests need a second explanation?

A document request can be clear to the processor who wrote it and confusing to the borrower who receives it. The borrower sends a partial packet, the processor explains the request again, and the file loses a day. Measuring how often that happens shows whether the request or the follow-up is the problem. The measure gives the team a way to test the request instead of blaming the borrower for a slow response.

Question and scope

The study asks what share of borrower document requests require a second explanation before the borrower sends the requested evidence. Scope names the request types, the loan stages, the channels, and the period. A request for a bank statement is different from a request for a self-employed tax return. Report the types separately.

Define the first request as the initial message that asks for the document. A reminder that repeats the same request is not a new request unless it adds a requirement. The study should count the request once and track the follow-up events that follow. This prevents a reminder schedule from inflating the denominator.

Decide whether to include requests sent by phone. A phone request can be clear even when no written message exists. If the team uses calls, record the call and the note that documents it. The protocol should state how a phone request is identified and how the follow-up is captured.

Define a second explanation

A second explanation is a follow-up message or call that explains the same request again because the borrower did not understand or sent the wrong document. The explanation may add an example, clarify a form, or correct a misunderstanding. A simple acknowledgment that the document arrived is not a second explanation. The code should also record whether the borrower asked a question or simply sent the wrong document.

Count a second explanation when the borrower asks what is needed, sends a document that does not satisfy the request, or says the request is unclear. Do not count a borrower who asks an unrelated question. The coding should distinguish a clarity problem from a new issue. Keep the examples in the codebook.

Separate a second explanation from a collection follow-up. A follow-up that asks whether the borrower sent the document is not an explanation unless it restates the requirement. The distinction matters because collection follow-up may be necessary even when the request was clear. The study should not blame the wording for a borrower who is simply late.

Unit of analysis

The unit is one request on one file. A file with three requests contributes three units, and the report should also show the file-level share. That prevents a file with many small requests from dominating the result. Record the file key, the request type, the channel, and the first request date.

Record the borrower's response and the processor's next message. The response can be a document, a question, or a request for more time. The processor's message can be a clarification, a reminder, or a new request. The sequence shows whether the second explanation was caused by the request or by the response.

Keep borrower identity out of the working table. Use a file key and a request key that an authorized reviewer can link back to the system of record. The borrower communication support lead should approve the fields and the retention period. A short retention rule prevents the study file from becoming a second borrower record.

Sample the requests

Use consecutive requests from a defined window or a random sample with a recorded start. Include each channel and each request type. If the sample includes only written requests, the result will not describe phone requests. Add a separate count for phone requests if the team uses them.

Include requests from borrowers with different levels of experience. A first-time homebuyer may need more explanation than a borrower who has purchased before. The protocol can record a simple experience flag without collecting sensitive details. The flag helps the reader see whether the result is concentrated in one group.

Record the request length and the number of documents requested. A long request with five attachments may be harder to understand than a short request with one. The analysis can compare the second-explanation rate by length. A pattern may point to a formatting fix rather than a wording fix.

Code the request

Read the first request and ask whether it names the document, the time period, the format, and the reason. A request that omits the period may produce a document for the wrong year. A request that omits the format may produce a photo when the lender needs a PDF. The codebook should define each missing element.

Use a plain-language check alongside the content check. Look for long sentences, internal jargon, and ambiguous pronouns. A request that says provide the required documentation without naming the document is not clear. The check should be simple enough for a second reviewer to apply.

Have a second reviewer code a subsample. Compare the codes and discuss the disagreements. A disagreement about whether a request was clear may point to a missing example. Update the codebook and keep the examples for the next round. The goal is a shared standard, not a perfect score.

Analyze the result

Report the share of requests with a second explanation by request type, channel, and length. A high share for one document type may point to a form that borrowers consistently misunderstand. A high share for one channel may point to a template that works in email but not in the portal. The request type view is more actionable than a single overall share because each type has a different fix.

Compare the second-explanation rate with the time to receive the document. A request with a high explanation rate and a long receipt time is a strong candidate for a rewrite. A request with a high explanation rate but a short receipt time may be clear enough once the borrower asks. The combination prevents a false priority.

Look at the explanations that worked. A short example or a labeled image can resolve a request that a paragraph could not. Keep the examples that borrowers responded to and use them in the next template. The study should produce a better request, not only a count.

Report the result

Open with the share, the sample size, and the request types included. Show the top three reasons for a second explanation: wrong period, wrong document, or unclear format. Each reason should have a short example with borrower details removed. The reader should be able to see the fix.

Add a section on the requests that needed no explanation. A clear example is useful for the team and for the training material. The example should show the document name, the period, the format, and the channel. Do not use a real borrower's message.

End with one template change and a review date. The change might be a numbered list, a sample image, or a required period field. The review should use the same coding rule so the comparison is meaningful. A result without a change is only a description.

Limits and sources of error

The study measures requests that produced a visible follow-up. A borrower who was confused but never asked may not appear in the data. Add a short survey or a call sample to estimate the hidden confusion. Report the estimate as an estimate, not as a measured share.

The coder's judgment about clarity can vary. A request that is clear to an experienced processor may be unclear to a first-time borrower. Include a borrower-facing review or a plain-language reviewer in the coding. The added perspective reduces the risk of grading your own work.

The sample may overrepresent requests that were easy to find in the system. A request sent by phone or chat may be missing from the record. Add a channel inventory before sampling and note the coverage. The report should say which channels are included and which are not.

Review cadence

Repeat the study after a template change, a portal change, or a change in the borrower population. Use the same definitions and the same request types so the comparison is meaningful. A share that falls while receipt time rises may mean the request became clearer but the borrower still needs help. A change in the borrower population can move the share even when the template is unchanged, so note it.

The loan processing support team can test a revised request on a small group before rolling it out. Compare the second-explanation rate and the time to receipt. If both improve, the change is worth keeping. If only one improves, the team should decide which outcome matters more.

End with the request type that produces the most explanations and the wording change that will be tested next. A clear request respects the borrower's time and the processor's time. The measure is useful only when it leads to a message that is easier to answer. The next test should use a request type with enough volume to show a difference within a month.