Mortgage broker workflow RACI matrix for outsourced teams

A mortgage workflow RACI matrix shows who does the work, who owns the outcome, whose input is required and who needs the result. For an outsourced mortgage team, it prevents a common failure: a task moves to support, but the broker approval, exception owner or customer-contact boundary remains unstated.

Use one accountable role for each workflow row, then connect the matrix to the actual queue, SOP and permissions. RACI is a planning tool, not authority by itself. A spreadsheet cannot grant a person permission to give advice, approve a submission or access a system.

Use RACI for outcomes, not every mouse click

RACI stands for responsible, accountable, consulted and informed. Responsible performs the defined work. Accountable owns the outcome and final acceptance. Consulted provides input before completion. Informed receives the result or a material update.

Create rows for meaningful outputs such as “document pack ready for broker review” or “lender status updated and client next step prepared”. Do not create a row for every field or button. Fine detail belongs in the workflow SOP.

Map the end-to-end stages first

List the brokerage's real stages from new inquiry to post-settlement care. Use names that match the CRM. For each stage, identify the trigger, exit condition and customer-facing promise. This exposes duplicated labels and stages that have no owner.

• inquiry captured and assigned;
• initial appointment prepared;
• fact find and supporting information tracked;
• scenario or research inputs assembled;
• application pack prepared for approval;
• lodgement and lender follow-up supported;
• conditional approval items coordinated;
• settlement readiness tracked;
• settlement confirmed and records closed;
• post-settlement contact and review cycle scheduled.

Your business may use different stages. The value comes from matching the matrix to production work, not adopting these labels.

Define roles before assigning letters

Use role names rather than individual names so the matrix survives leave and staff changes. Typical roles might include broker, broker assistant, loan processor, client-care coordinator, operations lead and system administrator. Add a separate approver when the process requires one.

Write a one-sentence boundary for each role. For example: “Loan processor prepares factual file material and records exceptions for broker review; the role does not make the brokerage's product recommendation or approve a customer-facing decision.” Have the appropriate business advisers confirm boundaries for the actual arrangement.

Build the first responsibility matrix

Workflow output	Support role	Broker	Operations lead	Client
Appointment preparation complete	R	A	I	I
Missing information list prepared	R	A	I	C through approved contact path
File pack ready for broker review	R	A	I	-
Unclear or conflicting information resolved	C	A/R	I	C when directed
Lender status recorded	R	A	I	I through approved update
Access change approved	I	C	A/R	-
Post-settlement review cycle scheduled	R	A	I	I

This is an illustrative structure, not a recommended authority model. Replace it with the roles, checks and contact rules your brokerage actually approves.

Keep one accountable owner per row

Several people can be responsible for parts of an output, but one role should own its final acceptance. Two accountable roles often means neither knows who must decide. If accountability changes by scenario, split the row or state the rule that determines the owner.

Do not default every row to the principal broker. Assign operational accountability where the role genuinely owns the output, while preserving broker approval for broker-owned decisions. Overloading one approver creates a queue that looks delegated but still waits on the same person.

Separate preparation from approval

Many mortgage support tasks contain a safe preparation step and a consequential approval step. Put those in separate rows. “Prepare customer update from recorded lender status” can be a support output. “Approve and send an update that interprets a material outcome” may belong to another role. The exact boundary depends on the work and business requirements.

Link the matrix to the system access permissions matrix. A person marked responsible should have only the access needed for that output; the accountable role needs the review evidence required to approve it.

Add handoffs and response expectations

RACI names the roles but not the handoff quality. For each output, record the incoming trigger, required information, destination queue, acceptance check and response window. Use the daily handover template for active work and the service schedule for recurring targets.

Make consulted roles practical. State what input is needed and by when. “Consult broker” can otherwise become an unlimited pause. A good consultation request includes the item, issue, checks completed, available options and decision required.

Give exceptions their own ownership

Standard work and exceptions should not share an ambiguous row. Add responsibility for missing information, conflicting evidence, customer complaints, lender policy uncertainty, access incidents, urgent deadlines and out-of-scope requests. The support person should know when to stop, where to record the issue and which role must respond.

Exception	First action	Accountable role	Backup
Input missing	Record blocker and approved follow-up	Queue owner	Operations lead
Information conflicts	Stop affected step and summarise discrepancy	Broker or named reviewer	Principal or delegate
System access concern	Stop access and use incident route	System owner	Security contact
Deadline at risk	Escalate with impact and required decision	Workflow owner	Operations lead

Test the matrix with a real handoff

Take one recent standard item and walk it across every row. Ask each role what they receive, do, approve and pass on. Compare those answers with the matrix. Then test one normal exception and one absent staff member. A matrix that works only when the usual person is online is incomplete.

Use the same exercise when defining a post-settlement client care workflow, where contact ownership often shifts after settlement.

Publish, train and maintain it

Put the matrix where the team works, not only in an onboarding folder. Include the owner, version date and approved changes. Update the linked SOP, permissions and service schedule together. A new responsibility with old access or an old acceptance check creates a hidden control gap.

Review the matrix after role changes, new software, new service scope, repeated escalations or a continuity exercise. Ask whether the actual queue still matches the designed ownership.

Test a fictional missing-input handoff

In this fictional scenario, a support person is preparing a review pack and discovers that an expected source item is missing. The matrix has separate outputs for preparing the missing-input list and deciding whether the pack may proceed.

Output	Responsible	Accountable	Evidence and handoff
Missing-input list prepared	Processor	Queue owner	Record the missing item, checks completed and next action in the linked task.
Decision on next step recorded	Named reviewer	Broker responsible for this workflow	Record the approved instruction; support does not infer the answer.
Approved request prepared	Broker assistant	Approved communication owner	Use the permitted template and record its review state.

Before using the arrangement, ask what happens if the reviewer is away: the documented backup receives the same decision request, and the affected work stays blocked until the decision is returned to the source record. If both the processor and broker think the other owns that request, change the matrix and queue assignment together. These sample assignments grant no authority; the brokerage must approve its actual roles and boundaries.

Copy this RACI worksheet

• Workflow output: a clear, observable result.
• Trigger: the event and required inputs that start work.
• Responsible: role performing the defined preparation.
• Accountable: single role accepting the outcome.
• Consulted: input required, format and response point.
• Informed: recipient, event and communication channel.
• Acceptance check: evidence needed before the row is complete.
• Escalation: exceptions, first action, owner and backup.
• System access: approved account and permission set.
• Linked SOP: current procedure and version.

A useful matrix makes work move when the usual person is busy. It lets support staff act confidently inside a defined lane while keeping approvals and exceptions visible to the roles that own them.