What does the list of systems actually look like?
Take an ordinary firm of sixty people. There is a practice or case management system. A document management system. A CRM that marketing cares about. Time recording, sometimes inside the practice system and sometimes not. E-signature. A data room. Microsoft 365, with a handful of Copilot seats bought to see what happened. A note taker someone trialled and kept. An identity and AML checking service. A client portal the largest account insisted on. And a short tail of renewals nobody can name an owner for.
Every one of those was bought for a defensible reason. None of them was bought to replace a process. They were bought to make a single step less painful, usually at the moment someone senior lost patience with it.
Meanwhile the week looks much as it did five years ago. People key the same client details into three places. They export numbers and reformat them. They chase colleagues for the paragraph that is still missing. The spend went up. The work did not move.
Why does buying a system rarely change the job?
Because a purchase closes a capability gap, not a process gap. The question in the room is "what product does this?" rather than "what is this job, who does which part of it, and which of those parts stops happening if we buy this?". Answer the first question and you get somewhere to put the output. Answer the second and you find out whether anything gets shorter.
Software is sold on feature lists, and features map neatly onto steps. They map very badly onto sequences. A product can be excellent at storing a report and have no view at all on how the report gets written, who approves it, or what happens when the figures change after approval. The firm buys the storage, keeps the writing, and counts the purchase as progress. We set the general version of this argument out in a tool is not a process.
Where does the manual work actually live?
In the joins. Watch a new instruction arrive. It comes in by email. Someone reads it and decides who should own it. The client details are typed into the CRM, then typed again into the case system because the two do not speak. Conflicts and identity checks run in a third place, and the result is saved as a PDF into a folder someone has to name correctly. An engagement letter is pulled from a template, edited by hand, sent out, then chased a week later from a spreadsheet of who has not signed. That is client onboarding, and most of it happens between the systems rather than inside any of them.
The same pattern shows up everywhere. Time is captured from memory on Friday because the recording tool does not know what the person was doing on Tuesday, which is the gap timesheet capture exists to close. Monthly reporting pulls figures out of two or three systems and lands them in a workbook that one person maintains, the pattern described in the spreadsheet that runs the firm. No vendor sells the join, so a person is the join.
Why doesn't integration fix it?
Integration works where two systems agree what a field means and nothing has to be decided in transit. Move a client reference, push a signed document into a folder. Useful, and a small share of the problem.
Most joins are not field moves. They are a reformat into the firm's house language, a cross-check against something else, a judgement about whether the thing is good enough to go on, or a decision about who needs to see it next. Those are the expensive parts, and they are exactly the parts an integration leaves behind. There is also decay. An integration is set up once, against the templates and categories that existed that month, and then the templates change, as they always do. Templates rot, and the pipework quietly stops matching the work.
Is the real problem that nobody uses what we bought?
Low adoption is a symptom, not the disease. People route around a system when using it properly costs them more time than it saves them personally. If the CRM wants twelve fields for the firm's benefit and gives the fee earner nothing back, it will be filled in late, thinly, or by an assistant guessing. The licence is not wasted because the team is stubborn. It is wasted because the job was never redesigned around it.
The Copilot seats are the clearest example. Firms bought them, ran a lunchtime session, and found that nothing measurable changed, because the tool can help with a paragraph but has no idea what the firm's file note, fee proposal or board pack is supposed to contain. We have written about where those seats do earn their keep in what Copilot is actually good for. More training does not rescue a licence bought to cover a process nobody defined.
Should we audit the subscriptions or the processes?
Audit the subscriptions by all means. It is an afternoon's work, it will find two or three renewals you can stop, and it tidies the ledger. Then put it down, because the money is not there.
The money is in the hours. Pick one job that happens every week and follow a single real instance of it from the first email to the last filing. Write down every system touched, every time something is retyped, every handoff, every wait for an approval, and the minutes each takes. Do it with the person who actually does the job, not the person who thinks they know how it is done. You will usually find the job runs twelve different ways across the firm and that nobody owns it, which is why no system ever fitted it.
Then do the arithmetic: hours lost per person, multiplied by the number of fee earners doing it, multiplied by their charge-out rate, multiplied by forty-six working weeks. The method is set out in how to calculate unbillable hours and the unbillable hours calculator does the sum for you. The number will be larger than your software bill, and it recurs whether or not you renew anything.
What changes if you rebuild the process instead?
The licences stay. That is the point worth making to a nervous partner: this is not another migration, and the team is not learning a fourth place to type things. What changes is that the systems stop being destinations fed by hand. The job runs end to end on the firm's own documents, templates and language, in the tools people already open every morning, and a named person reviews anything that reaches a client.
Do one job, not all of them. Choosing well matters more than moving fast, which is the case made in what to automate first, and the process priority scorer will rank your candidates. If you would rather start from the hours than the list of systems, the audit will tell you where they are going and which process to take first.