Table of contents
Lender portals are supposed to make mortgage work faster. In practice, a processor may log into four systems before lunch, search for the same file in each one, and upload a document twice because the first portal timed out. The time is real and it competes with review, borrower follow-up, and condition clearing. Nobody records it because it looks like part of the job rather than a separate task.
This protocol measures the share of a processor's available day that goes to portal navigation. It separates navigation from document review and from the actual underwriting decision. The result is a description of one team's system mix, not a claim about all processors. It is designed to be repeated after a portal change, a single sign-on rollout, or a process redesign.
Question and scope
The study asks what share of available processor time goes to lender portal navigation. Scope names the team, the lender portals, the loan stages, and the period. A team might study purchase files from application through closing during a four-week window. The result applies to that setting and should be reported with the scope.
Define available work time before collecting data. Subtract approved leave, required meetings, and system outages from paid hours. Do not subtract lunch unless the team has a written rule that lunch is unavailable for work. The denominator should be a number the team can reproduce from payroll and the calendar.
Decide whether the study covers one processor or a pod. A pod study can show how navigation moves between people, but it needs a rule for avoiding double counting. If two people log into the same portal for the same file, record the event once and note both participants. The time should be split only when the team can support the split with a log.
Defining portal navigation
Portal navigation is time spent logging in, finding a file, moving between screens, uploading a document, checking a status, or contacting portal support. The activity counts when the processor is using the portal interface rather than reviewing the document content. Reading a condition in the portal is review; finding the condition is navigation. Keep the distinction sharp so a slow review is not blamed on the portal.
The definition should exclude training, general meetings, and planned quality reviews. Those activities may improve portal use, but they are not the navigation itself. The definition should also exclude time spent reading a borrower email, even when the email links to a portal. The link click starts a navigation event, and the reading remains a separate activity.
Count the event when the record shows a start time, an end time, and the portal. A note that says "in the portal" is not enough. The note should name the task and the file. The protocol should state which evidence it accepts, such as a timer, a calendar entry, or a screen recording with consent.
Building the task categories
Use a small set of categories that the team can apply without debate. The set might include login, file search, document upload, status check, data re-entry, and support call. Add a category for system downtime only when the time is recorded separately. Too many categories produce inconsistent coding.
Pilot the categories for two days before the main sample. Ask each participant to code five events and compare the codes. If two people disagree about the same event, rewrite the definition and add an example. A category that requires a discussion every time will not survive a busy week.
Keep the category list visible during the study. A printed card or a pinned note reduces the chance that someone invents a category at the end of the day. The study measures the existing work, not a reorganization. A category that changes daily cannot be compared across participants.
Sampling the week
Use consecutive days rather than a convenience sample of quiet days. A Monday and a Friday often look different, and a closing week can distort the result. If the team cannot sample every day, use a rotating schedule that covers each weekday at least once. If a holiday shortens the week, keep the day in the series and note the reduced hours.
Ask participants to log the start and end of each navigation event, not only a daily total. A daily total is easier to recall but harder to verify. A short log with a timer or a calendar entry gives the reviewer something to check. The log should take less than a minute per event.
Include the interruptions that never become a file note. A failed upload that is retried three times is one navigation event with three attempts, not three separate tasks. The participant can log the total time and the number of attempts without recording borrower details. Use a file key or a neutral label to connect the event to the study.
Capturing the portal and task
The portal is a key variable because navigation time can vary widely between systems. Record the portal name, the task type, and whether the task succeeded on the first attempt. The success flag is more useful than a free-text description because it can be counted. It also points to a portal-specific fix.
Do not ask participants to judge whether the portal is poorly designed. That judgment invites frustration and distorts the log. Record the event and let the analysis separate recurring delays from one-time outages. A repeated delay may point to a login flow, a search field, or a file size limit.
Review the portal list with the team after the first week. Ask which portals were hard to classify and which tasks felt too small to record. The discussion often reveals a category the protocol missed. Update the protocol once, then keep it stable for the rest of the sample.
Coding and agreement
Have a second reviewer code a subsample of events without seeing the first coder's choice. Compare the results and report agreement by category. A low agreement on navigation is a signal that the definition is still ambiguous. Keep the examples that caused the disagreement.
Resolve disagreements with a written rule, not a private understanding. For example, decide whether a password reset counts as navigation or support. Write the answer in the protocol and apply it to the rest of the sample. Apply the rule to the next ten events and check whether the coders still agree.
Do not change the definition in the middle of the sample without marking the change. A mid-study change can make the share move for reasons unrelated to the work. If the team must change a rule, start a new segment and report both segments separately. Report the first segment as the baseline.
Reporting the share
Report the navigation share as a range, not a single decimal. Show the median across participants and the spread between the busiest and quietest week. A team with a twelve percent share in one week and a thirty percent share in another may have a portal outage rather than a navigation problem. With a small team, show each participant's share beside the summary.
Break the share down by portal and task type. A high share of login time may point to a single sign-on opportunity. A high share of document upload may point to a file size or format rule. A high share of status checks may point to a notification gap. The breakdown is more actionable than the total.
Pair the share with the work that was displaced. If navigation rises during closing week, show which reviews or document checks were delayed. The combination is more useful than the percentage alone because it connects time to a consequence. A displacement list with three items is enough to show the tradeoff.
What the number can change
A high navigation share does not automatically justify a new hire. It may justify a single sign-on tool, a better portal bookmark, a standard file naming rule, or a faster path to portal support. The study should list the changes that could reduce repeat navigation before it recommends additional capacity. The study should separate a system problem from a workload problem.
The mortgage operations support lead can test one change on a small group and rerun the same protocol. A single sign-on pilot is easy to test because the team can compare login time 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 portal mix that requires more time. The loan processing support team can review the portal inventory and the support contacts. The result should distinguish a system problem from a workload problem. If the change does not move the share, the next step is a capacity review rather than another bookmark.
Limits and sources of error
The study measures recorded time, not the value of the navigation. A short login that prevents a duplicate upload may be worth more than a long search that finds nothing. The share is a description of workload, not a judgment about which tasks matter. Report it with that limitation.
Recall and rounding can bias a daily log. A participant who fills in the log at the end of the day may round a nine-minute search to five or ten. Use a timer or a calendar entry when possible. Report the method so the reader can judge the precision.
The sample may miss work that happens outside the logged system. A processor who asks a colleague to check a portal may not record the request. Add a short end-of-day prompt that asks for unlogged events. The prompt improves coverage without turning the study into surveillance.
Review cadence
Repeat the study after a change to the portal, the staffing model, or the lender mix. Use the same categories and the same sampling rule so the comparison is meaningful. A share that falls while rework rises may mean the team stopped checking, not that navigation improved. A comparison across different categories is not valid, so freeze the codebook before the second round.
Share the result with the people who recorded the time. Ask which portals were hardest to use and which tasks felt avoidable. The discussion can reveal a login that nobody trusts or a status field that is always stale. The next study should test one of those findings.
End with a single sentence that states the share, the period, and the main portal task the team can fix. A precise finding with a named owner is more useful than a long report. The goal is a day that spends less time moving between screens and more time moving files. The sentence should name the change the team can make, not a cause outside its control.
Sources
- Consumer Financial Protection Bureau, Mortgage resources
- Consumer Financial Protection Bureau, Regulation X
- Consumer Financial Protection Bureau, Regulation Z
- Fannie Mae, Selling Guide
- Freddie Mac, Single-Family Seller/Servicer Guide
- U.S. Department of Housing and Urban Development, FHA Single Family Housing Policy Handbook
- Bureau of Labor Statistics, Occupational Outlook Handbook: Loan Officers
- National Institute of Standards and Technology, Cybersecurity Framework