It’s the software’s fault
One of the biggest complaints I’ve heard about document automation software is that the programs are too complicated to use, so you must hire a developer to create your templates for you. If you’re on a budget, paying thousands of dollars for a template set is out of the question.
In reality, though, most document automation platforms are scalable, meaning that if you want to keep things simple, you can. Anyone who has done Mad Libs should be able to use the tool of choice to create a simple template.
But simple isn’t always what we want, right?
Add to that the question of whether an attorney’s time is better spent in lawyering than it is in setting up his or her template set? (Sometimes, it’s worth the price to pay someone else to develop templates to gain the coveted workflow efficiency faster.)
It’s the client’s fault
Speaking from a developer’s perspective, the complexity can arise from a client’s requirements. If they understand the capabilities of the tool, they often want a World of features for the price of Greenland. In general, it’s easy to get the impression that we developers have a magic button that when pressed will automate a 50-page contract in less than 30 minutes, interview and all, but the truth is that even basic template development takes time.
To be sure, a client’s requirements are a good thing. They often drive a template developer’s creativity in using the platform of choice in new ways, as well as spurring on product development. Speaking of the developer…
It’s the developer’s fault
What if we developers are guilty of taking an otherwise “basic” template development project and creating template complexity, just because we can? Instead of opting for the simple fields a client is used to filling out, in TurboTax or the like, we complicate things by adding complexity the client didn’t explicitly ask for, because we “know better,” thinking the client will “thank us later.” A simple name field becomes four fields: first name, middle name, last name, and suffix. An address block becomes street address 1, street address 2, city, state, and zip. And so on.
Especially when clients are new to document automation, they often don’t know what’s possible, how scalable it can be. So, as a developer, it’s easy to want to wow them with the little extras we can throw in. But it’s better to clarify expectations up front as much as possible, because the more time we spend building in complexity the client didn’t ask for, the more we eat away at the hours allotted for the work. This then leads to scope creep and the client wondering what all the hours were used for.
I’ve spent some time learning about different document automation platforms over the past few months, and no matter which one you settle on, if you do the template development yourself, you will have to get up to speed on what to do to get the templates you want. Call it coding, authoring, or markup, you will need to invest some time getting used to the tool. It is true that some platforms make template authoring easier out of the box than others, but often what you gain in facility of template development, you lose in scalability. Depending on your needs, that may be all right.
You can keep things simple and just place basic fields on a form, essentially creating the digital equivalent of filling out a physical document by hand. But if you want any of the functionality that makes a template “complex,” then you must overcome the learning curve, however steep it may be.
What then makes a template “complex”?
A number of things can make template development a complex endeavour, but here are those elements that make the short list:
- IF-logic, where you have multiple conditioning paths through a document, including embedded levels of choices. This requirement often arises from the need to have one document template account for several versions of the original source document, so it becomes a “choose-your-own-adventure” type of template.
- Repeats, whether repeating the document itself, or simply having repeated information or lists in the document. The former is a more complex requirement and only a few document assembly systems accommodate it, while the latter is a common feature of most systems, but some systems limit how many embedded levels you can have.
- Signature blocks, their variations and levels deep. Big banks often need this capability.
- Calculations of inputted numbers, the formatting of numbers (e.g., forty-nine ), the summing up of numbers entered in a loop, the accounting for different currency denominations, all of these and more can make a Financial Statement, for example, a complex endeavor.
- Interview flow, having to explicitly instruct the program how to present the interview instead of accepting the default flow from the program.
- Mapping variable fields to external data using APIs or built-in components.
Complexity in document automation is a good thing
Most people who buy document automation software want to be able to do the things listed above. Some document automation platforms make it easier than others to implement this functionality in your documents, but once it’s set up, you benefit from being able to produce sophisticated documents faster. A simple merge system just doesn’t cut it.
A takeaway here is that document automation is scalable, so it can be as simple or as sophisticated as you want it to be, but to achieve any of the coveted complexity often adds to the needed template development time.
In a future post, I will highlight some things to look for in document automation software. But for now, embrace the complexity. Look forward to the return on your investment of time and resources to achieve a faster document assembly workflow.