Skip to content

Operations

What document automation actually returns

The business case for automating drafting is usually built on the wrong number. Here is the arithmetic that survives contact with a real firm.

Eglė Sabaliauskaitė

Chief Product Officer

·7 min read

Every document automation business case we see starts the same way. Someone counts how long it takes to draft a document, multiplies by the number produced each year, assumes automation removes seventy per cent of that time, and arrives at a number large enough to make the software look free.

The number is almost always wrong, and it is wrong in a way that damages the project. It sets an expectation the tool cannot meet in year one, and it hides the costs that actually determine whether the thing succeeds.

The cost nobody puts in the model

Automating a document is not a technical task. It is the task of deciding what the document should say — and in most firms, that decision has never been made explicitly.

A firm with eleven versions of a lease in a shared folder does not have a template problem. It has eleven partners who have each made small, reasonable, undocumented choices over a decade. Automating the lease means someone has to sit down and rule on those choices: which break clause is the house position, whether the indemnity is negotiable, what happens when the tenant is a subsidiary. That work is real, it takes senior time, and it is the single largest cost in any automation programme.

In our experience the ratio holds fairly steady: for every hour spent building a template in software, expect three to five hours of professional argument about what goes in it. A model that omits this is not a model, it is a sales aid.

The consolation is that this cost is paid once and is genuinely valuable in its own right. Firms routinely tell us that agreeing the house position was worth more than the automation, because it surfaced positions two partners had been quietly taking in opposite directions for years.

The savings that are real

Set aside drafting time for a moment. The reliable returns come from three less glamorous places.

Review time, not drafting time. A partner reviewing a generated draft is checking a document built from approved clauses in a known structure. A partner reviewing a bespoke draft is checking everything. The difference is consistently larger than the drafting saving, and it lands on the most expensive hour in the building.

Delegation. A guided questionnaire lets work move down the seniority curve safely. A paralegal can produce a first draft that would previously have required a two-year-qualified lawyer, because the conditional logic prevents the errors that made supervision necessary. This is where fixed-fee work becomes profitable rather than merely predictable.

Error avoidance. Hard to quantify and therefore usually omitted, but a wrong cross-reference or a clause left in from the previous deal costs vastly more than the hour it took to write. Firms that track this find a small number of expensive incidents per year, and automation removes most of the mechanism that causes them.

Choosing what to automate first

The instinct is to automate the most complex document, because that is where the visible pain is. This is a mistake. Complexity means more decisions to settle, more conditional branches to build and more scope for disagreement — so the hardest document delivers its return last.

Better selection criteria are volume, stability and standardisation. A document produced two hundred times a year, whose form has not materially changed in three years, and where the firm broadly agrees on the content, will be automated in a fortnight and start returning value immediately. Getting one of those live early also buys the political capital needed for the harder ones.

A reasonable sequence: pick two or three high-volume, low-controversy documents; get them into daily use; measure honestly; then move up the complexity curve with a team that now knows what it is doing.

A model that does not embarrass you

If you want a defensible business case, build it from these components rather than from a single time-saving percentage.

  • Build cost: hours of professional time to settle content, plus hours to construct the template, at blended internal rates.
  • Maintenance cost: assume every automated template needs revisiting once a year, and more often where the underlying law moves.
  • Review saving: reduction in senior review time per document, multiplied by volume. Measure this on the first two templates before extrapolating.
  • Delegation saving: the rate differential where work moves to a more junior fee earner, multiplied by the proportion of documents that actually move.
  • Drafting saving: include it, but treat it as the smallest of the three.

Run that over three years rather than one. Automation programmes that are judged at twelve months tend to be abandoned at the exact point they were about to become profitable, because the build cost falls in year one and the returns compound afterwards.

The honest summary

Document automation works. It does not work in the shape most business cases describe. The first year is mostly cost and argument; the value arrives from the second, and it arrives disproportionately in senior review time and in the ability to delegate safely.

Firms that go in expecting that are pleased with the result. Firms that go in expecting a seventy per cent drafting saving in month three are disappointed by a project that was, in fact, going perfectly well.

Document automationLegal operationsROI

A note on this article. Lexoria is a fictional company and this post is original editorial content written for a demonstration website. It is general commentary, not legal advice, and no lawyer–client relationship arises from reading it.

More from the blog

Book a demo

See Lexoria against your own matters.

A 40-minute walkthrough with someone who has actually practised. We will use your matter types, not a canned demo file.

No card required EU-hosted DPA available on request