Most teams starting a document automation project pick the wrong document first.
Not because they aren't thinking about it. Because the obvious candidate - the one everybody agrees is painful - is almost always the most complex document in the set. The loan agreement. The share sale agreement. The one with thousands of variables, conditional logic everywhere, and a dozen decisions about what to include and how much detail to go into.
And to be fair, the case for automating those documents is real. A document that takes ten hours to draft manually might come down to half an hour. The time saving per document is enormous, and the quality improvement - consistency, no missed clauses, no copy-and-paste from the last deal - is worth more again.
But two questions are worth asking before you start there.
How many of them do you actually do?
A 95% time saving on a document you produce twice a month is a smaller prize than a 60% saving on something your team does twenty times a day. Automation value is frequency multiplied by the number of people doing the work - not complexity.
When I first started out in automation, we did the loan agreements, and it was genuinely impressive. A relatively simple property finance loan went from about an hour down to about three minutes.
At the same time, I automated the certificate of non-revocation of power of attorney. One page. Needed every single time we released a security. We had a property developer client doing a lot of partial security releases, and on a busy day I was producing twenty of those.
I saved more time on the one-page document than I did on the loan agreements.
That's not an argument against automating the loan agreements. We did both, and both were worth doing. It's an argument for looking at your volumes before you decide what comes first.
Can you afford to learn on your hardest document?
The second issue is a learning-curve one, and it gets underestimated.
Your first automation project is where you work out how the system really works - how it handles conditions, how you structure questions so the interview makes sense to the person answering it, how you build components you can reuse rather than rebuilding the same clause five times. That's a lot to figure out while simultaneously wrestling with a document that has a thousand variables and no obvious place to start.
Simple, high-volume documents give you somewhere to learn where the stakes are lower, and the payback arrives quickly:
- Letters
- Notices
- Confirmations
- Short agreements
- NDAs
- Internal approvals and instructions
These get used constantly, by a lot of people, and they're often the documents nobody has ever bothered to look at properly because individually they only take a few minutes. Templates for them can be built quickly, and what you learn building them transfers directly into the complex work when you get to it.
A four-column table beats a workshop
If you want a practical way to plan this, you don't need a strategy day. You need a table with four columns:
| Document | Uses per week | Minutes each (now) | Total minutes per week |
|---|---|---|---|
| Certificate of non-revocation | 100 | 6 | 600 |
| Standard NDA | 15 | 25 | 375 |
| Loan agreement | 2 | 60 | 120 |
That last column is the one that matters. It's the pool of time you're actually trying to reclaim, and it will almost certainly surprise you - both in which documents rise to the top and in how large the total is once you add it all up.
Fill it in with your own numbers, sort by the last column, and start at the top. You'll get value sooner, you'll build capability while you're doing it, and you'll walk into the harder documents knowing what you're doing.
There is a more sophisticated version of this exercise - scoring candidates on frequency of use against the total drag you can remove - which I'll cover in a future post on How to work out which documents to automate first.
One more thing: saved time isn't value yet
Getting the sequencing right is the easy half. The harder half is what you do with the time you free up.
If you're a law firm billing by the hour, an efficiency gain with no change to how the work is priced doesn't show up as a better result - it shows up as lower recorded time, and the tool gets blamed. If you're an in-house team, capacity that isn't consciously redirected tends to get quietly absorbed.
So it's worth deciding in advance what the saved time is for: taking on work you currently turn away, pricing a fixed-fee product you couldn't offer before, cutting turnaround times you've been apologising for, or giving people back the parts of their week they lose to reformatting documents. That decision turns a time-saver into a business result.
But it starts with picking the right document. And that's usually not the one everybody expects.
If you'd like to talk through how any of this applies to your documents and processes, I'm always happy to have a conversation.
This post is part of a series on getting more value from document automation.
