Document Automation TRIAD

There are many ways to approach document automation. Choosing the right one depends on how much complexity is required — or desired — to get the job done as well as costs associated with implementation. At a fundamental level, you will need 3 components:

• Software: Provides the platform to store the documents, interview questions, as well as programming logic on what to display when the user answers a question.
• Template author: A person who is familiar with said software who will implement the solution by creating and naming variables, and imbedding if-then statements within the document, as to make certain paragraphs and words appear or disappear when certain conditions are met from user choices.
• Knowledge worker: Usually an attorney who intimately understands the business and legal impact and nuances of the document that is being automated. Depending on the training, the template author can be the knowledge worker or vice versa, or a team can be ensembled so that appropriate level of expertise is present to execute the project.

Choosing the Platform and Doers

In terms of software, at the most basic setup would be an attorney utilizing Microsoft Word to do a mail merge, but instead of letters, using legal documents, to automate the document generation. Microsoft Word is capable of going a bit more beyond mail merge, but document automation is not its forte, and specialized software such as HotDocs or Contract Express, will easily outperform Microsoft Word on many aspects, including usability, robustness and programmability.

Unfortunately, there isn’t a unified programming language to program the templates; each platform is different, and some can be quite complex (such as HotDocs) or more user friendly. It does seem, however, that more powerful platforms require more complex and steeper learning curve for programming. A solo practitioner might take the DIY approach with a platform geared towards user friendliness, whereas a small to medium firms might take the consultant approach with higher-end software, whereas larger firms might have an in-house team devoted to automating the documents and maintaining the templates.

Step Preparation for Automation

After you have chosen the software and who will implement, then the work with the documents begin. First is to decide which documents to automate, and this involves, choosing what to NOT automate. Documents that are story driven (like description of facts in a pleading), fact gathering documents (due diligence requests), documents you do not control (opposing counsel opinions), or documents that change at frantic pace (closing checklist) are typically NOT good candidates for automation.

On the other hand, documents that are form driven, frequently used, repetitive in data usage, and come in “sets” make excellent candidates. Examples include estate planning documents (trust, will, power of attorney, healthcare proxy), loan documents (loan agreement, promissory note, guaranty, security agreement, etc.), leasing agreements, employment agreements, and M&A documents are some common documents that are frequently automated.

Second is to organize the documents. Part of the reason for organizing is to help you decide on how to group the document sets and what type of optionalities you want in your automation. So for above example, you might divide the lending documents into Commitment Documents and Closing Documents. And Closing Documents are further divided into Loan Closing Set, and Collateral Closing Set. And both Commitment Documents and Closing Documents will have optionalities for SBA type of loans, or EDA type of loans, as well as including and excluding certain language based on east vs. west coast.

The ultimate goal is to have 2-5 groups of documents, with each group of documents having 2-5 optionalities that allow them to be used in different settings, and you want your templates to cover around 80%+ of all use case scenarios. You typically will not strive for 100% automation coverage, because given the 80/20% rule, diminishing returns will make it more inefficient and expensive to implement less ROI, automating rarely used documents/use case scenario.

Third part to prepare is to review and scrub the documents to be automated. Automation is really nothing more than scaling by selectively copying, and if there is a typo, mistake or error in the template, it will be magnified 100x; in other words, garbage in, garbage out. As such, this would be a good time to have the documents reviewed by outside attorneys and internal review team, and if there are different versions of the same document that is being used, it would be an ideal time to settle on which version would ‘rule’. Make sure that documents reflect what the organization actually does, and consistent with market practice.

Implementation

For implementation, it is time to roll up your sleeves and make it happen (or pay someone to make it happen). I have a few Pro Tips:

1. Start out small, and complete a loop, instead of trying to automate everything. It is important to get something useful to test users earlier rather than later. You can always build and expand more later.
2. Try to improve the aesthetics of the documents.  Making font and formatting consistent among the documents. Make signature blocks consistent.
3. Keep track of variables on Excel, as there can be many, hundreds at least in a typical project.
4. Don’t try to create too many optionalities; it can case ‘decision fatigue’ on users.
5. Receive feedback from various users from different levels of totem pole.  Junior folks will likely be the ones using, and they will often point out things that higher-ups did not think about.  They will appreciate a solution that they contributed to.

Conclusion

Bravo, you did it! But just as you would update your form once in a while, you’d most likely update your forms as well periodically. About once a year is a good pace, though when you first implement, you’ll likely have more updates and revisions, as you expand out.