A practical framework for mapping a broker's case workflow, spotting where it breaks, and deciding what to automate versus keep human.
Written by
Charlotte BrownRole
Mortgage Industry Writer
Most mortgage brokerages don't have a workflow problem because nobody's working hard enough. They have one because the process a case follows was never designed, it accumulated: a step added after a near-miss, a habit that stuck because it worked once, a spreadsheet column nobody quite remembers the reason for. That kind of process mostly holds up until it doesn't, and when it fails, it tends to fail at the worst point: a document chased too late, a fact-find detail that never made it into the recommendation, a case that stalls because nobody was clearly responsible for the next step.
Whatever a firm's specific process looks like on paper, a case moves through roughly the same shape underneath it. A lead comes in and gets qualified as worth pursuing. The adviser runs a fact-find and gathers the documents needed to support it, a stage covered in more detail in how to build an onboarding process that holds up. That turns into research and a recommendation. The recommendation becomes an application, packaged and submitted to a lender. The case moves through underwriting and offer, with the adviser chasing updates and relaying them to the client. It completes. And there's a period afterward where the case isn't really finished, renewal dates, protection reviews, and the relationship itself all carry on well past the point most firms stop actively tracking it.
Treating all of that as one undifferentiated block of "doing the case" is where workflow design usually goes wrong. Each stage has a different job, a different person waiting on something, and a different way of quietly failing.
Two points account for most of the friction. The first is document collection during the fact-find stage, because it's the one part of the process that depends on the client acting quickly, and it's the easiest stage to lose track of without something actively chasing it. The second is the handoff itself, the moment a case moves from one person or one stage to the next and, for a window of time, nobody is explicitly responsible for it. A case that's "with the adviser" one day and "with admin" the next can sit in that gap for longer than anyone intends, not because either person is dropping the ball, but because the workflow never made clear whose ball it was.
Communication inconsistency compounds both problems. A client who gets a proactive update from one broker and has to chase for the next one draws the obvious conclusion, even if the actual case progress was fine throughout.
Not every part of a case workflow deserves the same treatment. Reminders, document requests, status notifications and check-ins on a known timeline are exactly the kind of repetitive, rules-based tasks that automation handles well, and handles more reliably than a person remembering to do it manually on top of everything else on their desk. The advice itself doesn't work that way. Reading a client's actual circumstances, weighing what they've disclosed against what's realistic, and explaining why a particular recommendation fits them needs a person doing real thinking, not a template with the blanks filled in.
The risk isn't automating too much of the operational side, most firms under-automate that part. It's drifting the other way and letting templated language creep into the parts of the process that are supposed to reflect a specific client's situation, which tends to show up later as a suitability record that reads the same for every case regardless of what was discussed.
It's tempting to treat workflow design purely as a productivity question: fewer stalled cases, less chasing, more capacity. That's real, but it undersells what's actually at stake. MCOB 4.7A.25R requires a firm to keep a record explaining why a recommendation was suitable, and MCOB 4.7A.5R requires that advice be based on the facts a client has disclosed and other relevant facts the firm is, or reasonably should be, aware of. A workflow where fact-find detail gets lost between stages, or where a vulnerability flagged early in the process never reaches the person writing the recommendation, doesn't just create friction. It creates a genuine suitability and evidence gap, the kind of gap that's hard to see day to day and very visible the moment a case gets reopened for a Consumer Duty review, exactly the discipline covered in how case records and evidence are expected to hold up in 2026.
Vulnerability flags are a sharper version of the same problem. If identifying and recording a vulnerable customer happens at one stage but the workflow doesn't actively carry that flag through to every later stage, the firm's own vulnerable customer policy exists on paper without functioning in practice.
Most firms can describe roughly how long a case takes from lead to completion, but far fewer can say which specific stage it spends the longest in, or where it most often stalls waiting on something. That's the more useful number. Tracking time spent per stage, not just start-to-finish, surfaces the actual bottleneck rather than a vague sense that "cases feel slower lately." A stage that consistently runs long relative to the others is telling you something concrete about where the process is genuinely under strain, as opposed to where it merely feels that way to whoever's dealing with it that week.
Cleera runs a case through its actual stages rather than treating it as a single undifferentiated record. Every case sits in a defined stage on the pipeline, with fact-find detail, documents and any vulnerability flags attached to the client record and visible at every later stage rather than left behind at the one where they were captured. Reminders and document requests fire automatically off the case's own timeline, so the operational chasing happens without anyone having to remember it, while the recommendation and suitability rationale stay exactly where a person wrote them. Get in touch if you want to see what that looks like against your own case workflow.
What's the difference between a workflow and a checklist? A checklist tells you what needs doing. A workflow tells you what stage a case is in, who's responsible for it right now, and what happens next once it's done. A firm can have a thorough checklist for every case type and still have no real workflow, because nothing connects one step to the next or flags when a case has stalled between them.
Which parts of a broker's process are safe to automate? Anything that's a status update, a reminder, or a request that doesn't require judgement travels well to automation, chasing a missing document, nudging a lender for an update, notifying a client their offer's through. Anything that involves reading a situation, weighing a client's circumstances, or explaining a recommendation needs a person, and trying to template it usually shows up later as a thin, generic suitability record.
How many stages should a mortgage case workflow have? There's no fixed right number, but most firms find somewhere between five and eight stages captures the real shape of a case without becoming unmanageable. Fewer than that tends to hide where things genuinely stall; many more than that usually means stages are being split for the sake of it rather than because the work changes at that point.
Where do mortgage broker workflows most commonly break down? Handoffs are the most common failure point, the moment a case moves from one person or one stage to the next and nobody explicitly owns it in between. Document collection during the fact-find stage is a close second, since it depends on a client acting quickly and is the easiest stage to lose track of without a clear trigger for chasing it.
Share this article
Try Cleera
Manage mortgage and protection cases together. Pipeline, branded client portal, document gathering, e-signatures, and an FCA audit trail in one place.