Picture an advice firm that automates its client review preparation. Advisers now get their packs thirty minutes before the meeting instead of the day before, and compliance notes fill themselves in from the CRM. On paper it’s a clean win.

Now suppose the process underneath had three approval steps nobody could explain, data fields nobody had updated in eighteen months, and a review template written for a regulatory regime that has since changed. The automation fixes none of that. The firm just produces the wrong thing faster, and at scale.

That’s the pattern, and it’s common. Automating a broken workflow gives you broken output at high speed[1]. The speed makes it worse, because the errors pile up before anyone notices.

Automation removes the friction that was catching mistakes

Friction sounds like a cost, but it’s often doing useful work. A slow manual step usually contains an informal check: someone noticing something odd, a second pair of eyes, a pause that prompts a question. Automate the step away without replacing the check and you’ve automated away the catch as well.

Automation also makes a process rigid. A person doing a task can adapt: spot an anomaly, depart from the template, ask a question. An automated workflow can’t. If the logic is wrong, every run is wrong, and it’ll run hundreds of times before anyone looks at the output.

In a regulated firm that matters more. An automated process running bad logic on client data is a compliance risk that may not show up until a regulatory review or a complaint, by which point the damage is done. The ECB has made the same point about customer-facing AI that hasn’t been properly validated[2].

Fixing the process first takes days, not months

This isn’t an argument for six months of process mapping before anyone touches a tool. It means four things before you build anything.

Walk the process end to end with the people who do it. Not the people who designed it, the people who run it today. When I start on a process I ask who actually does it now, and where I can I sit next to them while they work. Ask what they skip, what they double-check, and what they’d change. The informal workarounds show you where the documented process and the real one have drifted apart.

Cut what doesn’t need to exist. Approval steps that exist because someone once asked for them, reports nobody reads, fields captured out of habit. If a step can’t be tied to a client outcome or a regulatory duty, it’s a candidate for removal before it’s a candidate for automation. Automating a pointless step only makes it harder to remove later.

Turn judgement into rules, or keep a person in it. Automation needs explicit logic. “Send the review pack when it’s ready” isn’t something a system can follow. “Send the review pack at 9am the working day before the meeting, provided the fact-find was completed more than five working days ago” is.

Run the cleaned-up version by hand for a week. You’ll find the edge cases before the automation turns them into errors.

Getting the order wrong costs more later

Some costs show up quickly: rework, error correction, time spent debugging automations that are faithfully running bad logic.

The bigger cost is that the process becomes hard to change. Once a workflow is automated, people stop wanting to touch it. Other things get built on top of it. A process that was slightly wrong in month one can be locked in by month six, with dependencies that make fixing it expensive.

Regulated firms carry a third cost. If an automated client-facing process gets something wrong (wrong figures in a report, a suitability letter built on stale data, an AML check that skips a step), the firm carries the liability, and “the automation did it” isn’t a defence.

Which processes are ready to automate

Most automation candidates in an advice firm fall into one of three groups.

Clean and well understood. Automate it. Start with a person reviewing the output as a draft before it’s sent or filed[3], and reduce the review once the output has proved itself over a decent sample.

Messy, but the core task is sound. Tidy it using the four steps above, then automate. For a process one or two people know well, that usually takes days.

Unclear, with no agreement on what “correct” looks like. Don’t automate it. You’ll lock in the ambiguity. Sort out the process design first, which is usually a people and governance question rather than a technology one.

A simple test: if you can’t describe the process clearly enough for a capable new starter to follow it without asking questions, you can’t describe it clearly enough to automate it reliably.

Before building, five answers should be written down. What starts the process, unambiguously? What are the steps, in order, each with one owner and one output? Where does it branch, and what decides the branch? What does a good output look like? And what happens to the exceptions, and who handles them? Any question that gets a shrug is where the work is.

The process is the product

None of this is glamorous, and none of it involves interesting technology. That’s the point. Automation is a multiplier, and it multiplies whatever process you give it. In a regulated firm, automating a bad process isn’t a neutral experiment that didn’t pay off. It’s a faster, harder-to-reverse way of producing the errors your regulator will eventually ask about. Fix the process, then automate it, in that order, every time.

This article is for informational purposes only and does not constitute regulated financial advice or a compliance opinion. Consult a qualified compliance professional for advice specific to your firm.

Sources

[1] ai-in-business, “Mapping and automating an existing, broken workflow simply creates high-speed, scalable dysfunction” (2026-06-08). Internal takeaway from ai-in-business intelligence feed; primary claim is consistent with established process improvement literature.

[2] European Central Bank, Artificial Intelligence in Financial Services: Risks and Implications (2024). Referenced for position that customer-facing AI in financial services carries substantial risk where validation is absent.

[3] Zen van Riel, AI Engineer Blog, “Implement ‘human-in-the-loop’ verification layers for AI-assisted workflows to treat AI output as a draft rather than a finished product” (2026-06-07). https://zenvanriel.com (framework reference).