There is a version of firm progress that looks like buying. A new app for onboarding, an integration to move data between systems, an automation to stop someone rekeying the same client details four times. It feels like momentum. Sometimes it is. Often it just hardwires a mess you already had, so now the mess runs faster and breaks in more places.
The uncomfortable rule underneath all of it: if you automate a broken process, you do not get a fixed process. You get a broken process that runs at speed. Crap in, crap out. An integration cannot rescue a workflow that was never agreed in the first place.
So before the next tool goes in, it is worth asking a different question. Not what can we automate, but is this process even ready to be automated?
Why does automation so often disappoint?
Here is the pattern that plays out again and again. A firm wants automation. Everyone does. But then comes the crossroads: automate what, exactly? The honest answer is usually that nobody knows, because the process was never mapped. People can describe it at a wave-of-the-hand level, a lead comes in, we send an engagement letter, the work starts, but the moment you ask who touches it, which app it lives in, what triggers the next step, the description falls apart.
That is not a technology problem. It is a process problem wearing a technology costume. And it is why so much automation spend disappoints: the firm bought a fast route through a road it had never actually drawn.
The fix is unglamorous. Before anything gets automated, you map the process. Visually, on a flowchart, showing what happens, who touches it, and what triggers each step. When it is on a wall where you can see it, the pain points announce themselves. This is where it breaks. This is where the work waits. This is the step three different people do three different ways.
Are you actually standardised, or does everyone just think so?
Ask a firm whether its core processes are standardised and most will say yes. Then ask a few more questions and the “yeah, buts” arrive. We do it this way, except for that client. And that one. Oh, and Bob down the hall does it his own way entirely.
That is the real state of most firms: not standardised, and not quite aware of it. Which matters, because you cannot automate what you have not standardised. If the same job is done five different ways to reach the same outcome, there is no single process for a tool to sit on top of.
Here is the idea worth holding onto, because it sounds like a contradiction and is not: standardisation is the first step to becoming flexible. When there is no standard, every unusual request is just more chaos, and the firm is a squirrel darting between exceptions. Once there is a standard, an atypical request becomes a clear decision. You can look at it against the way you normally work and choose, deliberately, whether this exception is worth making. Standardisation does not make you rigid. It gives you a baseline to flex from on purpose.
Do you know why you are automating in the first place?
There is a question that should come before any tool, and almost nobody asks it. Why do you want to automate this at all?
Ask ten people and you will get ten answers. To make more money. To get time back. For a better work-life balance. Because the team is bottlenecked and clients are leaving. Because a competitor did it. None of those are wrong, but they lead to very different decisions. If the goal is time back for a burned-out team, you automate the tasks people dread. If the goal is margin, you automate the highest-volume repetitive work. Skip the why, and you end up automating things to feel modern, patting yourself on the back for a firm that looks automated while the actual bottleneck sits untouched.
Which points to a discipline about what to automate at all. The value is in the simple, common-logic tasks, the ones that happen the same way for most clients most of the time. The complex, nuanced automation with thirty-five branches of logic for a hundred different clients is where things break constantly and the effort never pays back. If you are saving five minutes for one client once a month, the hassle is not worth it. Automate the common path, handle the edge cases by hand.
Where should a firm actually start?
If there is one place to begin, it is onboarding, everything from a new lead arriving to the work being handed to the delivery team. It is the natural starting point because it is where all your apps meet, and therefore where the same client information gets entered twice, three times, four times, once in the CRM, again in the folder structure, again in the engagement letter, again in the workflow. Every one of those re-entries is a chance to get a number or a date wrong, and those small errors have a long knock-on tail.
Onboarding is also where steps get silently dropped. A contract comes in, someone forgets the welcome email, the job never gets assigned, and the client’s first impression of the firm is a stumble. Getting that sequence right does two things at once: it removes the duplicate data entry, and it protects the client experience at the exact moment the relationship is being set.
The part everyone skips: bringing the team with you
A tool only works if the people using it adopt it, and adoption is where most automation quietly dies. If the team does not buy in, they will not tell you when something breaks. They will just tell you it does not work, and go back to the old way.
Part of that is fear. Automation, heard from the wrong angle, sounds like a plan to remove jobs. The honest framing is the opposite: a good team does not get smaller when the drudgery goes away, it gets freed up for the work that actually needs a person. The move is to be transparent about the why with the whole team, not just the partners. What is this for? What does it give you back? Often the team will point you at the real pain, the tedious thing they dread twice a month, that no ROI spreadsheet would ever have flagged. Fixing that does not show up cleanly in a return-on-investment number, but it shows up in people not leaving.
The order that actually works
The through-line here is the same one that governs outsourcing, and the same logic applies to outsourcing as to automation: neither is the answer on its own. Process first. Standardise what you do, agree it, write it down. Then decide why you are changing anything. Then, and only then, reach for the tool, whether that tool is an automation, an integration, or an outside team. Do it in that order and the technology genuinely does turbocharge the firm. Do it in the wrong order and you have paid to make a problem faster.
If you want a second set of eyes to map the process first before you commit to a tool, that is a conversation we have with firms all the time, and it is the kind of thing a good back-office team has done many times over.
For more on building a better accounting practice, MoneyPenny hosts Beyond Numbers, a podcast of practical conversations on capacity, workflow, pricing, technology and the realities of running a firm. Watch on YouTube or listen on Apple or Spotify.
