82,891
edits
Document assembly: Difference between revisions
no edit summary
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{a|tech| | {{a|tech| | ||
{{Image|Self-adjusting thank you letter|jpg|[[nigel molesworth|Molesworth]]’s [[self-adjusting thank-you letter]], the first recorded instance of document assembly in legal history}} | |||
}}Not the [[Mediocre lawyer|lawyer]]-killing disruptive [[legaltech]] that [[thought leader|thought leaders]] thought it might be way back in 2006.<ref>[https://doi.org/10.1093/ijlit/eal019 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. </ref> | }}Not the [[Mediocre lawyer|lawyer]]-killing disruptive [[legaltech]] that [[thought leader|thought leaders]] thought it might be way back in 2006.<ref>[https://doi.org/10.1093/ijlit/eal019 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. </ref> | ||
| Line 12: | Line 12: | ||
“Document assembly: brilliant: saves time, reduces error, enforces standards, reduces costs.” | “Document assembly: brilliant: saves time, reduces error, enforces standards, reduces costs.” | ||
Before plunging | Before plunging your pinkly into those warm amber depths, it is worth being self-analytical for a moment. Consider ''what you already do'', what is wrong with it, and therefore by deduction ''what you are trying to fix''. It might surprise you. | ||
We take it as a given that you will say your processes are lengthy, un-standardised, expensive to maintain and prone to error. This may even be one of those rare things about which the organisation finds consensus. It may seem so self-evident that the firm’s usual period of obligatory bureaucratic introspection can be dispensed with. | |||
Resist this thought. For these things are relative, and you must judge them against your objective. If you are managing a one-off, $10bn risk, who ''cares'' how long, bespoke and expensive your legal document is, as long is it aids your management of that risk?<ref>It won’t, of course, but [[don’t take a piece of paper to a knife fight|that is another story]].</ref> | |||
A [[root cause analysis]] may help you get to the heart of the matter. | |||
If the subject matter is it quotidian, throughput high and the usual negotiation load light — [[terms of business]], say — then fix your contract form so it doesn't ''need'' automation. Genericise it. Cut out some of the [[verbiage]]. Drop an [[indemnity]]. Seriously, will you miss it? | |||
If heavily negotiated, then — firstly, same; see what you can simplify and strip out to save having to argue about it — but once you've done that, ask ''how much time will automating save''? A draft that takes 30 minutes to prepare in the context of a three-month negotiation, as is common for an {{isdama}}, is really not the problem you need to be solving. | |||
{{sa}} | {{sa}} | ||
*[[Reg tech]] | *[[Reg tech]] | ||
*[[Nigel molesworth]] | *[[Nigel molesworth]] | ||
{{ref}} | {{ref}} | ||