Document automation: If it’s so good, why isn’t everyone using it?
About Charles Drayson
“I get a kick out of creating good content and seeing it used repeatedly and reliably by colleagues without fuss and bother”.
Back in the day – when software was shipped in boxes with CD media – I heard it said that document assembly software was most often found sitting on the shelf in the offices of law firms, like some toy put aside after Christmas. The early adopters were individuals who risked colleagues questioning whether it was the best use of their time. With very few exceptions, use cases were limited to small-scale back-office projects, and wider adoption met with reactions varying from hostility to bemusement.
A decade later, at a time of austerity after the 2008 financial crisis, a UK government initiative included document automation in a shortlist of technologies that had the best chance of delivering quick returns on investment and efficiency gains for public sector services. That’s how I came to be talking to a group of senior executives in the UK’s National Health Service. One representative said he could see how other departments might get benefits, but the NHS didn’t have many standard documents they could automate. I knew that was incorrect.
I had recently received an NHS appointment for the termination of my pregnancy. Readers, I am male. I called the clinic and explained there must be a mistake. No, it wasn’t a mistake, they said, apparently not grasping the obvious impossibility. They then explained. I had been on the waiting list for a separate surgical procedure, but they had a standard letter for all appointments in that clinic! The ‘system’ generated it.
The first premise for this article is that most organisations generate documents by customising a standard template. If done by humans, that task is performed with varying degrees of accuracy, time, competence and tedium. It’s been like that for years.
To consider the question posed in the title, we must acknowledge a second premise: document automation technology works. Unlike AI, we are swell past experimental solutions that produce patchy results. Organisations can buy reliable document automation software from multiple vendors ranging from venerable to modern.
If there’s a need for document automation, with tried-and-tested solutions available to do the job, why isn’t it mainstream by now? Inevitably, there are multiple factors in play, and cumulatively they create a misleading impression that deter adoption.
If you are familiar with the technology adoption cycle brilliantly explained in Geoffrey Moore’s ‘Crossing the Chasm’, you need to know that document automation has moved beyond the ‘early adopters’, and has at least reached the ‘early majority’. Many organisations are using it, but it’s not prominent. The nature of the technology means that document recipients don’t know they are consuming the work product of document automation. The technology is good enough to create customised documents. Customisation of documents, like customisation of products and services, is what people expect. Organisations have little incentive to shout about the gains they obtain from smart technology. It’s enough that the COO and CFO appreciate the benefits. The vendors publish case studies (you can see ours here), but they tend to be seen by organisations already looking for a solution.
Nevertheless, uptake of document automation has been steady rather than rapid. The legacy applications from the vendors who dominated the market sometimes struggled to shift document automation from ’nice-to-have’ to something sufficiently compelling to rise to the top of someone’s to-do list. Despite two decades of development, the first-generation applications were functional but burdened by designs that were not as satisfying as they needed to be. The software had inherent limitations. It has taken a new generation of software to throw off the obstacles and produce solutions that feel complete and readily deployable. There is objective evidence to show that these solutions are finally causing industrial-scale adoption and will become ubiquitous.
Vendors like Legito acknowledged the reluctance to deploy tools that needed coding skills or depended on scripting that looked like coding. It was too hard to put those skills quickly into the hands of authors, the people who were the subject matter experts for document content. Early document automation was aimed at law firms. Not many lawyers have the aptitude to draft legal text as well as the coding skills needed to write and manage templates. There was a tendency to use ‘developers’ to create the documents, which was sub-optimal. No-code tools like Legito overcome that problem and free up authors to focus on the content rather than the development process. Such tools are empowering and pleasant to use.
The next paradigm shift was the deployment of document automation with a suite of features that facilitates the management of documents and workflow to move them through a business process. First-generation applications didn’t do much more than assemble documents using data provided by a user through some form of interview. There was little recognition that the data might already exist in machine-readable form in another system. Users mostly had to re-key data, thereby re-introducing opportunity for human error, and it is tedious work. There was even less recognition of what happens to a document after production: there was no document management or workflow capability. Document generation was disconnected from the business process.
An organisation ready to benefit from document automation will soon get frustrated if the technology is limited to just creating the document, useful though that is. Increasingly, a document is a vehicle for carrying data, but presented in a human-readable way. The data might flow from other systems. When the document is ready, the data (now encapsulated into the document) should flow to where it is needed. It needs to be stored reliably and methodically. Perhaps it needs to pass through several people to add more information or approvals or comments, and then it typically moves to a signature process. Maybe there are several iterations of the document before it is ready to be signed. That’s how documents move in the real world. They are part of a wider business process. Academics built first-generation document assembly applications. Practitioners built next-generation solutions. They didn’t have to accept the legacy of the older solutions.
The third significant development came from evolution rather than design, but it is pivotal to the fast uptake of modern document automation. The pioneering users of first generation document assembly applications are in the later stages of their careers. It’s a trite observation that people joining organisations today are digital natives and more of them arrive with graduate-level education. They will have neither the patience nor the temperament to perpetuate outdated working practices. They intuitively recognise tasks better done or augmented by technology. They expect short cycle times, high-performance, and customised outcomes from tools that are not clunky.
‘Document automation’ is perhaps the wrong label. The process of assimilating data to create a document and marshalling the document through a business process will be increasingly indistinguishable from any other step in the process. Tools like Legito will tend to consume data from one system, re-formulate it for human reading, and carry the data intact into another system. They will make work better for humans but they will fit neatly into data-driven environments. In the future, we won’t need AI to interpret document collections. That’s why we now see industrial-scale adoption.
More Industry Insights