Table of contents
A mortgage assistant who covers two channels can look efficient on a staffing plan and chaotic in practice. The assistant becomes the default owner of every question that arrives through either channel. A scope note makes the split visible before the first busy week, when assumptions are still cheap to correct. The note should be short enough to read in one sitting and specific enough to settle a priority question.
Name the primary queue and the secondary queue
Start with a clear statement of which queue owns the assistant's time when both are busy. A percentage split is not enough because it does not resolve a conflict at ten in the morning. Name the primary queue and the condition that allows the secondary queue to interrupt. Write the interruption condition with a time limit so the secondary queue cannot consume the primary block.
Write the condition as a test. For example, a closing-date request from the primary queue takes precedence over a routine document reminder from the secondary queue. A test lets the assistant decide without asking a manager for every conflict. It also gives the reviewer a standard to apply later.
Define the decisions the assistant can make
List the actions the assistant can complete without approval. These might include sending a standard document request, updating a received date, or routing a borrower question to the right owner. Then list the actions that require a reviewer, such as changing a condition status or promising a closing date. Put both lists in the same note so the boundary is visible without comparing two documents.
Keep the two lists short and concrete. A scope note that says "handle borrower communication" is too broad to enforce. A note that says "send the standard request template and log the reply" is testable. The narrower language also protects the assistant from being blamed for a decision nobody authorized. The HUD FHA Single Family Housing Policy Handbook is one example of a lender-specific rule set that can make one queue more complex than the other.
Write the handoff trigger
A handoff is needed when the work crosses a boundary the assistant cannot cross. Name the trigger, the receiving role, and the record that proves the handoff happened. A condition that needs an underwriter decision is a trigger. A borrower who disputes a fee is another. The assistant should not wait for a manager to notice.
The handoff record should include the file, the question, the evidence already collected, and the deadline. A message that only says "please review" forces the receiver to start over. A complete handoff respects the receiver's time and protects the assistant from a later claim that the issue was never raised. A handoff that includes the next action lets the receiver start work without reopening the entire file.
Protect focus time in both queues
Two channels can consume a day through small interruptions. Set a block of time for each queue and route non-urgent items into the next block. The schedule does not need to be rigid, but it should be visible. A borrower message that arrives during the primary block can wait unless it meets the urgent test.
Review the schedule after two weeks and compare it with the actual work. If the secondary queue consistently takes more than the planned time, the scope is wrong. Do not solve the problem by asking the assistant to work faster. Change the split, add support, or reduce the secondary queue's scope.
Set an escalation path with names
An escalation path is only real when it names a person and a response window. Write the first contact, the backup, and the situation that requires each. Include the channel to use and the information to send. A path that ends with "manager" is not a path.
Test the path with a low-stakes question during the first week. The test shows whether the backup answers and whether the response window is realistic. If the test fails, fix the path before a live escalation. The assistant should never discover the gap during a closing-week crisis.
Review the scope when volume changes
A scope note is a snapshot of the work at a point in time. When a lender adds a requirement, a new channel opens, or a team member leaves, the note may no longer fit. Put a review date on the note and name the person who owns the update. A review that happens only after a failure is too late.
The mortgage operations support lead can run the review with the assistant and the receiving reviewers. Ask what work is crossing the boundary without a handoff and what handoff is creating unnecessary delay. The answers show whether the scope is still useful. End the review with one change to the note and a date for the next check.
Watch for scope drift
Scope drift usually starts with a reasonable request. Someone asks the assistant to check one more field, send one more update, or cover one more inbox. Each request is small, and the cumulative load is not. Track the requests and review them together rather than approving them one at a time.
A simple log with the date, request, owner, and decision makes the drift visible. If the log grows faster than the team can review, the scope note is being bypassed. The fix is a short conversation about priorities, not a longer note that tries to cover every exception. A monthly count of out-of-scope requests is enough to show whether the problem is growing.
Keep the note where the work happens
Store the scope note in the same place as the queue instructions and link it from the onboarding checklist. A note in a folder nobody opens does not guide a decision. The assistant should be able to reach it from the file or the task without searching. Link the note from the queue template so a new task brings the scope with it.
The loan processing support team can use the note as part of its handoff review. A reviewer who sees an action outside the note can ask whether the note is wrong or the action is wrong. That question keeps the scope alive instead of letting it become a document that was written once and forgotten. A note that is reviewed with the people who use it is more likely to survive a busy week.