Written by Yuri Polukeev, CEO, BNTouch Published September 7, 2026
A mortgage pipeline exception review focuses on files where the normal next step has broken down. Bring the decision needed, the confirmed facts, and the person who can act. Leave with an action and a clear condition for resolving the exception.
This is an operational meeting format, not an underwriting exception policy. Credit, compliance, disclosure, and other regulated decisions remain with the authorized roles and procedures.
Assignment confirmed and callback commitment visible.
Working CRM status differs from the authoritative loan record.
Which status is current, and who corrects the working record?
Responsible person verifies the source and records the correction.
A processor receives a file without the borrower’s open question.
Who supplies the missing context?
Receiving processor confirms the question and next action.
An agreed borrower update is overdue.
Who responds now?
Contact completed or a documented escalation and next check-in.
A task remains after the situation changed.
Should it be revised, cancelled, or reassigned?
The obsolete action is no longer presented as current work.
A short meeting agenda
Before the meeting: Each case owner writes the decision needed in one sentence. Routine status updates stay in the usual work queue.
During the review: Read the confirmed facts and identify the missing answer. Do not spend the meeting reconstructing an undocumented history.
Make the decision: Assign the next action to someone who has the authority and access to complete it.
Set the check: Record when the team checks again and what would count as resolved.
After the review: Check the prior meeting’s commitments before opening another list.
Worked example: mismatched status
Illustrative case: The CRM’s working label suggests a later stage than the current record in the LOS. A borrower update is due.
Decision: Which confirmed status may the team communicate?
Action: The authorized loan-record owner verifies the source status. The loan officer owns the borrower update and does not repeat the unverified label.
Resolved when: The working record has been corrected or the discrepancy has a documented explanation, and the borrower-update owner has the confirmed information.
Do not assume the mismatch proves a broken integration. A manual edit, a definition difference, or a timing issue can produce a similar symptom. Investigate the actual record path before changing a connection.
A decision log that can be read next week
Use these columns: record reference, issue, confirmed source, decision, action owner, next check, and resolution evidence. Keep sensitive loan information in its approved location; the meeting log can reference it rather than duplicate it.
“Discussed” is not a resolution. “Assigned processor confirmed the correct status and the loan officer completed the promised update” describes an action that can be checked.
Set entry rules for the exception meeting
Ask each case owner to describe the decision the group needs to make. “File is in processing” belongs in routine status reporting. “The receiver cannot find the outstanding borrower question, and an update is due” identifies a problem the group can resolve. Use the meeting for cases requiring a decision across roles, access, or competing information.
Time-sensitive issues should follow the organization’s escalation process as soon as they arise. Do not hold a privacy concern, required notice, or urgent borrower matter until the next scheduled meeting. A recurring review can examine why a problem happened after the immediate response is underway.
Prepare a case card before discussion
Case-card field
Fictional example
Reason to include it
Decision needed
Choose who owns the borrower callback while the processor is absent.
Prevents the meeting from becoming a full file-history review.
Confirmed facts
The prior note contains a callback commitment. No receiving acknowledgment is recorded.
Separates evidence from the team’s assumptions.
Source reference
Approved relationship record and the designated loan-record owner.
Lets an authorized person check the information without duplicating sensitive data.
Immediate action
Coverage owner accepts the callback and confirms the outstanding question.
Identifies work the team can do now.
Resolution condition
Callback responsibility is accepted and the next borrower contact is documented.
Gives the next review something specific to verify.
Keep the card to the facts relevant to the decision. Link to authorized records for detail. A meeting participant should not need a second copy of a borrower’s financial documents to understand an ownership problem.
Work through three different exception types
Ownership conflict
Two people assume the other will contact the borrower. The meeting owner assigns one accountable person and confirms coverage. The case closes when the receiving person acknowledges responsibility and the communication commitment is visible in the working process. Adding another reminder without resolving the ownership conflict leaves the same failure in place.
Changed circumstances and obsolete work
A task or campaign no longer fits the confirmed situation. Ask the authorized owner to check which action remains appropriate, whether a pending communication needs review, and who updates the working record. Record the reason for cancelling or changing work. Task disappearance alone does not prove the team resolved the issue correctly.
Unclear system information
The CRM and another system show different labels. Record the exact labels, when each was observed, and which person owns the underlying fact. First determine whether the labels describe the same event. If they do, investigate the source path and timing with the responsible administrator. If they do not, clarify the definitions before changing a connection or asking staff to overwrite a status.
This investigation requires account-specific evidence. The article does not establish which fields BNTouch exchanges with a particular LOS or how frequently a connection runs.
Keep the meeting focused when a case needs investigation
Some exceptions cannot be resolved during the discussion. Assign a named investigator, the exact question to answer, and the next review point. Also assign any borrower communication that remains due. The record should make clear that investigation is underway, not that the team has completed the underlying work.
If a case repeatedly returns with no new information, ask whether the assigned person has the access and authority to resolve it. Moving the same task between people can create activity without progress. Escalate through the approved management route when the missing decision sits outside the group’s authority.
Measure open cases and resolved work separately
Track the number of open exceptions at the start of the period, new cases, cases resolved, and cases still open at the end. Keep reopened cases visible rather than presenting them as brand-new issues. Define the period and what “resolved” means before comparing weeks.
In a fictional review, the team begins with eight open cases, adds four, and resolves five. Seven remain, assuming no other changes. That arithmetic describes the queue; it does not explain service quality. Review the seven remaining cases for age, borrower impact, and missing authority, and inspect whether the five closed cases have actual resolution evidence.
Do not set a universal target from this example. Different teams have different case definitions and operating constraints. Use a consistent definition within your own process so a change in the count can be investigated rather than celebrated or blamed without context.
Keep a reusable record of the decisions
After the meeting, the owner should be able to find the decision beside the next action. If someone works from a separate list, define how they will record completion in the approved source. Avoid maintaining two contradictory lists of open cases. At the next review, check the prior commitments before adding new work.
When the same exception repeats, decide whether the team needs a clearer definition, a training example, a coverage change, or an account-specific technical investigation. Save the resolved example in an appropriate internal training format with private information removed.
What to inspect in BNTouch
The Daily Dashboard tutorial around 4:00 demonstrates the task view. Ask how a person finds their next work and how your proposed exception note would sit alongside it.
The campaign-trigger tutorial around 3:01 also demonstrates removal rules. That is relevant when evaluating how a changed record should stop fitting a campaign. It does not establish every account’s settings or prove an LOS field-sync rule.
How do you know the meeting is useful?
Track whether the same unresolved issues return, how many actions lack an owner, and whether prior commitments were completed. These are team-defined operating checks, not universal benchmarks. A smaller meeting is useful only if work is getting resolved rather than omitted.
