How much appraisal scheduling time is lost to portal resets?

Appraisal scheduling looks like a short task on a process map. A processor opens a portal, enters the property and contact details, chooses a vendor, and confirms the order. In practice, the work is interrupted by session timeouts, duplicate order screens, and portals that lose a selection after a page refresh. The time lost is hard to see because it is spread across the day.

This study measures how much scheduling time is lost to portal resets. It separates reset time from ordinary waiting time so the result does not blame a vendor for a slow response. The protocol is designed for a small operations team that can time a sample of orders without buying new software. The result helps the team decide whether to change the workflow, the vendor, or the training.

Question and scope

The question is how much active scheduling time is lost when a portal reset interrupts the work. The scope names the team, the lenders, the vendors, the order types, and the period. A team might study appraisal orders during a six-week window. The result applies to that setting and should be reported with it.

Define active scheduling time as the time a person spends working on the order, including entry, verification, and confirmation. Exclude time waiting for a vendor response or a borrower call. The distinction matters because a reset is a workflow interruption, while a wait is a queue delay. Only the reset time belongs in the headline measure.

Define a portal reset as any event where the session or order state is lost and the person must re-enter information or restart a step. A login timeout, a page refresh that clears a form, a duplicate order screen, and an error that requires a new session all qualify. A slow page load is not a reset unless it forces re-entry. The definition should be written down so two observers count the same event.

Why resets are easy to miss

A reset often lasts a few minutes, so it does not appear in a monthly report. The person simply logs in again and re-enters the data. When the same reset happens several times a day, the minutes add up to a meaningful share of the scheduling workload. The cost is hidden in the gap between the process map and the actual day.

Resets also create errors. A person who re-enters data after a timeout may mistype a contact number or choose a different property. The error may surface later as a failed inspection or a borrower complaint. The cost of the reset is therefore larger than the minutes it consumes.

The measure is not an argument for blaming the portal vendor. A portal may reset for a valid security reason, and the team may be able to reduce the impact with a different workflow. The study should describe the event and the recovery, not assign fault. The purpose is to find a practical change.

Timing the order

Use a simple timer at the start and end of the active work. Record the start when the person opens the order and the end when the confirmation is saved. If the work is interrupted, pause the timer and record the reason. A stopwatch or a shared spreadsheet is enough for a small sample.

Record each reset as a separate event with its own start and end. Include the action that triggered the reset and the recovery step. For example, note "session timeout during contact entry, re-entered three fields" rather than "portal slow." The detail helps the team compare events and choose a fix. A short note also helps the team see whether the same step triggers the reset each time.

Do not rely on memory at the end of the day. A person who handled ten orders will not remember the minutes accurately. Time the sample while the work is happening, or ask the person to record the event immediately. A consistent method is more important than perfect precision.

Sampling orders

Sample orders across vendors, loan types, and processors. A sample from one vendor will not show the range of portal behavior. Include orders placed at different times of day because a reset may be more common during a busy period. Record the date and the order type for each sample.

Use a fixed sample size, such as twenty orders, and report the sampling rate. A small sample has a wide margin of uncertainty, and the report should say so. Do not present a twenty-order sample as a precise measure of the whole month. The goal is a useful estimate, not a false sense of accuracy.

Include orders that were scheduled without a reset. The comparison shows the share of orders affected and the time per affected order. A study that only measures reset events cannot say how common they are. The denominator should be all sampled orders, not only the problematic ones.

Separating wait time from work time

Wait time is the time between a request and a vendor response. It may be long and frustrating, but it is not active work. Work time is the time a person spends on the order. The study should report both so the team does not confuse a slow vendor with an inefficient portal.

A reset can create wait time if the person must stop and ask for help. Record that time separately from the re-entry time. The re-entry is active work, while the help request may be a queue delay. The distinction helps the team decide whether to fix the portal or improve the support path.

Include the time to log back in and find the order again. That recovery time is part of the reset cost even if it feels like a separate task. A person who spends two minutes finding the right screen has lost two minutes to the reset. The timer should cover the full recovery.

Reporting the result

Report the total reset time, the share of sampled orders affected, and the median time per affected order. A total alone can be misleading because one long reset can dominate the result. The median shows the typical experience, while the total shows the aggregate cost. Report both.

Break the result down by vendor and by reset type. A vendor with frequent session timeouts may need a different login workflow. A vendor with duplicate order screens may need a different entry sequence. The breakdown is more actionable than a single number.

Pair the reset time with the error rate. A reset that causes a wrong contact number is more costly than a reset that only repeats a page. The study should record any correction or rework that followed the reset. The combination helps the team prioritize the most expensive interruptions.

What the team can change

A short checklist before starting the order can reduce resets. Confirm the login, the borrower contact, and the property details before entering the portal. Save the order at each step if the portal allows it. These steps take seconds and can prevent a full re-entry.

A different browser or a wired connection may reduce timeouts, but the team should test the change before rolling it out. A vendor may also have a bulk upload or a saved template that removes repeated entry. Ask the vendor for the options rather than assuming the portal cannot change. The test should record whether the change reduced resets without adding a new error.

The loan processing support team can test one workflow change on a small group and rerun the time study. The mortgage operations support lead can review the intake path if the resets cluster around one portal. A pre-entry checklist is easy to test because the team can compare reset counts before and after. The test should run long enough to cover a normal scheduling cycle. Keep the test group small enough that the rest of the team can continue the normal work.

Limits and sources of error

The study measures recorded reset time, not every interruption. A person who works around a reset without recording it may understate the cost. A person who records every minor delay may overstate it. The protocol should define the event clearly and apply the definition consistently.

The observer effect can bias the timing. A person who knows the order is being timed may work differently. Use a sample that includes both observed and self-reported orders, and compare the results. If the two methods differ widely, report both rather than choosing the more convenient one.

The sample may miss orders placed by a different team or channel. A loan officer who places an order directly may not appear in the processing log. Add a short note to the study about coverage and any known gaps. A clear limitation is more credible than a complete-looking number.

Review cadence

Repeat the study after a portal update, a vendor change, or a workflow change. Use the same definitions and the same sampling rule so the comparison is meaningful. A reset time that falls while total scheduling time rises may mean the team is doing more work elsewhere. A comparison across different definitions is not valid, so freeze the codebook before the second round.

Share the result with the people who recorded the events. Ask which resets were most frustrating and which recovery steps worked. The discussion can reveal a saved field or a browser setting that nobody documented. The next study should test one of those findings.

End with a single sentence that states the reset time, the period, and the main workflow change the team can make. A precise finding with a named owner is more useful than a long report. The goal is a scheduling task that finishes without a restart. The sentence should name the change the team can make, not a cause outside its control.