Charles Drayson

Oct 21 · 5 min read

Here’s a situation you might recognise: an organisation sells a range of services that need different contract terms. Customers might buy more than one service. How do you create a contract which contains all the necessary clauses in one document but none of the irrelevant ones? That was my first task for document automation, and it seemed like a good project. I had a trial version of the software, and I started drafting.

We had thousands of customers served by a sales team of more than fifty people. We had a Word document for each service, so customers had to sign multiple documents. Sometimes, the salesperson would use the wrong documents. Sometimes, the documents did not even look like they came from the same company. It was a mess, and we needed to do it better. It would take a long time to get to signature. Often, the services went live before we finished sorting out the contract terms – which is never a good idea.

I built a template that allowed a salesperson to select the services from a menu. I used the answer to control the clauses in the contract.

I demonstrated version #1. That’s when the trouble started. The sales team complained they couldn’t select the services they needed. I discovered sales teams used different names for the services, depending on which salesperson you asked. How could we have so many customers without a consistent name for the services? I talked to the Finance team. They created invoices, so they must know the range of services to list them on invoices. They told me that the Finance system used codes (not names) for each service, and the Finance team had to interpret what each salesperson intended when a new customer contract arrived for billing. It was educated guesswork.

The contracts included an Order section, where we stated the services and the fees. Before automation, contracts occasionally omitted some fees altogether because they were forgotten or misunderstood. Document automation created an opportunity to make sure the menu of services also forced the relevant fees to be included in the contract. The Finance team told me which fees were supposed to be collected. However, the sales teams had been giving proposals to customers for fees that did not align with the services. Unsurprisingly, people got grumpy when the contract tool started to generate fees that were not the same as those in the sales proposals.

“Generating a contract with document automation became a chance to identify errors before we put them in front of customers.”

Why am I telling you all this? It took me a few weeks to learn how to use the document automation software and create the first versions of contract templates. It took me much longer to develop the templates to a stage where everybody (Sales, Finance, customers) could agree that the templates created ‘correct’ contracts. It wasn’t a legal problem. It wasn’t a technology problem. We were trying to automate a business process that was not consistent or reliable. We were automating rules that were not uniformly applied or recognised. Deploying automation forced us to recognise the problems.

I was expecting to use document automation to reduce the cycle time to get customer contracts signed. That was the return on investment.

What we achieved was something altogether different and unexpected. We stopped losing revenue from missing fees accidentally omitted from contracts. We ensured the sales team, the finance team, the operations team and the customers all had the same understanding about what we would deliver and invoice. We stopped annoying customers with incorrect invoices and credit notes. We forced our internal teams to agree how things should be done. Generating a contract with document automation became a chance to identify errors before we put them in front of customers.

Since then, working with different organisations, I have lost count of the business or operational problems that we discovered and fixed because document automation forced us to look more closely at what we were doing. Those problems were never part of our return on investment calculation because we didn’t know they existed. It’s a welcome bonus when we fix them. Automation can be like that.

Here’s a situation you might recognise: an organisation sells a range of services that need different contract terms. Customers might buy more than one service. How do you create a contract which contains all the necessary clauses in one document but none of the irrelevant ones? That was my first task for document automation, and it seemed like a good project. I had a trial version of the software, and I started drafting.

We had thousands of customers served by a sales team of more than fifty people. We had a Word document for each service, so customers had to sign multiple documents. Sometimes, the salesperson would use the wrong documents. Sometimes, the documents did not even look like they came from the same company. It was a mess, and we needed to do it better. It would take a long time to get to signature. Often, the services went live before we finished sorting out the contract terms – which is never a good idea.

I built a template that allowed a salesperson to select the services from a menu. I used the answer to control the clauses in the contract.

I demonstrated version #1. That’s when the trouble started. The sales team complained they couldn’t select the services they needed. I discovered sales teams used different names for the services, depending on which salesperson you asked. How could we have so many customers without a consistent name for the services? I talked to the Finance team. They created invoices, so they must know the range of services to list them on invoices. They told me that the Finance system used codes (not names) for each service, and the Finance team had to interpret what each salesperson intended when a new customer contract arrived for billing. It was educated guesswork.

The contracts included an Order section, where we stated the services and the fees. Before automation, contracts occasionally omitted some fees altogether because they were forgotten or misunderstood. Document automation created an opportunity to make sure the menu of services also forced the relevant fees to be included in the contract. The Finance team told me which fees were supposed to be collected. However, the sales teams had been giving proposals to customers for fees that did not align with the services. Unsurprisingly, people got grumpy when the contract tool started to generate fees that were not the same as those in the sales proposals.

“Generating a contract with document automation became a chance to identify errors before we put them in front of customers.”

Why am I telling you all this? It took me a few weeks to learn how to use the document automation software and create the first versions of contract templates. It took me much longer to develop the templates to a stage where everybody (Sales, Finance, customers) could agree that the templates created ‘correct’ contracts. It wasn’t a legal problem. It wasn’t a technology problem. We were trying to automate a business process that was not consistent or reliable. We were automating rules that were not uniformly applied or recognised. Deploying automation forced us to recognise the problems.

I was expecting to use document automation to reduce the cycle time to get customer contracts signed. That was the return on investment. What we achieved was something altogether different and unexpected. We stopped losing revenue from missing fees accidentally omitted from contracts. We ensured the sales team, the finance team, the operations team and the customers all had the same understanding about what we would deliver and invoice. We stopped annoying customers with incorrect invoices and credit notes. We forced our internal teams to agree how things should be done. Generating a contract with document automation became a chance to identify errors before we put them in front of customers.

Since then, working with different organisations, I have lost count of the business or operational problems that we discovered and fixed because document automation forced us to look more closely at what we were doing. Those problems were never part of our return on investment calculation because we didn’t know they existed. It’s a welcome bonus when we fix them. Automation can be like that.

More Industry Insights