Document Automation: All that is Old is New Again

By Dera Nevin

Although document automation technology has been around for decades and cannot be said to have “gone away”, it has been enjoying a resurgence in the legal technology press and as a conference topic.   Why might this be, and what does it mean?

“Document automation” generally refers to technology that facilitates document assembly: it will house and organise templates, clause libraries and packages of documents and forms and permit sharing and recycling of content considered “best practice” or “standard”.  Most examples of this technology started to embed “smartness” many years ago by enabling auto-population of certain types of information, such as from an associated database (such as a CRM).  Much of this technology will integrate with both the Microsoft Suite, particularly Word, and with a DMS.  These integrations facilitate document lifecycle management by ensuring the assembly features are accessible through Word and that the document can be saved into a common repository such as a DMS.  Lifecycle management of document assembly products becomes even more powerful when combined with naming conventions for documents; thus, documents which are built from a common template can be easily searched within a DMS or even in a file share.

It’s hard to argue with the benefits of document assembly software, not only within legal but, more generally, where readily available information (such as names, addresses, titles of proceedings, court information, etc.) can be introduced into a pre-formatted document template.  This kind of technology saves time and reduces errors during document creation.  However, a drawback of document assembly technology is that human time and skill is often required at the outset:  in creating forms, in curating document and clause repositories, and in preparing structured data systems from which the document assembly technology draws.  These can be tedious processes that take time and skill to maintain, and often are discontinued once the document assembly technology has been implemented.   The failure to maintain the quality of the data over time erodes the utility of the assembly software: there is no point quickly pulling inaccurate information into a standard form.

Document assembly technology, therefore, is best viewed as a process tool: one that requires both the software and the human resources to maintain the data.  Failure to budget for both within the implementing organisation will, over time, degrade the performance of the system.  Perhaps this is the reason that this technology has failed to become pervasive despite its ubiquity: there has been under-investment in the human side of maintaining the content within it.

I have seen examples, too, where document automation takes on an extended meaning and refers more generally to the automation of processes that depend on textual inputs.  For example, expert system or decision tree software may be referred to as document automation technology, even though such systems instead automate a process that depends on known and repetitive patterns and inputs (largely textual).  Expert system technology has also been around for decades and serves to gain efficiencies and improve consistency of outcomes.  It also is a tool relied on in process mapping.  Perhaps technology that maps decision trees (such as expert systems) is achieving a resurgence because these can help develop maps of conversation flows for chatbots.

A core distinction between document assembly and expert systems is that the former are intended to lead to a textual (document) outcome, whereas the latter can be used to arrive at a decision or awareness of information, but not necessarily a document.  It is helpful to understand this distinction so that one can select the right product category for what the intended outcome of its use will be.

Each of document assembly and expert systems can be important starting points (or re-invigouration points) for more sophisticated offerings, including the use of more advanced technology that incorporates artificial intelligence and analytics.

For example, a curated clause bank within a document assembly system can be used to help identify proprietary or typical critical clauses that might not be contained in an out-of-the-box transactional due diligence tool, and can form a bespoke training set.  Using materials gained from document assembly curation, contract management tools can be calibrated to spot atypical and anomalous clauses from standard form documents, and send for review – including through a decision matrix created within an expert system.  Moreover, the process of preparing data in structured systems such as CRMs, or of reducing or refining the taxonomy in DMS systems (or adding a naming convention) can lead to greater ability to mine existing systems with analytics and search technologies.

Overall, the human processes involved in preparing document assembly and process workflow using expert systems can form the basis for more complete and complex knowledge management, data architecture and inventory programmes that can yield tremendous downstream benefits beyond the efficiencies and accuracy management gained from implementing document assembly.  However, the ongoing human participation of curating and cleaning data, policing naming conventions and updating and enhancing templates remains critical.  And where the artefacts from document assembly and expert systems underpin the data feeding artificial intelligence scenarios and use, ongoing budgeting for maintenance of the data is even more critical.

Dera J Nevin practices Information Governance and eDiscovery at Baker McKenzie LLP and is affiliated with its WhiteSpace Collab Innovation Hub.  Opinions expressed in this article are the author’s alone.  In this space she proposes to address common questions from readers about the evaluation and implementation of legal technology. You can contact the author at  


This article first appeared in the April issue of the Orange rag