Catherine Bamford is a well-known figure in document-assembly circles, so I paid attention when recently I saw her LinkedIn article entitled Legal Document Automation ... Where Did It All Go Wrong? (here). That was a sobering headline, given that I was about to launch a document-assembly business!
Her article was a transcript of her talk at LegalGeek 2023. Here’s the gist of what she had to say:
Document Automation is STILL not widely used. It is not the business as usual way the majority of lawyers prepare legal documents. Most lawyers still find a precedent and manually edit it in Word.
So why? This tech has been around, after all, for more than 20 years! How come firms are still struggling to scale its use?
Well… I am going to focus on ONE REASON and this is the truth bit I mentioned that no one really has ever said before…
So the one reason - my big reveal…… document automation IS ACTUALLY REALLY HARD!!!!!!
I’m not going to parrot Catherine. Instead, I’ll offer my own take on why document assembly has always underperformed, differing only in some details from Catherine’s account. And I’ll suggest why Adams Contracts can help make it easier to use document assembly.
Compiling the Contract Language
Document assembly faces four problems. First, figuring out what to say in a contract and how to say it is always challenging, but it’s even more challenging for document-assembly projects, given the customization—you have to figure out how all the different scenarios interact.
But wait, it gets worse! We live in a copy-and-paste world, so it’s safe to assume that many who might work on document-assembly projects start with precedent contracts that exhibit the dysfunction of mainstream contract drafting. It’s also safe to assume that many who might work on document-assembly projects have learned contract drafting the traditional way—by regurgitating that dysfunction and absorbing the addled conventional wisdom that seeks to explain away the dysfunction. Those two factors don’t form a promising foundation for document-assembly work.
So I’ve long assumed that one reason document assembly has lagged is that many don’t have the stomach for the work it involves.
Automating the Contract Language
The second challenge is that once you get away from the easy stuff, document assembly is … coding. Your contract language ends up as fragments floating in code. And the more sophisticated functionality is accomplished by inscrutable code that would be hard for nontekkies to understand.
So as Catherine suggests, it’s important for you to get help. But that help makes document assembly more expensive. Furthermore, even if you get help, anyone spearheading a document-assembly project should still understand how all the parts fit together. In a project of any ambition, that will be challenging. When I mentioned to someone that I was working on a document-assembly project, they said, “But it’s just logic, isn’t it?” Well, no, because of the sophisticated functionality. Furthermore, sure, it’s driven by logic, but once you get enough moving parts, it’s tough to keep track of it all.
So not everyone who could be working on document-assembly projects will be cut out for the technical challenges.
Economies of Scale
With any document-assembly project, a key question is who is going to use it. Your organization? Great! But that means your template will be used by fewer people than would be the case if the template were used by many organizations.
So the third challenge is whether you’re able to reap economies of scale, with many using a given template. An organization considering its own document-assembly project might well decide that the use it would make of the template won’t justify the cost.
Inertia
The fourth challenge to successfully applying document assembly to contracts is the force that impedes any change in the legal world—inertia. Any kind of change will, in the short term, impose costs that are greater than the benefits. Changing your contracts forces everyone who touches them to adjust their thinking. All those people! All that change! If you’re wedded to short-term thinking, it’s easy to reject the change that comes with document assembly.
A Shortcut
Given that background, it’s easy to see why document assembly has languished.
But the challenges show why Adams Contracts is in a better position than most. When it comes to wrangling contract language, I have the credentials for it, and I have the stomach for it. And because Adams Contracts is selling to the broader market, it can achieve economies of scale.
Sure, no one would confuse me for a coder, but I can keep track of the basics. And yes, our templates will inflict short-term change, but to make a go of it all we need is for a modest part of a vast market to have their eye on long-term benefits and not be scared off by the short-term demands that come with change.
But perhaps the most compelling proposition Adams Contracts has to offer is that any organization can turn our templates into their own templates. We can customize our templates for you by stripping out some questions, adding others, and adjusting the guidance. That would allow you to reap the benefits of commoditized contract drafting without the heavy lifting that goes along with running your own document-assembly projects.
Contact me (at ken@legalsifter.com) if that’s of interest.
By the way, the illustration at the top is by Russell Christian, and I commissioned it around ten years ago, when I last got involved in document-assembly. It's nice to have occasion to use it again!
