How stable is mortgage processing capacity across a month?

A monthly capacity plan can look balanced while individual days are impossible. Files arrive in bursts, closings cluster at month end, and a single absence removes hours that the plan assumed. A daily series shows the variation that a monthly total hides. A daily series shows where the plan breaks and which work waits for the next available hour.

Question and scope

The study asks how stable processing capacity is across the working days of a month. Scope names the team, the file stages, the work types, and the month. It also names the capacity unit, such as available processing hours or review slots. A result in hours should not be compared with a result in files.

Define capacity as the hours available for processing work after meetings, leave, and required training. Do not use paid hours as a substitute because paid hours include time that cannot be used for files. The difference matters when a team has many meetings or a training week. A team with a training week may have paid hours that look normal while the available processing hours fall sharply.

Define demand as the work that must be completed on each day to meet the team's service standard. Demand is not the same as arrivals. A file that arrives on Monday may be due on Friday, and a file that arrives on Friday may be due the same day. The study should use the due date or the planned work date.

Build the daily series

Create one row per working day with the date, available hours, arriving work, due work, completed work, and the queue at the end of the day. Use a consistent unit for work, such as estimated hours or weighted files. Record the source of each number so the series can be audited. The row should also note the source of the demand estimate so the series can be checked later.

Do not smooth the series before the analysis. A three-day moving average can hide the one-day spike that caused the delay. Show the raw daily values and add a summary line only after the reader has seen the variation. The spike is often the most useful part of the study.

Mark the days with unusual events, such as a system outage, a holiday, a closing deadline, or a team absence. The marks help the reader separate a recurring pattern from a one-time event. A capacity problem that appears only on closing days is different from a problem that appears every Monday. A day with both a closing deadline and a system outage can distort the month if it is not marked.

Measure available hours

Start with the team's paid hours for the day and subtract the time that is not available for processing. The subtraction should include scheduled meetings, approved leave, training, and any known system downtime. Use the calendar and the time records, not an assumption about utilization. The rule should be written before the series starts so the team does not adjust it to fit a preferred result.

Do not subtract a standard lunch or break unless the team has a written policy that those hours are unavailable. A study that removes lunch by default may understate capacity. A study that ignores lunch may overstate it. The protocol should state the rule and apply it consistently.

Record the hours by role when the team has different review responsibilities. A processor hour and a reviewer hour are not interchangeable if the reviewer is the only person who can approve a condition. The capacity series should show the constraining role, not only the total. A single total can hide the fact that the reviewer is the constraint even when processors have room.

Measure demand

Use the due date or the planned work date to place demand on a day. A file that must be reviewed before a closing belongs on the day the review is needed, not the day it arrived. This placement shows the real peak and prevents a false sense of balance. A file that arrives early and is due late should not be counted as demand on the arrival day.

Estimate the work in hours using a simple standard, such as the median time for a file type from a recent sample. Do not use the fastest time or the slowest time. A median estimate is defensible and easy to update. Record the estimate and the sample it came from.

Separate new work from rework. Rework consumes capacity but does not add a new file, and a series that ignores it will overstate the available room. Add a rework estimate from the queue or a short sample. The estimate can be a range if the team does not track rework hours.

Analyze the variation

Calculate the mean and the range of daily utilization. A mean of 85 percent with a range from 60 to 130 percent describes a very different team from a mean of 85 percent with a range from 80 to 90. The range is the part that explains the experience of the team. A mean without the range can make an unstable month look calm and a stable month look risky.

Count the days that exceed 100 percent of available capacity. Those are the days when work must wait or someone must work late. Report the work that waited and the date it moved. A capacity study that does not show the consequence is only a chart.

Compare the peak days with the closing calendar. If the peaks align with closings, the team may need a weekly capacity plan rather than a monthly one. If the peaks do not align, the cause may be a batch of arrivals or a vendor schedule. The comparison points to the fix.

Report the result

Open with the number of working days, the mean utilization, and the range. Show the days above capacity and the work that waited. Add a short note on the largest single-day gap and what caused it. The reader should be able to see the shape of the month, not only the average.

Break the result down by role if the team has a constraining role. A processor may have room while the reviewer is fully booked. The bottleneck is the role that limits the file, not the role with the most available hours. Report the constraint explicitly.

End with one scheduling change and a review date. The change might be a weekly capacity review, a closing-date buffer, or a cross-training plan. The review should use the same daily series so the team can see whether the peaks moved. A plan that is not tested is only a hope.

Limits and sources of error

The demand estimate depends on the time standard. A standard that is too low will make the team look over capacity, and a standard that is too high will hide the problem. Use a median from a recent sample and report the range. Update the standard when the file mix changes.

The series may miss work that is done outside the queue. A processor who answers a borrower call or helps a colleague may not record the time. Add a short interruption log for the study period. The log does not need to be perfect, but it should show whether the missing work is large.

The month may be unusual. A holiday, a system conversion, or a refinance wave can make one month look different from the next. Repeat the series for at least three months before drawing a conclusion about stability. A single month is a case study, not a trend.

Review cadence

Repeat the daily series each month and compare the shape, not only the mean. A team that learns to see the peak before it arrives can move work earlier or adjust the closing calendar. The mortgage operations support lead can own the monthly review. The review should ask whether the peak moved or simply became smaller.

Share the series with the people who work the queue. Ask which day felt the most overloaded and what they stopped doing. The answer often explains a gap that the data alone cannot show. The loan processing support team can test a small scheduling change on the next peak.

End with the day of the month that most often exceeds capacity and the change that will be tested before the next peak. The goal is a plan that reflects the real variation, not a monthly average that never happened. The next peak is the test, and the owner should be named before the month begins. The team should record the result on the same chart so the next month starts with a visible comparison.