The image above is one of 12 panels from this tweet by Jordan Furlong containing his graphic entitled “Types of Future of Law Paper.” It’s a riff on this xkcd webcomic entitled “Types of Scientific Paper.”
Document Assembly Has Underperformed
Obviously, for that one panel to work, it has to be grounded in reality.
Document assembly is a straightforward technology that allows users to change contract drafting from a copy-and-paste exercise to a process of answering an annotated online questionnaire. It holds the promise of allowing you to create contracts faster and have them be better suited to the transaction at hand, with fewer mistakes.
But document assembly has always appeared to underperform in the market. I offer you a simple explanation for that: document assembly is easy, contracts are hard.
Around ten years ago I was immersed in document assembly. I was friends with the people at Business Integrity, developers of the document-assembly software Contract Express. They helped me build an automated confidentiality agreement that was a thing of beauty. And Contract Express was a joy to work with. Even a lummox like me could do the basic stuff, but it was amazing how with some indulgent help from Business Integrity, Contract Express could handle every task I threw at it. I was a fan.
I haven’t had used Contract Express since Thomson Reuters acquired it, but I’m sure it’s still as good as it was then. There’s now another player on the scene, the open-source docassemble; the technologists I listen to all swear by it. And there are all sorts of other document-assembly products on the market. So whatever you need to get done, you can do it with the technology that’s available.
But.
People Don’t Want to Grapple With What’s in Contracts
Using document assembly for contracts requires that you immerse yourself in the content. At a minimum, you have to decide what options you want to offer and what blanks you want users to fill. And whether you want to or not, you’re forced to contemplate what your contracts say and how they say it.
That’s not something most of us are eager to do. There are two inextricably linked realities of contracts. First, most of us are copy-and-paste monkeys: we don’t have the time, authority, or expertise to grapple with what’s in contracts. Instead, we rely on precedent contracts of questionable quality and relevance, making only limited adjustments. And second, much of what’s in contracts doesn’t make sense or could be improved and most of what’s in contracts is expressed in semiliterate prose. Those two realities reinforce each other in a sad feedback loop.
So whether it’s a function of aptitude or inclination, those who work with contracts would rather not delve into their contracts and would rather stick with business-as-usual.
How That Squeamishness Manifests Itself
I encountered that in my years of consulting work. Around half of my projects failed: a big company would pay me legitimate money to redo one of their templates; I would produce something that says what their template says but looks very different, as a result of my fixing the prose and rearranging the elements; my client wouldn’t be able to use it, because it was too different.
Even those who take it upon themselves to offer superior contracts to the world are unwilling or unable to truly get to grips with the task. The templates I’ve seen for sale are poor—BigLaw simulacra hawked to BigLaw. And well-meaning initiatives aimed at breaking the stasis rely on crowdsourcing—Everyone give us your dreck, and may the best dreck win!
Another manifestation of people being squeamish about delving into contracts is the urge to rely on technology—The machines will save us from ourselves! Recently I did this post about one variant of that, using artificial-intelligence technology to mark up new drafts to reflect decisions made in your stash of negotiated contracts.
Perhaps the most basic indication that people aren’t inclined to monkey with the prose of contracts is the fact that I continue to be the lone figure willing to get to grips with the subject. Evidently no one else has had the stomach for it.
The Obvious Alternative
So what stands in the way of broader adoption of document assembly is the fact that you have to tinker with what’s under the hood. The way around that is to free people from the task of creating the bulk of contract content. Limit their involvement to choosing what options are relevant to the task at hand and making any necessary adjustments.
There’s only one way to accomplish that: build a subscription-based, highly customized library of document-assembly templates. Enlist the help of subject-matter experts, so the content is state-of-the-art. Have all content comply with a style guide. And have the components be modular, so, for example, the governing-law provisions in all templates are consistent.
This isn’t a new idea. For one thing, I’ve been talking about it for years. So far, no one has attempted it. But it’s the only way to circumvent the copy-and-paste machine and make progress in contracts. And as a business, I think it would do well. So let’s see whether anyone has the imagination and resources to give it a try.
I’ve written both software and contracts for money. I can confirm the headline here is 100% correct.
To give a sense, I built a lawyer-facing document assembly solution in extra time (not much) during my first year of solo law practice. I’ve used it ever since, for countless forms. Recently, I built a lightweight, client-facing contract generator—with a “wizard” of questions—as a weekend project. None of this is to talk up my own skills. I’m nothing special. None of this is to diminsh the DocAssemble folks or the programmers at the commercial vendors. They know.
Posing prompts, taking answers, and conditionally mushing text together based on the results isn’t hard. The average popular website homepage handles more of that kind of complexity than any contract template or playbook I’ve ever seen in law practice. From a programming point of view, the difficult parts of these projects is often the last step: getting text into one of the crufty, obscure data formats that lawyers insist on using, like Word or PDF. I’ve done extensive work on that step, and given it away for free as open source software.
That said, I think there is real danger in confusing documents for contracts. It’s true that people want contracts, because they want a higher power to stand behind their agreements in ways they can’t stand up for themselves alone. But the “deal” is never just the terms and a couple signatures.
Even if you happen to have a client who happens to have a need that happens to fit a published form that happens to be really well drafted, none of that is going to automatically create any sense of ownership, confidence, or well-representedness in the client or the counterparty. Unless both sides, rather than their lawyers, really just see a written agreement as a red-tape requirement or a form of quasi-religious ritual.
There are some areas that are just so humdrum and repeatable that you really just want a standard form, so you can stop thinking about it. The Waypoint NDA project I’ve run for a few years with others, at waypointnda.com, has saved thousands of hours of pointless review and negotiation. But beyond that, I’ve succeeded with clients (and colleagues) primarily by offering tools and erector sets they can use to up their own game and serve themselves.
Due in part to confidentiality, we can’t build trust in commoditized legal terms as we might in the safety of cars or power tools or rollercoasters or other potentially dangerous equipment. The nearest substitutes are trust—in authority, in reputation, in competence—and hands-on involvement. I think we’ve all seen deals done on terribly drafted terms to the delight of clients, because they trusted their lawyers. And I think we’ve all seen deals where someone originally preserved a perfectly serviceable published or even “standardized” form, but getting a deal ended up requiring an exercise in trust-building over the course of negotiating an objectively inferior set of bespoke terms.
To put it short, after several years, I can no longer pretend to be surprised that MSCD does so much better than finished templates. I still think more “worked examples” are very important, but primarily as power-ups to MCSD and lawyers studying MSCD, not as shortcuts around that process.
“…crufty, obscure data formats that lawyers insist on using, like Word or PDF”. I’m listening. Alternatives? Reasons why?
“…the difficult parts of these projects is often the last step: getting text into one of the crufty, obscure data formats that lawyers insist on using, like Word or PDF. I’ve done extensive work on that step, and given it away for free as open source software.” I would love to trial it, could you please post a link?
I still wonder what the purpose of document assembly is, and who is its intended market. Is it for lawyers to assist them in putting together contracts in a more efficient manner? Is it for companies that use non-negotiable contracts, so that customers can just fill in the blanks? In a world where contracts are negotiated, a clause-selection tool is only helpful as a first step. You still need to understand what is in each clause, why you’ve selected it, and how you can modify it during negotiations. Even in the context of contracts that aren’t negotiated (like website terms of use), it only works if the person using the tool is sophisticated enough and willing to dive into each clause, and fully understand why you would or would not use each alternative. Otherwise, it’s just a fancy tech term for what people already do, which is find contracts on the internet and frankenstein them together into a hot mess, without any understanding of what they are getting.
Hi Paul. The use case that has always been foremost in my mind is allowing companies to create a new template by completing a highly customizable questionnaire and consulting the annotations. The alternative is drafting-by-committee hell, where people with limited expertise spend way too long producing contracts of questionable quality and relevance.
I’m with you, I have extreme intolerance for bad contracts. They exist because, unlike driving a bad car, there are few reliably self-enforcing consequences for using them. A bad contract could be likened to a bad car which will only crash if you drive it on a certain road, which you are fairly unlikely to use. Therefore, most parties get away with using them most of the time.
Hi Stephen. I’d adjust your analogy. The concern isn’t limited to a certain road: contract disputes routinely arise from the unexpected. Perhaps it’s more that the person building the car won’t be driving it, so they’re particularly worried about the odds of crashing.
And bear in mind that the more immediate cost of bad contracts is the day-to-day waste of time and money.