By Kathy Valentine & Ryan McClead
There seems to be a renaissance in document automation happening in legal. Maybe the fear of an economic downturn has firms returning to the basics of innovation? Maybe new players in the market have prompted firms to dust off their long-dormant doc auto plans? Maybe clients and prospects have just started coming to Sente with more doc auto questions since we started offering dedicated document automation services?
Regardless, we are getting a lot of questions these days. Which platform is best? What features do we really need? Why is it so hard to estimate how long it will take to automate this 600 page document?
Unfortunately, there is no single best, one-size-fits-all, document automation platform that every firm should buy. But there are a number of items you should take into consideration to ensure that you’re getting a document automation tool that will meet your firms needs for the foreseeable future.
1. Identify Sample Documents, Document Sets, and Pilot Users and Coders
Don’t go looking for a platform without already having a handful of automation candidate documents in mind. Clearly articulate your use-cases in writing and, identify a group of enthused and engaged pilot users who are willing and able to help you assess the platforms you are going to evaluate. Ensure that your pilot users include those who will be building your automated documents.
Make sure your candidate documents include a variety of document types, ranging from simple to complex. Include a least one “document set”; a series of documents, some or all of which will need to be created depending on a user’s given answers. Include scenarios for external or client-facing documents, as well as internal-only processes. Understand the scale of your doc automation problem - what kind of hours / time is currently dedicated to manually generating each of your candidate documents? Identify “champions” for each document and quantify their pain points.
2. The Questionnaire Experience
Every automated document begins with a questionnaire of some sort. A user answers a series of questions, submits their answers, and then voila, documents are created that incorporate their answers. The questionnaire is the primary way that most people in your firm will interact with your document automation platform. A bad questionnaire experience will undermine everything else about the platform.
Some items to consider:
Can the user preview their document while they’re still answering the questionnaire? Does the platform easily show the user the parts of the document that will be impacted by the current question (including in multiple documents that are part of a document set)? How are drafting notes or guidance notes handled in the questionnaire? Can they be easily collapsed (only shown if the user clicks to see them)? Can you insert a link to a video or to other internal or external guidance notes? Can you create multiple sections in the questionnaire to group similar questions together? Can you customize the formatting of the questionnaire? How easy is it to make these changes? Can you use previous answers to questions in later questions? For example, first name is entered as “Sam”; can the follow up question be: “What is Sam’s title?” Can questionnaires be made available to clients or other external parties?
3. The Automation Process Experience
While most people will only ever see the questionnaire, your “document coders” will be up to their elbows in the guts of the platform. Understand the working environment in the automation platform.
Where does document generation start? Can you begin with a document already created in Word? Where is the coding actually done? Do you enter fields and calculations in the Word document itself using an MS Word plugin, or do you need to use the platform’s own document editor? What are the transfer points to and from Word? Can you export the document (already with coding), send it to someone to edit, and re-upload the document without losing the coding? What workflow options are available? Does the platform simply generate the document? Or can it also send for approval, signatures, etc.?
4. Conditional Logic
The work-horse of document automation is conditional logic. “Inline” conditionals change words within a sentence like “party” to “parties”, and “Block” conditionals use logic to include entire sentences, clauses, paragraphs or document sections, based on the user’s answers.
Understand how your platform manages both inline and block conditional logic, with both single and multiple condition scenarios;
Confirm that answers to conditional logic will control the questionnaire process, i.e. A user should never be asked the same question more than once in a single questionnaire. The questionnaire should never ask nonsensical questions. For example, if you ask ”do you have children?” you don’t want to ask “how many” if the user says they have none. Do you need to order questions in a particular way to ensure conditional logic works properly? How does the platform handle multiple conditions within a table or array?
Formula calculations are where document automation can really shine or completely fall apart. Make sure you test your platform’s calculations and understand how they will work for your firm, with your firm styles, and to accomplish your document needs. Especially make sure you test date math and financial calculations. You should never need to ask a user for numbers that you can calculate based on other answers they’ve already given. For example,
A Date of hire can be used to calculate date of review and resulting bonus, or In an Offer Letter application, can you calculate monthly salary depending on role, location, and whether remediation measures are in place?
6. Multi-level numbering and field codes
Numbering is often handled by MS Word itself, but different platforms interact with Word numbering in different ways.
How are embedded numbers in a paragraph handled? For example, can the user select from a list of numbered items to show up below a paragraph, where the numbering will update accordingly in the final document based on which items the user selected? Are cross references automatically updated? Can they be generated automatically from references typed into Word already?
7. Loops, Repeats or Instances
How are multiple instances of something handled? For example,“for each borrower, please provide the following information.”
How is punctuation controlled when multiple instances are listed inline or in a table? Can you create separate documents in a set specific to each instance? For example, if Role is “President,” generate document X; if Role is “Shareholder,” generate document Y.
8. Document Sets
Document sets include multiple documents automated from responses to an initial questionnaire. Examples include a set of real estate leases with multiple schedules or incorporation documents.
Can you display a menu allowing a user to choose which documents to include, including “select all”? Can you insert a document into another based on answers in the questionnaire? Is section formatting honored or stripped?
9. The Generated Document
Of course, the ultimate value of any doc automation platform is dependent on the resulting document. Here too, not all platforms are as flexible in creating the final output as you may want.
How do they control variable formatting? For example, can the same variable be displayed in one part of the document in all UPPER CASE, but somewhere else as Initial Caps? Can numbers appear in text (”Five Thousand Dollars”) even though they were answered numerically ($5,000.00)? How does the platform handle unanswered questions? If a question is optional, can you change text in the document accordingly (for example, if date is known then provide a calendar to choose from; if date is not known then insert a placeholder [executionDate] or a blank ____ for manually filling in the document later. Can you control how unanswered questions will show up in the document? How do you control the name and filing location of the generated document(s) (i.e. are documents automatically saved into the DMS? Connected to client-matter #)? How does “round-tripping” work? That is, can a completed document be downloaded, completed, returned, and re-uploaded, maintaining the data integrity?
Finally, it’s important to understand how the platform handles data, ideally integrating with internal and external systems to pre-fill known data (client name, company address, etc.), as well as storing questionnaire responses for data analysis, aggregation, and later retrieval.
Can you create multiple documents by importing answers from a spreadsheet or database records? For example: You have a list of new hires for the summer associate program in a spreadsheet and want to generate all their letters at once. You want to generate a letter to all partners with their compensation information from data in both the accounting and HR systems. Can you use data sources to update the questionnaire or document? For example: You have a firm internal database with Office Locations and other pertinent information. You want to query this table to determine where the agreement is being signed in order to generate the correct signature block. You want to pull data from an internal database to populate a drop-down in the questionnaire as the user is filling in answers. Can you export data captured in the app to use for analysis? For example: For a series of offer letters, can you export data into a spreadsheet to determine how many and what percentage of new hires are in each region or practice group and how many would meet diversity requirements? In templates for trademark forms, can you export data to determine which templates are used most and in what situations. Can you capture data from answers to one questionnaire for use in other documents?
These 10 considerations are based on our actual experience creating automated documents and document sets for law firms over several decades. No two platforms will handle these items in exactly the same way and some platforms may not be able to handle several items at all.
The right platform for you and your firm doesn’t have to tick all of these boxes, and it doesn’t have to handle each item in exactly the way you would prefer. Other considerations like infrastructure (on-prem, SaaS), security, and cost will all play a big role in determining the tool your firm ultimately purchases, but it’s important to understand (and document) the functional limitations of the platform you buy as well. If your end-users and document coders are all comfortable with those limitations (and any “hoops” they may have to jump through to work around them) then go ahead and make your purchase confidently, but keep your limitations document handy.
If you haven’t evaluated your prospective platform for the functions we’ve listed, or if your users haven’t signed off on any limitations you’ve identified, then maybe you should go back to do some further evaluation.
Because chances are, if you buy the wrong document automation platform, no one is going to use it.