When the audit says don't build

Roughly one in five engagements that begin with an operations audit ends with us recommending against the software we were initially asked to build.

This is not a sales tactic in disguise. The recommendation does not come with a more expensive substitute we would prefer to sell. It usually comes with a written brief, an invoice for the audit, and a quiet handshake.

A small studio that admits this risks putting itself out of business. We would rather do that than ship software that should not exist. There are at least three reasons that turn out to be the right call more often than firms expect, and they are worth naming.

Reason one: the process has not been written down

The most common version of “do not build” is when the firm has asked us to automate a workflow that no two people in the office describe the same way.

Two partners agree on the goal. The senior associate runs the day-to-day and has her own version. The front desk has a third. The system being asked for would encode whichever version got into the scope document, which is to say the version held by the person most willing to write things down. The other versions, which often contain the actual reasons the workflow exists, would be silently overwritten.

The written brief in this case names the conflict, recommends a one-week internal process exercise to consolidate it, and offers to revisit the build six weeks later when the firm has agreed with itself on what the workflow actually is. About half of these firms come back. The other half discover that the consolidation exercise was the engagement, and no further software is needed.

Reason two: the cost of being wrong is higher than the cost of being slow

The second pattern shows up most often in legal: a partnership wants to automate something where a wrong answer is dangerous. Conflict checks for a regulated practice. Tax positions where the firm signs an opinion. Anti-money-laundering reviews where the consequence of a missed flag is a regulator’s letter.

In these cases, automation can still be the right answer, but only after a careful read of where the firm’s risk tolerance actually sits. Sometimes it sits much closer to the manual process than the partners initially say. The partner doing conflicts at midnight is not doing it because the partner enjoys midnights; the partner is doing it because no one else’s judgement is acceptable to insure against.

We have written briefs that say, in effect: this is automatable. The technology exists. The risk-adjusted cost of getting it wrong, in your specific firm, is not yet justified by the time saved. Revisit in eighteen months when the model accuracy gap has narrowed and the audit trail standards have matured.

Reason three: the firm is using the wrong version of the software it already owns

This one is the most common, and the most uncomfortable to deliver.

A surprising share of operational pain in professional services firms comes not from missing software but from underused software the firm already pays a license for. Karbon has a workflow engine the operations lead has never opened. Clio has matter templates that would solve half the intake problem. NetDocuments has classification rules nobody at the firm knows how to write.

The reason this happens is structural: the people who buy software at a firm and the people who use software at a firm are often different people, and the configuration step gets dropped between them. The vendor sold the partnership the platform; the partnership never finished setting it up.

The right recommendation here is to spend a week with the existing platform’s documentation, not a fortnight with a custom build. We have written more than one brief that ends, “Before commissioning new software, we recommend booking a one-day consultation with your existing practice-management vendor and asking them to walk through the modules already enabled in your contract.”

This is the recommendation that is hardest to deliver in person, because the firm has already decided it wants new software. But it is a recommendation that has saved partnerships meaningful sums. Nothing about being a small studio requires us to build something every time.

What the audit is actually for

The reason an operations audit is priced separately is exactly so we can deliver this recommendation when it is the right one.

If the audit were free or rolled into a build, every audit would conclude with a build. That is a structural conflict of interest, and it is the reason most automation agencies’ “free assessment” steps are not assessments at all; they are pre-sales calls dressed up.

The audit is its own product because it must be possible for the audit’s answer to be no. Otherwise the answer is always yes, regardless of what would actually serve the firm.

What this means for the engagement

If you commission an audit from us, you are commissioning a written read of your operations from someone who is incentivised to give you the right answer rather than the most expensive one. You are also paying for the possibility that the answer is uncomfortable.

About one in five firms, when we deliver that uncomfortable answer, thanks us, pays the invoice, and follows the recommendation. About one in ten initially pushes back, then comes around six weeks later when the recommended process exercise has revealed the same thing on its own. The remainder of audits proceed to a build, with a much better-scoped brief than the firm started with.

We are happy to engage on these terms. We hope your firm is too.