When document automation first came on the scene back in the early 1990s, the attraction was having the merge-field capabilities of your word processor, but on steroids. You could complete an interview, populate the document with your answers, and even save those answers to use with another document template. This process provided you with a template that remained consistent, compliant, and error-free. Because the template, provided with new or saved answers, could be assembled multiple times, you saved time in many ways and produced perfect, or nearly perfect, documents. But what was the missing connection of this focus on the template proper and its assembly through user-driven interviews?
Data. Data you already have elsewhere: In an Excel spreadsheet, a SQL database, a Client Relationship Management (CRM) system, and so on. Data, data everywhere, but not a byte processed efficiently through your document automation tool. To be sure, the possibility of connecting to your data might have been offered as part of the solution, but it was often cost prohibitive and, frankly, an afterthought on the part of the software company.
Marketing the Document and Not the Automation
For many years now, document automation has been marketed all wrong. The overriding premise has been that customers want a tool that will allow them to generate documents faster by means of aesthetically pleasing interviews they or their users complete.
Certainly, a solution that does this well has the foundation in place to become a competitive document automation solution. But while there is a case for interviews being presented to a user, the focus on a cog in the overall document generation process wheel ignores the relationships a document template has to data elsewhere. This focus, whether by senior management, product development or marketing, has put user input in the driver’s seat instead of data. Your document automation solution might be a Ferrari, but if you’re relying solely on user input from interviews, you’re going 25 on the Autobahn. Data-driven document automation pushes the limits of what’s possible.
For an example of the user-input option, consider how most organisations onboard a client by entering the client’s information into some sort of CRM. It may be Salesforce or Clio. All the basic information is captured: name, address, telephone, and so forth. Next, the salesperson or paralegal turns to their document automation tool and starts assembling a document. Because the CRM and the document automation tool are not connected, what is the first thing they do? Copy the basic info from the CRM and paste it into the document assembly interview, or heaven forbid, retype it. What was supposed to save time for that very reason (no copy and paste!) has simply moved copy-and-paste to another level.
Data Processing Automation, Outputted Document
Data should flow. Data should be processed. Once entered, you shouldn’t have to enter data again elsewhere.
Speaking to the example above, what ought to happen is that when you launch the assembly of a document, the data you already have for a Client populates the document fields automatically. Now, depending on how many data values have already been answered by the data in your CRM or other database, you may or may not need to present an interview to the User. If all your data points have been answered, then you can bypass an interview altogether and just output the assembled document; otherwise, you may present the user with an interview that addresses unanswered values. Either way, just like the ancient Greek philosopher Heraclitus said about never stepping in the same river twice, you never touch your data twice.
If you measure against this standard of processed data driving document automation, you can judge for yourself whether the document automation solution you’re currently using has the following characteristics:
- Holistic. Views the document automation process as more than a simple interview plus merge platform, but a piece of the overall data processing workflow puzzle that fits nicely in its space and connects seamlessly with the pieces around it.
- Out-of-the-Box. The data connectivity possibilities are part of the document automation solution already. The software provider has anticipated the data connection needs of its market and has made it so that the ability to connect to your data is out-of-the-box functionality and not something you can only get by paying extra for an integration solution.
- Security. Your data throughout the entire process is kept secure with state-of-the-art methods appropriate to your workflow. Whether it’s encryption, permissions, on-premise or in-the-Cloud safeguards, your document automation solution protects your data and ensures that you are compliant with data privacy regulations.
Put Your Data in the Driver Seat
Document automation as a concept promises to save you time, but if the solution doesn’t capture the data you already have somewhere, any time saved becomes a wash. You have invested time and money in a solution that provides little return.
If this is your situation and you already have a document automation solution, explore what options you have within your current solution to connect with your data. If your solution doesn’t have the capability you need, then enlist the help of DocGovern to guide you in the choice of a document automation solution that will meet your data connectivity requirements.
If you’re new to the document automation market, remember this: You have data; you just need a tool to process that data into documents. Require the capability to process your data of any document automation solution you consider.
In the 21st century, data must drive the generation of documents. Anything less is stuck in the 1990s slow lane.
How does data drive your document automation process?