A firm I spoke to recently had automated their client review preparation workflow. Advisers were getting packs thirty minutes before meetings instead of the day before. Compliance notes were being populated from CRM data automatically. On paper, it looked like a clean win.
The problem: the underlying process had three redundant approval steps that nobody could explain, data fields that hadn’t been updated in eighteen months, and a review template designed for a regulatory regime that had since changed. The automation hadn’t solved any of that. It had just made the firm produce the wrong thing faster, and at scale.
This is not an unusual story. Mapping and automating an existing, broken workflow creates high-speed, scalable dysfunction[1]. The speed makes it worse, not better, because the errors compound before anyone catches them.
Why automation amplifies problems rather than solving them
Automation removes friction. That sounds like a benefit, but friction is sometimes doing useful work. A slow manual step often contains an informal check, someone noticing something odd, a second pair of eyes, a pause that prompts a question. When you automate that step away without replacing the check, you also automate away the catch.
The bigger issue is that automation makes a process more rigid. A human carrying out a task can adapt on the fly: notice an anomaly, deviate from the template, ask a question. An automated workflow cannot. If the process logic is wrong, every execution is wrong, and the system will execute it hundreds of times before anyone reviews the outputs.
This is especially true in regulated environments. In financial services, an automated process running bad logic on client data is not just an operational problem. It is a compliance risk that may not surface until a regulatory review or a client complaint, by which point the damage is already done.
What “fixing the process first” actually means in practice
This is not a call to spend six months on a process-mapping exercise before touching any automation tooling. For most firms at the size I work with, it means doing four things before you build anything.
First, walk the process end to end with the people who actually do it. Not the people who designed it. The people who run it today. Ask them what they skip, what they double-check, and what they wish they could change. You will find the informal workarounds that indicate where the documented process and the actual process have diverged.
Second, cut what doesn’t need to exist. Approval steps that exist because someone once asked for them, reports nobody reads, data fields captured out of habit. If a step cannot be connected to a client outcome or a regulatory obligation, it is a candidate for removal before it becomes a candidate for automation. Automating a redundant step does not make it useful, it just makes it more embedded.
Third, clarify the rules. Automation requires explicit logic. If a step currently works because someone uses their judgement, you need to either articulate that judgement as a decision rule or keep a human in it. “Send the review pack when it’s ready” is not a rule an automated 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.
Fourth, test the process manually at small scale before you automate it. Run the cleaned-up version by hand for a week. You will find the edge cases before the automation codifies them as errors.
The discipline is not “automate everything that can be automated.” It is “first make the process worth automating, then automate it.”
The cost of getting the sequence wrong
The costs are both direct and indirect, and the indirect ones are often larger.
Direct costs: rework, error correction, time spent debugging automations that are faithfully executing bad logic. These tend to surface quickly once an automation is live.
Indirect costs: the process becomes harder to change. Once a workflow is automated, there is psychological and operational resistance to touching it. The tooling becomes load-bearing infrastructure. People build other things on top of it. A process that was modestly wrong in month one can become structurally embedded by month six, with downstream dependencies that make remediation genuinely expensive.
In regulated firms there is a third cost: reputational and regulatory exposure. If an automated client-facing process produces incorrect outputs (wrong figures in a report, a suitability letter drawn from stale data, an AML check that misses a step), the firm carries the liability. Regulators are moving from guidelines to enforcement[2], and “the automation did it” is not a defence.
A practical sequencing guide
Most automation projects at advice firms fall into one of three situations.
The process is clean and well-understood. Automate it. Start with a human-in-the-loop configuration, treat the automation output as a draft that a person reviews before it is sent or filed[3]. Once you have confidence in the output quality over a meaningful sample, reduce the review burden proportionally.
The process is messy but the core task is sound. Tidy the process first using the four steps above, then automate. This typically takes days, not weeks, for a process that one or two people understand well.
The process is genuinely unclear, nobody agrees what “correct” looks like. Do not automate this. The automation will lock in ambiguity. Resolve the process design question first, which is often a people and governance question rather than a technology one.
The decision rule is simple: if you cannot describe the process clearly enough that a capable new employee could follow it without asking questions, you cannot describe it clearly enough to automate it reliably.
What good looks like before you build
Before any automation project starts, the answer to each of these questions should be on paper:
What is the trigger? What event starts the process, unambiguously?
What are the steps, in order? Each step should be one action, with a clear owner (human or system) and a clear output.
What are the decision points? Where does the process branch, and what is the rule that determines which branch is taken?
What does a good output look like? How will you know the automation is producing the right result?
What is the exception path? What happens when the normal logic doesn’t apply? Who gets it, and what do they do with it?
If any of these questions produce a shrug, that is where to spend your time before writing a line of workflow logic.
Getting these answers is not glamorous work. It does not involve any interesting technology. But it is the work that determines whether an automation project produces a return or a liability, and in a regulated firm, the difference between those two outcomes is not marginal.
If you are planning an automation project and want to think through the process design before you build anything, a discovery call with Cordrey Consulting is a good place to start.
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).