Mortgage broker CRM implementation checklist

Choosing broker software is the visible half of the decision. The half that determines whether it works is what your firm does in the eight weeks either side of go-live. Capable platforms fail regularly, and almost always for the same reasons: nobody agreed what the process was, the data arrived dirty, the training was a tour of features, and the old workaround never died.

This is a checklist for the implementation itself, whichever platform you have chosen.

Appoint an owner with authority

Not a committee. One person who can decide that a status will be called this rather than that, who signs off configuration, and who is allowed to tell an adviser that the spreadsheet is going away.

Implementations stall when every decision needs consensus. Give the owner a deadline and the principal's backing, and give them time released from other work, because this is a real job for a period.

Write down the process you actually run

Map the journey from first enquiry to completion and review: every step, who does it, in which system, what the client sees and where things wait. Do this by watching people work, not by asking them to describe it, because the description will be the version they believe rather than the one that happens.

You will find variation between advisers. Decide deliberately which variations are legitimate and which are habit, before configuration bakes them in permanently.

Decide the source of truth for each record

Be explicit, field by field, about where each thing lives: contact details, fact-find data, documents, case notes, research evidence, suitability records, compliance checks, review dates, revenue. If any of these will exist in two places — which is common for AR firms with a network system — write down which one wins and what the other is for.

An unresolved answer here becomes the source of every argument about data quality for the next three years.

Clean before you import

Do not migrate everything simply because it exists. Remove duplicate clients, standardise statuses, archive dead enquiries, and check that review dates are real rather than inherited from a spreadsheet nobody has maintained.

Agree what happens to records that do not map cleanly into the new structure, and to fields with no new equivalent. Advisers abandon a system quickly if the first thing they see is data they know is wrong.

Configure for roles, not for everyone

An adviser, an administrator, a manager and a compliance reviewer need different screens. Build the default view for each around the first three things they do each day.

Resist the urge to expose every field to everybody. Visibility feels generous and reads as noise. It is easier to add a field later than to persuade people to stop ignoring a cluttered screen.

Pilot with live cases, deliberately chosen

Run a small group of real cases through the new system before the whole firm moves. Choose the mix on purpose: one straightforward purchase, one messy case with a change of lender, a protection opportunity, a remortgage review and one case involving a client who will not engage.

The pilot exists to find missing templates, awkward hand-offs, statuses that do not fit and training gaps. Keep a running list of what broke and fix it before launch rather than after.

Train on the working day

Nobody needs a tour of the menus. Train by walking through the shapes of a real day: an enquiry arrives, a fact-find is completed, documents are requested, advice is recorded, a case moves stage, a review is set, a client asks for an update.

Train administrators separately from advisers, because their work is different and the mixed session serves neither. Record short clips of each workflow so a new starter in six months does not depend on somebody's memory.

Switch the old thing off

Set a date, announce it, and hold it. Parallel running past a couple of weeks is how firms end up with two half-maintained systems and no single truth.

Where a legacy system must stay accessible for retention purposes, make it read-only and say so, so nobody quietly keeps working in it.

Measure adoption rather than satisfaction

Ask the system, not the team. Look at overdue tasks, cases with no note in ten days, documents arriving by email instead of the portal, unlogged calls, case age by stage and review dates set on completed cases.

Those numbers show whether the software is where the work happens. Ask advisers as well, but weight what the logs say more heavily than what people say in a meeting.

Review at thirty, sixty and ninety days

At thirty days, fix the friction: templates, statuses, permissions, anything people are working around. At sixty days, look at whether the process you designed is the process being followed. At ninety days, compare against the baseline you recorded before the change and decide honestly whether the firm is better off and what still needs attention.

Bottom line

Treat implementation as an operating change rather than an IT project. Process first, clean data second, configuration third, and adoption measured rather than assumed. The rollout is not finished when the software goes live. It is finished when the workaround it replaced has genuinely disappeared.