Short answer: Mortgage lead distribution rules should identify the source context, the accountable first reviewer, the fallback owner, the next action, and the exception path before a record reaches the team. A workable rule lets a manager explain why a record went where it did without reconstructing the decision from memory.
A source label is not an ownership rule. Referral, web, event, past-client, and purchased-source records can all need different handling, but the source alone does not answer who must act, what counts as a handoff, or what happens when the record is incomplete.
In this guide
What a usable lead-distribution rule must answer
| Question |
Write the answer down |
What to check later |
| What arrived? |
The source, capture date, relationship context, and any information needed to place the record in the correct queue. |
The source and record history are visible; the team is not guessing from a name or a note. |
| Who reviews first? |
A named owner or queue, plus the decision that put the record there. |
The record has one accountable first reviewer, not an implied owner. |
| What is the next action? |
The first review step and where the result is recorded. |
A manager can see whether the action was completed, deferred, or needs a decision. |
| Who covers an exception? |
A fallback owner for unavailability, conflict, missing data, or an out-of-scope record. |
The exception is visible rather than silently returned to the same queue. |
| Who resolves a duplicate? |
The person or role that decides whether an existing relationship changes the normal path. |
The record history explains the resolution and does not create competing follow-up. |
Start with decisions, not automation
Teams often try to write a rule in a tool before agreeing on the operating decision. Start with the practical questions: Does a prior relationship change the handoff? Is a territory, branch, or specialty relevant to the first review? What happens after hours? Which role can correct a bad assignment? A workflow can support a clear decision; it cannot make an unclear decision accountable.
Keep the distinction between assignment and contact approval clear. A route identifies who is responsible for the record. It does not replace the organization’s process for consent, licensing, communication review, or other policies that may apply. Confirm those requirements with the people responsible for them.
Five-record review
Before using a new or revised distribution rule, work through five de-identified examples with the person who owns the exception path. The point is to find ambiguity before it becomes a borrower or partner experience.
- Ordinary intake: a complete record from a common source. Confirm the owner, next action, and review history.
- Existing relationship: a record that appears to match a borrower, referral partner, or prior conversation. Confirm who decides whether that relationship changes the normal route.
- Unavailable owner: a record assigned when the expected reviewer cannot take it. Confirm that the fallback is a named person or queue with a visible handoff.
- Incomplete record: a record missing the information the rule relies on. Confirm it reaches a review path rather than being assigned on an assumption.
- Conflicting record: a duplicate or two source signals that point to different owners. Confirm the resolver, the decision record, and the final owner.
For each example, capture only what the team needs to audit the route: record identifier, source, initial owner, final owner, next action, exception type, and the person who made the correction. Do not use a test as an excuse to collect or expose extra borrower information.
Build a small exception queue on purpose
A good lead-distribution process has a place for records that do not fit the ordinary rule. That queue should have a named reviewer, a reason code the team can understand, and a review rhythm. Examples include an existing relationship, missing source information, a duplicate record, a geography or licensing question, and an unavailable primary owner.
The audit is not a scorecard for individual loan officers. It is a way to see whether the written rule still matches the business. When the same exception appears repeatedly, revise the rule, the source capture process, or the training note rather than asking people to work around it.
Put routing rules in a deliberate order
Two rules can match the same inquiry. An existing relationship may point to one loan officer while a branch rule points to another. Write which decision takes precedence and who resolves a disagreement. Otherwise, staff may get different answers depending on which screen they inspect first.
Begin with the conditions that require a person to review the record: an uncertain identity, missing routing information, an unsupported service request, or a conflict between owners. Then apply the company’s approved relationship, coverage, and assignment rules. The order below is an operating example, not a description of BNTouch’s default settings.
| Decision |
Example treatment |
Owner’s check |
| Record cannot be classified |
Hold in the intake review queue. |
Identify the missing fact without inventing a value. |
| Existing relationship found |
Ask the designated resolver whether to preserve or change ownership. |
Check the current relationship and coverage, not just an old name. |
| Ordinary eligible record |
Use the approved distribution pool. |
Confirm that the pool contains available, authorized users. |
| Assigned user unavailable |
Use the documented backup route. |
Keep one accountable owner and a reason for reassignment. |
| No eligible recipient |
Escalate to the named operations decision-maker. |
Prevent repeated transfers through the same unavailable pool. |
Choose a distribution method for the work you have
A rotation can spread ordinary intake across an eligible pool, but it does not prove equal workloads. One loan officer may be handling active-file issues while another is available for new conversations. If capacity matters, define how the team determines it and how often someone refreshes that information. A forgotten availability setting can create the same delay as an unstaffed inbox.
A relationship-based assignment can preserve continuity, provided the relationship is current and the assigned person can respond. A branch or service-area rule needs an approved business purpose and current authorization checks. Avoid using demographic characteristics or proxies for protected characteristics to exclude people from service or favorable treatment. Ask the organization’s compliance owner to review the actual criteria against applicable requirements, including Regulation B’s general rules.
Keep your CRM evaluation specific: can the proposed configuration express the approved rule, show why a record matched, and expose exceptions? Do not assume a particular distribution method, capacity calculation, or audit field exists until it has been demonstrated in the environment you would use.
Walk through a conflicting assignment
Fictional example: A partner introduces a prospect whose earlier inquiry belongs to Loan Officer A. The introduction reaches a branch pool while A is on leave. The branch manager confirms the existing relationship and assigns Loan Officer B as the accountable temporary owner. The record explains the coverage reason and the manager’s decision.
B checks the prior conversation before acting. The team closes any duplicate task that would send a second, conflicting response. When A returns, ownership does not change merely because a calendar date passed; the designated resolver checks the current commitment and records the next handoff. This prevents the prospect from having to repeat the same request to both people.
For a test, change only one input at a time. Repeat the case with A available, then with the prior relationship unresolved, then with no eligible backup. Write the expected owner before running each version. If the outcome differs, decide whether the written rule or the configuration needs correction.
Separate rule problems from workload problems
Review records that were reassigned, held, or left without an accepted next action. For each, record the first route, final route, reason, and elapsed wait. Count transfers per record as well as total transfers: a small number of inquiries circulating through several people can disappear inside a large activity report.
Use these findings to choose a specific change. Repeated unavailable-owner exceptions suggest a coverage issue. Complete records landing in the wrong branch suggest a rule or source-mapping issue. Many valid assignments with late acceptance suggest a workload or notification problem. Test the suspected cause before changing several rules together.
Version the routing document when you make a change. Retain the approval, effective date, affected sources, and controlled test results. The historical tutorial below can help you prepare a product demonstration, but your written operating rule remains separate from the product’s current configuration.
Reviewed BNTouch routing source
Options Tab: Automated Lead Distribution – Users & Filters is a BNTouch tutorial published in 2020. It visually demonstrates example users, filters, schedules, and reassignment settings. Treat it as historical workflow evidence, not a statement of current account configuration, permissions, or data behavior. Verify the workflow your team needs in a current product demonstration.
Use this when evaluating a CRM
Bring the five de-identified examples and one written exception rule to a BNTouch demo. Ask the team to map the source context, accountable owner, next action, fallback, and correction path in the workflow you are considering. Confirm the current configuration before using any workflow in production.
For the broader operating picture, use the mortgage lead distribution software review for platform evaluation and the mortgage lead management guide for source review, task ownership, and follow-up records.
This lead-distribution review supports the broader mortgage lead-generation workflow: it focuses on what happens after a valid inquiry reaches the team, including assignment, fallback ownership, and reviewable exceptions. Read the mortgage lead-generation workflow for the related owner-page context.
Sources and further reading
