Select Page

When Documents Meet Reality

When Documents Meet Reality

Sep 21 · 2 min read

Process Failures

Last month, I made a claim for my wife under a health insurance policy. It was a stressful situation needing quick treatment. We called the claims number to begin the process. The claims handler said my wife was not covered under the policy; the relevant hospital consultant was not recognised by the insurers, and the procedure was outside the scope of cover. We arranged the procedure without their help. Time was pressing.

It later transpired that all three assertions were incorrect. They asked if we wanted to make a complaint. We did. They stated their procedure for handling complaints, and then missed their self-defined timescales for investigating.

I am surely not alone in experiencing a situation where an organisation says one thing and does another. Why does that happen?

I suspect process failures cause many mistakes. I further suspect that many process failures arise because there is no reliable connection between a promise in a document and organisational readiness to deliver on the promise. We are too accepting of that disconnect. It’s the same reason why business teams sometimes talk proudly about signing a contract and then putting it in a draw (never to be used). If we can make promises in documents without being accountable for performance, no wonder we end up with lengthy policy documents that are ignored and protocols that probably wouldn’t survive a first contact with reality.

If we see fit to make promises, plans and decisions in accordance with a document, it is possible to flow documented commitments into a delivery process that aims to comply. Moreover, if we at least try to connect the documents to the delivery process, we might discover glitches before we disappoint the customer or do damage somewhere in the supply chain. If we find we cannot connect the commitments to the delivery process, we must invoke a manual intervention to bridge the gaps, or maybe stop making promises that are not achievable.

My past experience working as a lawyer for a large business process outsourcing company, revealed a consistent root cause when we retrospectively reviewed occasional service failures. In almost all cases, the root cause of failure could be traced back to a customer asking us to do something non-standard, often in a hurry as a favour, and our teams did what the customer wanted without the guard rails of a procedure that trapped errors.

Some documents, if they are intended to create action, should be part of a reliable workflow. The workflow doesn’t have to be automated, but automated workflow are dependable. Integrating documents within a workflow means documents should be created in a way that ensures they are tailored to finite, known boundaries – with options that match what you can deliver.

Unless you are documenting a service that can be truly bespoke, such operational documents should not be an opportunity for artistic flourish in the hands of your employees. If they find the ‘system’ doesn’t let them do what they want to do (“Computer says no”), provide an escalation route that ensures a human checks whether the non-standard items are sensible. A system that doesn’t cater to infinite options is your friend.

When Documents Meet Reality

Sep 21 · 2 min read

Process Failures

Last month, I made a claim for my wife under a health insurance policy. It was a stressful situation needing quick treatment. We called the claims number to begin the process. The claims handler said my wife was not covered under the policy; the relevant hospital consultant was not recognised by the insurers, and the procedure was outside the scope of cover. We arranged the procedure without their help. Time was pressing.

It later transpired that all three assertions were incorrect. They asked if we wanted to make a complaint. We did. They stated their procedure for handling complaints, and then missed their self-defined timescales for investigating.

I am surely not alone in experiencing a situation where an organisation says one thing and does another. Why does that happen?

I suspect process failures cause many mistakes. I further suspect that many process failures arise because there is no reliable connection between a promise in a document and organisational readiness to deliver on the promise. We are too accepting of that disconnect. It’s the same reason why business teams sometimes talk proudly about signing a contract and then putting it in a draw (never to be used). If we can make promises in documents without being accountable for performance, no wonder we end up with lengthy policy documents that are ignored and protocols that probably wouldn’t survive a first contact with reality.

If we see fit to make promises, plans and decisions in accordance with a document, it is possible to flow documented commitments into a delivery process that aims to comply. Moreover, if we at least try to connect the documents to the delivery process, we might discover glitches before we disappoint the customer or do damage somewhere in the supply chain. If we find we cannot connect the commitments to the delivery process, we must invoke a manual intervention to bridge the gaps, or maybe stop making promises that are not achievable.
My past experience working as a lawyer for a large business process outsourcing company, revealed a consistent root cause when we retrospectively reviewed occasional service failures. In almost all cases, the root cause of failure could be traced back to a customer asking us to do something non-standard, often in a hurry as a favour, and our teams did what the customer wanted without the guard rails of a procedure that trapped errors.

Some documents, if they are intended to create action, should be part of a reliable workflow. The workflow doesn’t have to be automated, but automated workflow are dependable. Integrating documents within a workflow means documents should be created in a way that ensures they are tailored to finite, known boundaries – with options that match what you can deliver. Unless you are documenting a service that can be truly bespoke, such operational documents should not be an opportunity for artistic flourish in the hands of your employees. If they find the ‘system’ doesn’t let them do what they want to do (“Computer says no”), provide an escalation route that ensures a human checks whether the non-standard items are sensible. A system that doesn’t cater to infinite options is your friend.

More Weekly Articles

Start Automating Now

5 Reasons Why Home-Grown Solutions Don’t Last

5 Reasons Why Home-Grown Solutions Don’t Last

Sep 14 · 1 min read

Some organisations come to Legito from a competitor solution, and some have no existing solution, but today I’m talking about organisations who have built a home-grown solution that isn’t meeting their needs.

Organisations with a requirement for automation are frequently big enough to employ technologists somewhere in the building. Or maybe they have a few people who have become experts in doing clever things with the usual office applications. One can do a lot with the standard suite of Microsoft office applications, especially if you’re willing to write some VBA code or macros. If your team needs a quick fix to a tedious or repeat task, there are many reasons why it might be appealing to build something rather than buy a solution from a vendor. If it fails, there’s no obvious penalty, or difficult conversations about wasted expenditure, and at least you can justify why you need to buy something instead? But…

5 reasons why home-grown solutions don’t last

#1 Document automation is harder than it looks

Building sophisticated solutions is technically demanding when you get beyond mail-merge, quick-parts, and other quasi-automation tools in Word. The first document automation solution to achieve commercial success had over one million lines of code – and it was years before vendors could offer the automation options you can get now.

#2 Home-grown solutions get stranded when people leave or move to other projects

I worked with an organisation that used a clever spreadsheet to calculate pricing. It was issued to all the sales execs. No doubt, the guy who created the spreadsheet was an Excel wizard, and the tool was smart. And then he left. Not a single person could fathom how to update the spreadsheet.

#3 Office applications evolve

I have a family member who worked for a large public organisation I dare not mention. That organisation generated some rather important documents. A keen individual wrote a script for Word. He shared it with colleagues. Soon, everybody used it. Microsoft brought out a new version of Word, with the .docx format – and the script was incompatible with the new version. The IT team had no awareness of the automation. As the new version of Word rolled out, it just stopped working. Sure, he could have updated the script – but he had authored many documents, and it would take time – which they didn’t have.

#4 In-house solutions are not built to be resilient or secure

Automation does more than execute tedious work. Modern business needs for automation frequently include business controls and compliance. There’s a need to ensure tasks are done correctly by people with the designated authority and backed up with auditable records. Business processes invariably require processing of personal data or confidential information. Enterprise-grade security and resilience must be designed into a solution, and that requires skills which are scarce.

#5 Off-the-shelf solutions have a lower cost of ownership

Volume fees from numerous users finances the build cost of commercial software. More commercial software is now supplied as a cloud-based solution which includes the cost of hosting the solution and providing support. The true cost of building and deploying an in-house solution is probably not measured – but it’s real and costly.

5 Reasons Why Home-Grown Solutions Don’t Last

Sep 14 · 1 min read

Some organisations come to Legito from a competitor solution, and some have no existing solution, but today I’m talking about organisations who have built a home-grown solution that isn’t meeting their needs.

Organisations with a requirement for automation are frequently big enough to employ technologists somewhere in the building. Or maybe they have a few people who have become experts in doing clever things with the usual office applications. One can do a lot with the standard suite of Microsoft office applications, especially if you’re willing to write some VBA code or macros. If your team needs a quick fix to a tedious or repeat task, there are many reasons why it might be appealing to build something rather than buy a solution from a vendor. If it fails, there’s no obvious penalty, or difficult conversations about wasted expenditure, and at least you can justify why you need to buy something instead? But…

5 reasons why home-grown solutions don’t last

#1 Document automation is harder than it looks

Building sophisticated solutions is technically demanding when you get beyond mail-merge, quick-parts, and other quasi-automation tools in Word. The first document automation solution to achieve commercial success had over one million lines of code – and it was years before vendors could offer the automation options you can get now.

#2 Home-grown solutions get stranded when people leave or move to other projects

I worked with an organisation that used a clever spreadsheet to calculate pricing. It was issued to all the sales execs. No doubt, the guy who created the spreadsheet was an Excel wizard, and the tool was smart. And then he left. Not a single person could fathom how to update the spreadsheet.

#3 Office applications evolve

I have a family member who worked for a large public organisation I dare not mention. That organisation generated some rather important documents. A keen individual wrote a script for Word. He shared it with colleagues. Soon, everybody used it. Microsoft brought out a new version of Word, with the .docx format – and the script was incompatible with the new version. The IT team had no awareness of the automation. As the new version of Word rolled out, it just stopped working. Sure, he could have updated the script – but he had authored many documents, and it would take time – which they didn’t have.

#4 In-house solutions are not built to be resilient or secure

Automation does more than execute tedious work. Modern business needs for automation frequently include business controls and compliance. There’s a need to ensure tasks are done correctly by people with the designated authority and backed up with auditable records. Business processes invariably require processing of personal data or confidential information. Enterprise-grade security and resilience must be designed into a solution, and that requires skills which are scarce.

#5 Off-the-shelf solutions have a lower cost of ownership

Volume fees from numerous users finances the build cost of commercial software. More commercial software is now supplied as a cloud-based solution which includes the cost of hosting the solution and providing support. The true cost of building and deploying an in-house solution is probably not measured – but it’s real and costly.

More Weekly Articles

Start Automating Now

Advanced automation features

Advanced automation features

About Charles Drayson

Charles is a UK lawyer who has used document automation for 20 years. He has worked for large law firms, corporate legal teams, and has automated legal and non-legal documents. He writes for Legito to share his passion for using automation to get work done. “I get a kick out of creating good content and seeing it used repeatedly and reliably by colleagues without fuss and bother”.

Advanced automation features

Charles Drayson

Aug 30  · 5 min read
Charles Drayson
Aug 30 · 5 min read
Comparing automation solutions is tricky if you don’t know what the more advanced features will do or whether you need them. Is it likely that you would use only the basic features, and anything else means paying for complexity and bloat that you don’t need? The assessment is harder if this is the organisation’s first deployment of an automation solution. A demo is good, but each vendor will run a demo that looks slick.

Comparing automation solutions is tricky if you don’t know what the more advanced features will do or whether you need them. Is it likely that you would use only the basic features, and anything else means paying for complexity and bloat that you don’t need? The assessment is harder if this is the organisation’s first deployment of an automation solution. A demo is good, but each vendor will run a demo that looks slick.

ADVANCED FEATURES – AM I JUST ADDING UNNECESSARY COMPLEXITY AND COST?

ADVANCED FEATURES – AM I JUST ADDING UNNECESSARY COMPLEXITY AND COST?

Successful projects create a demand for more. Most vendors (including Legito) advise starting with a simple project and then building incrementally. Projects which begin with large, ambitious rollouts carry risk. The first project is usually a success, unless an organisation has bought something completely unsuitable. Unfortunately, some organisations find it hard to increase adoption after the first project. What will you find when it’s time to take off the water-wings and swim in the deep end?

If you decided to invest in automation, it’s probable that some of your needs were not simple. Organisations are messy. Departments want different things. For every process, there are exceptions. You might have a standard document broadly suitable for most occasions but ideally suited to almost none. You map out a process, and then someone changes it, or you find that people are not following policies. If you over-simplify the solution, your colleagues will not use it, find ways round it, or complain loudly that it doesn’t work.

Successful projects create a demand for more. Most vendors (including Legito) advise starting with a simple project and then building incrementally. Projects which begin with large, ambitious rollouts carry risk. The first project is usually a success, unless an organisation has bought something completely unsuitable. Unfortunately, some organisations find it hard to increase adoption after the first project. What will you find when it’s time to take off the water-wings and swim in the deep end?

If you decided to invest in automation, it’s probable that some of your needs were not simple. Organisations are messy. Departments want different things. For every process, there are exceptions. You might have a standard document broadly suitable for most occasions but ideally suited to almost none. You map out a process, and then someone changes it, or you find that people are not following policies. If you over-simplify the solution, your colleagues will not use it, find ways round it, or complain loudly that it doesn’t work.

YOU THINK YOU ASKED ALL THE STAKEHOLDERS ABOUT THEIR REQUIREMENTS, AND, AFTER YOU BUY THE SOLUTION, YOU FIND THEY ASK FOR SOMETHING DIFFERENT.

YOU THINK YOU ASKED ALL THE STAKEHOLDERS ABOUT THEIR REQUIREMENTS, AND, AFTER YOU BUY THE SOLUTION, YOU FIND THEY ASK FOR SOMETHING DIFFERENT.

This is why, sooner or later, you will want advanced features. The Pareto Principle still works – you will get 80% of the benefit from 20% of the features, but there are three more factors to consider:

  • It’s hard to predict which features will form the 20% delivering most of the benefit. 
  • As you expand across the enterprise, each department might depend on different features. 
  • People who get good at developing solutions using Legito don’t want to stop at 80% – believe me, it’s addictive, and you will want more.

It’s like buying a car. I still remember cars without electric windows – we thought it was mad that some people would pay extra money to save the effort of winding down a window by hand. Remember manual chokes to get engines started? They were not exactly complex, but none of us looked back after electronic ignition. When cars first had air conditioning, it seemed extravagant. As for heated steering wheels, why would anyone need one? But, the driving experience with all those features is fundamentally different from the experience of the sort of cars I first drove as a teenager. There’s another similarity with buying software solutions: if you buy something basic, it might be impossible to retrofit the features you need – you have to buy again (and write off the investment in the first solution). For the manufacturers, it was hard to upgrade legacy models to compete with new modern designs.

Next-generation automation solutions compared to legacy solutions are, like modern cars, easier to use and more amenable to wide adoption by colleagues who are increasingly intolerant of mediocre technology.

What are the advanced features that make the difference?

This is why, sooner or later, you will want advanced features. The Pareto Principle still works – you will get 80% of the benefit from 20% of the features, but there are three more factors to consider:

  • It’s hard to predict which features will form the 20% delivering most of the benefit. 
  • As you expand across the enterprise, each department might depend on different features. 
  • People who get good at developing solutions using Legito don’t want to stop at 80% – believe me, it’s addictive, and you will want more.

It’s like buying a car. I still remember cars without electric windows – we thought it was mad that some people would pay extra money to save the effort of winding down a window by hand. Remember manual chokes to get engines started? They were not exactly complex, but none of us looked back after electronic ignition. When cars first had air conditioning, it seemed extravagant. As for heated steering wheels, why would anyone need one? But, the driving experience with all those features is fundamentally different from the experience of the sort of cars I first drove as a teenager.

There’s another similarity with buying software solutions: if you buy something basic, it might be impossible to retrofit the features you need – you have to buy again (and write off the investment in the first solution). For the manufacturers, it was hard to upgrade legacy models to compete with new modern designs.

Next-generation automation solutions compared to legacy solutions are, like modern cars, easier to use and more amenable to wide adoption by colleagues who are increasingly intolerant of mediocre technology.

What are the advanced features that make the difference?

#1 No code development

I liked writing code using the first generation of document automation solutions. It was satisfying to get it right. But, I was one of those who also liked programming as a kid, and I relished the challenge. If you want your subject experts to build a solution for their teams, you could look around for people who also like messing around with code.

Here’s the problem: not many people fall into that category, and even if they do, not many organisations want to pay their key staff to mess around dabbling in code just because it has some esoteric appeal. They want their lawyers to use their legal drafting skills. They want their HR professionals thinking about people-friendly processes. They want their procurement teams focused on delivering value.

#2 Workflow

Many organisations who bought the first-generation solutions were surprised to find that the solutions generated a document and then did nothing else. The data used to create a document was mostly discarded or useless. The documents were no less and no more useful than a simple Word file. Everything else happened by email. Have your colleagues reviewed the document? No idea – email them. How many replies are you waiting for? No idea – trawl your sent items folder and see if you’ve had replies. Maybe create a list in a notepad and tick them off as they arrive. Is your document waiting for approval from someone who is on annual leave? You will need workflow. Do you have the budget and bandwidth to buy a workflow solution and integrate it with the document automation tool? Much better to have them in the same tool.

#3 Dashboards

If you deploy an automated solution, you probably have more than a few work items to get processed. After the solution has been running for a while, you will want to manage the workload. You will want visibility of current work. You will want to retrieve information from work processed months ago.

#4 Customisation

It’s better to have one solution that can be used across the whole enterprise, rather than each department buying its own solution. Each department might not care, but each department might not have the autonomy to fly solo on such things. However, each department will have a different requirement and a different view on your organisation’s world. That’s why you need to be able to customise. Customising a solution is more than just adding a logo and being able to select a colour scheme for the screens. True customisation means recognising that each team uses different data, different reports, and different processes. Moreover, they might want to separate one from another. The HR team does not want employee records accessible across the organisation. On the other hand, HR might want to roll out some processes (annual leave requests, new joiner processes) across all teams. This level of customisation requires software designed to be enterprise-wide.

#5 Digital signatures

Many documents need to be signed: contracts, purchase orders, job offers, approvals, audits. If they need to be signed by more than one person, you might need to specify the order in which they get signed. In many situations, you might need to verify that a signature is genuinely applied by the person named. It might not be good enough to copy and paste a GIF image taken from your scanned hand-written signature. Signing documents the old-fashioned way is a nuisance, time consuming and increasingly it makes you look old-fashioned. Since Covid, digital signatures have dramatically increased. In my work as a lawyer, I rarely see documents signed using hand-written ‘counterparts’ scanned and emailed. If a document is to be digitally signed, generate the document in a way that is natively ready for digital signature, and integrate the workflow with a digital signature solution. It’s easier if you can do all this in one tool.

#6 Data mining

Your organisation’s total document store contains valuable data that could provide insight into your business that is available from no other source. Litigators have been looking for ways to scrutinise documents using e-discovery tools. Mercifully, there are more beneficial reasons to look back at your documents to see what you can find. That task is easier if you keep digital records about each document. Inevitably, you might want information in the future that you did not anticipate when the document was first created. The tools to extract useful information from documents and processes are starting to deliver additional value beyond the obvious automation benefits.

#7 Who knows what’s coming?

It’s a trite observation to say solutions are, in general, becoming more sophisticated. You could wait for the next new thing, but there will always be something new coming, and you might never get started. The better strategy is to buy a solution with a history of developing new features, regularly – it’s the most reliable assurance that the solution will not drift out of date.

#1 No code development

I liked writing code using the first generation of document automation solutions. It was satisfying to get it right. But, I was one of those who also liked programming as a kid, and I relished the challenge. If you want your subject experts to build a solution for their teams, you could look around for people who also like messing around with code.

Here’s the problem: not many people fall into that category, and even if they do, not many organisations want to pay their key staff to mess around dabbling in code just because it has some esoteric appeal. They want their lawyers to use their legal drafting skills. They want their HR professionals thinking about people-friendly processes. They want their procurement teams focused on delivering value.

#2 Workflow

Many organisations who bought the first-generation solutions were surprised to find that the solutions generated a document and then did nothing else. The data used to create a document was mostly discarded or useless. The documents were no less and no more useful than a simple Word file. Everything else happened by email. Have your colleagues reviewed the document? No idea – email them. How many replies are you waiting for? No idea – trawl your sent items folder and see if you’ve had replies. Maybe create a list in a notepad and tick them off as they arrive. Is your document waiting for approval from someone who is on annual leave? You will need workflow. Do you have the budget and bandwidth to buy a workflow solution and integrate it with the document automation tool? Much better to have them in the same tool.

#3 Dashboards

If you deploy an automated solution, you probably have more than a few work items to get processed. After the solution has been running for a while, you will want to manage the workload. You will want visibility of current work. You will want to retrieve information from work processed months ago.

#4 Customisation

It’s better to have one solution that can be used across the whole enterprise, rather than each department buying its own solution. Each department might not care, but each department might not have the autonomy to fly solo on such things. However, each department will have a different requirement and a different view on your organisation’s world. That’s why you need to be able to customise. Customising a solution is more than just adding a logo and being able to select a colour scheme for the screens. True customisation means recognising that each team uses different data, different reports, and different processes. Moreover, they might want to separate one from another. The HR team does not want employee records accessible across the organisation. On the other hand, HR might want to roll out some processes (annual leave requests, new joiner processes) across all teams. This level of customisation requires software designed to be enterprise-wide.

#5 Digital signatures

Many documents need to be signed: contracts, purchase orders, job offers, approvals, audits. If they need to be signed by more than one person, you might need to specify the order in which they get signed. In many situations, you might need to verify that a signature is genuinely applied by the person named. It might not be good enough to copy and paste a GIF image taken from your scanned hand-written signature. Signing documents the old-fashioned way is a nuisance, time consuming and increasingly it makes you look old-fashioned. Since Covid, digital signatures have dramatically increased. In my work as a lawyer, I rarely see documents signed using hand-written ‘counterparts’ scanned and emailed. If a document is to be digitally signed, generate the document in a way that is natively ready for digital signature, and integrate the workflow with a digital signature solution. It’s easier if you can do all this in one tool.

#6 Data mining

Your organisation’s total document store contains valuable data that could provide insight into your business that is available from no other source. Litigators have been looking for ways to scrutinise documents using e-discovery tools. Mercifully, there are more beneficial reasons to look back at your documents to see what you can find. That task is easier if you keep digital records about each document. Inevitably, you might want information in the future that you did not anticipate when the document was first created. The tools to extract useful information from documents and processes are starting to deliver additional value beyond the obvious automation benefits.

#7 Who knows what’s coming?

It’s a trite observation to say solutions are, in general, becoming more sophisticated. You could wait for the next new thing, but there will always be something new coming, and you might never get started. The better strategy is to buy a solution with a history of developing new features, regularly – it’s the most reliable assurance that the solution will not drift out of date.

More Industry Insights

Start Automating Now

Digital transformation with documents

Digital transformation with documents

About Charles Drayson

Charles is a UK lawyer who has used document automation for 20 years. He has worked for large law firms, corporate legal teams, and has automated legal and non-legal documents. He writes for Legito to share his passion for using automation to get work done. “I get a kick out of creating good content and seeing it used repeatedly and reliably by colleagues without fuss and bother”.

Digital transformation with documents

About Charles Drayson

Charles is a UK lawyer who has used document automation for 20 years. He has worked for large law firms, corporate legal teams, and has automated legal and non-legal documents. He writes for Legito to share his passion for using automation to get work done. “I get a kick out of creating good content and seeing it used repeatedly and reliably by colleagues without fuss and bother”.

Charles Drayson

Jul 26 · 3 min read

Charles Drayson

Jul 26 · 3 min read

Documents are awkward components of digital transformation.

You store them on digital media but, ultimately, they remain analogue materials for human consumption. Advances in machine learning and artificial intelligence are as yet unable to extract full and reliable data from documents. Hell, you can put the same document in front of several humans and not even yield consistent interpretations of the content.

 

What can we do with those pesky documents in a quest to make things better?

Documents are awkward components of digital transformation.

You store them on digital media but, ultimately, they remain analogue materials for human consumption. Advances in machine learning and artificial intelligence are as yet unable to extract full and reliable data from documents. Hell, you can put the same document in front of several humans and not even yield consistent interpretations of the content.

What can we do with those pesky documents in a quest to make things better?

Abandon documents that we don’t need

If a document exists to present digital data in human-readable form, keep the data and create a transient document on each occasion when it’s needed. Bank statements are a good example. Who needs years of bank statements if we can reconstruct a statement (probably with more insightful data) on demand from a digital record of transactions? The veracity of a digital record is easier to verify – documents are prone to fabrication. Document assembly tools are ideal for this.

Store documents with the data that spawned them

If you must keep a document, and if the document was generated automatically from machine-readable data (just about all high volume documents), make sure you store the data (or a link to it) with the document. Systems can then read the data rather than trying to reverse engineer the document. Insurance policies, mortgage documents, employment contracts, purchase orders – all fall into this category.

If a dispute arises, someone can verify the data tallies with the document on an exceptions basis. You also mitigate the risk of a document presenting ambiguous information – you can look back at the source to resolve discrepancies. It’s helpful to have a document management system that allows such files to be collocated.

Store documents with metadata

If you cannot link a document to machine-readable data that contains the same information, tag the document with clues about what it contains. Typical metadata could include the date of the document, the name of the author, the type of document, maybe a tag to describe a related project. This might be sufficient for most reporting purposes, and reduce the task of searching for specific documents when the occasion arises. Created metadata at the same time as the document – it’s harder to tag documents retrospectively (although some AI systems are good at that).

Limit the use of documents as the sole repository of information

This requires some discipline among the teams of prospective authors. They need to understand that using a document as the medium to record the product of their work could be the least efficient way to apply their efforts.

For example, a real estate agent could feasibly create a very pleasing document describing a client’s house, with photographs, plans and descriptions. How useful is that document for analysis by anything systematic (or to share with marketing agents)? Instead, have a taxonomy for describing houses (number of rooms, dimensions, plot size, etc) and for collating plans and photographs. Compile it digitally, and then use document assembly to render descriptive documents (with the added benefit of having documents that are consistent and meet the organisation branding). Lawyers should create more legal documents this way too.

Impose a screening process before assimilating ad hoc documents into a digital system

If you must have incoming documents that don’t fall into the categories above, you do at least need to safeguard your organisation with a few steps to keep a healthy document store. The exact steps will depend on your industry but think about compliance and safeguarding.

Before you accept a document, you might want to remind users about data protection (you might want to know if documents contain personal data), security classification, password protection (if documents have to be opened by someone without a password), or simply to check if this is the correct system to be storing such documents.

Build a process for the human-in-the-loop

If documents are for human consumption, build an automated business process that has a place for the human-in-the-loop. Don’t try to replicate the nuanced, sensitive, intuitive work that only humans do well. Provide a way for humans to participate and leave their mark. Workflow tools integrated with document automation are what you need.

Abandon documents that we don’t need

If a document exists to present digital data in human-readable form, keep the data and create a transient document on each occasion when it’s needed. Bank statements are a good example. Who needs years of bank statements if we can reconstruct a statement (probably with more insightful data) on demand from a digital record of transactions? The veracity of a digital record is easier to verify – documents are prone to fabrication. Document assembly tools are ideal for this.

Store documents with the data that spawned them

If you must keep a document, and if the document was generated automatically from machine-readable data (just about all high volume documents), make sure you store the data (or a link to it) with the document. Systems can then read the data rather than trying to reverse engineer the document. Insurance policies, mortgage documents, employment contracts, purchase orders – all fall into this category.

If a dispute arises, someone can verify the data tallies with the document on an exceptions basis. You also mitigate the risk of a document presenting ambiguous information – you can look back at the source to resolve discrepancies. It’s helpful to have a document management system that allows such files to be collocated.

Store documents with metadata

If you cannot link a document to machine-readable data that contains the same information, tag the document with clues about what it contains. Typical metadata could include the date of the document, the name of the author, the type of document, maybe a tag to describe a related project. This might be sufficient for most reporting purposes, and reduce the task of searching for specific documents when the occasion arises. Created metadata at the same time as the document – it’s harder to tag documents retrospectively (although some AI systems are good at that).

Limit the use of documents as the sole repository of information

This requires some discipline among the teams of prospective authors. They need to understand that using a document as the medium to record the product of their work could be the least efficient way to apply their efforts.

For example, a real estate agent could feasibly create a very pleasing document describing a client’s house, with photographs, plans and descriptions. How useful is that document for analysis by anything systematic (or to share with marketing agents)? Instead, have a taxonomy for describing houses (number of rooms, dimensions, plot size, etc) and for collating plans and photographs. Compile it digitally, and then use document assembly to render descriptive documents (with the added benefit of having documents that are consistent and meet the organisation branding). Lawyers should create more legal documents this way too.

Impose a screening process before assimilating ad hoc documents into a digital system

If you must have incoming documents that don’t fall into the categories above, you do at least need to safeguard your organisation with a few steps to keep a healthy document store. The exact steps will depend on your industry but think about compliance and safeguarding.

Before you accept a document, you might want to remind users about data protection (you might want to know if documents contain personal data), security classification, password protection (if documents have to be opened by someone without a password), or simply to check if this is the correct system to be storing such documents.

Build a process for the human-in-the-loop

If documents are for human consumption, build an automated business process that has a place for the human-in-the-loop. Don’t try to replicate the nuanced, sensitive, intuitive work that only humans do well. Provide a way for humans to participate and leave their mark. Workflow tools integrated with document automation are what you need.

More Industry Insights

Start Automating Now