Document assembly
Not the lawyer-killing disruptive legaltech that thought leaders thought it might be way back in 2006.[1]
|
JC pontificates about technology
An occasional series.
|
Its capabilities are limited, it costs a lot (no one has figured out a sensible model for how to price it... by document? by structure? by user?) it is difficult to implement, and it really just isn’t very good. Candidly, it has barely evolved past its original invocation, by noble, fearless and brave legal pioneer nigel molesworth, whose first prototype is pictured at right.
It is specified by IT folk who don’t understand the business application, sold to users who don’t understand the technological benefits of automation, let alone the challenges sub-optimal legal language poses to that benefit, and is commissioned and configured by management consultants who (a) don’t understand (that is, fear) the business application, (b) don’t trust (that is, fear) the legal users; and (c) are motivated to retain control of the process and quash any instinct for flexibility or creativeness by lawyers, whom they are trying to reconceptualise as mute users of overweening technology — that is to say, users.
If document assembly is the answer...
The intuitive case is obvious:
“Document assembly: brilliant: saves time, reduces error, enforces standards, reduces costs.”
Before plunging naked into the warm amber depths, it is worth being self-analytical for a moment. Consider what you already do. We take it as a given that your process is lengthy, error-prone, un-standardised, and expensive. But judge these things relative to your objective. If you are managing a one-off $10bn risk, who cares how long, bespoke and expensive your legal document is?
See also
References
- ↑ Darryl R Mountain: Disrupting Conventional Law Firm Business Models using Document Assembly International Journal of Law and Information Technology, Volume 15, Issue 2, Summer 2007, Pages 170–191.