Table of contents
A staffing request that says the team is busy invites a debate about feelings. A request that shows where files wait, which tasks repeat, and what the team stops doing when volume rises gives a manager something testable. The case does not need a perfect forecast. It needs enough evidence to show that the current queue cannot absorb the next month of work without a predictable failure.
Start with the work that never gets done
A capacity case usually starts with the visible backlog, but the more useful evidence is the work that never starts. List the checks the team skips when the day gets tight, such as the second review of a condition or the call to a title company. Then count how often those skipped checks return as rework. The pattern shows the cost of the current load better than a raw file count.
Track interruptions separately from planned work. A processor may spend a morning on borrower calls that were not scheduled, and that time disappears from a simple file count. Ask each person to log the interruption, the file, and what work was displaced. After two weeks, the log will show whether the team has a capacity problem or a priority problem.
Measure the queue, not only the hours
Record when a file enters a stage and when it leaves, then report the median and the slowest quartile. A median that looks healthy can hide a tail of files that wait for days. The tail is where lock extensions, borrower complaints, and closing delays accumulate. Report the tail beside the median so the reader sees both.
Use a short time study to describe the work inside each stage. Ask the team to sort tasks into review, request, follow-up, data entry, and waiting. A fifteen-minute increment is enough for a two-week sample. The goal is not a perfect timesheet. The goal is a defensible estimate of where the hours go.
Put a price on the delay
Late files create costs that do not appear on a processing invoice. A lock extension may carry a fee, overtime may add payroll, and a borrower may call three times because nobody gave a date. List the costs the team can verify and mark the rest as estimates. A conservative number is more persuasive than a dramatic one.
The Consumer Financial Protection Bureau's mortgage resources describe the borrower-facing timeline and the documents borrowers should expect. That context helps a manager explain why a delayed file creates more than internal friction. Use it to frame the risk, not to promise a specific outcome. Keep the citation close to the sentence it supports so the reader can check the source without leaving the case.
Separate demand growth from self-inflicted work
Not every extra hour is new demand. Count the files that returned because a request was unclear, a field was wrong, or two people edited the same record. Those returns are a process cost, and adding staff without fixing them simply buys more rework. Show the rework share beside the volume trend.
A simple rule helps the reader interpret the chart. If volume is flat and rework is rising, the case is about ownership and request quality. If volume is rising and rework is flat, the case is about capacity. If both are rising, the request should include a process fix and a staffing change.
Write the one-page case
Open with the decision you want, not with a tour of the department. State the ask, the period it covers, and the outcome it protects. Then show four numbers: incoming volume, cycle time, skipped checks, and rework. Put the detail in an appendix so the reader can verify it without reading a novel.
Describe the work the new person would own. A request for a generic extra processor is harder to approve than a request for a named queue, a defined task set, and a review owner. Explain what the team would stop doing if the request is denied, including the risks that would remain unmanaged. A clear tradeoff is more honest than a promise that nothing will change.
The loan processing support model works best when the request names the queue and the handoff, not only the headcount. A manager can then compare the ask with the work that actually arrives. The comparison also gives the finance reviewer a way to test the number without redoing the study. If the comparison shows that the queue does not need a full-time person, the case can recommend a smaller change with the same evidence.
Test the ask before you send it
Ask a peer who does not work in the queue to read the case and explain it back. If the peer cannot state the ask and the evidence in one minute, the case is too complicated. Remove any chart that does not change the decision. Keep the chart that shows the tail even if it is less flattering.
Check the numbers against the system of record before the case leaves the team. A single inconsistency gives the reader a reason to dismiss the whole request. Write down the source and date for each figure, and note any manual estimate. Transparency about the weak spot is stronger than a false precision.
Close with a decision and a review date
End with two or three options, including the option to redistribute work instead of hiring. Give each option a cost, a risk, and a review date. The reviewer may choose a smaller step, such as a temporary contractor for one queue. A good case makes that smaller step possible without forcing an all-or-nothing vote.
Schedule a review after thirty days and name the measure that will show whether the change worked. Use the same queue and rework definitions from the original case. If the measure does not move, the team should revise the diagnosis rather than ask for more headcount. The mortgage operations support lead can own that review and publish a short result to the people who approved the change.