Everything AI-related so far sits in the domain of data extraction for contract or, more broadly, document, management rather than production (supposedly the core function of document automation).

You may argue that there is currently no AI in document automation. You are right if you equate AI with deep learning machines based on neural networks.

Deep learning machines work by being trained on samples of data that represent the set of cases that have been accounted for (supervised learning).

You might conceivably take a set of documents generated over the last few years, feed them and the data that was used to generate them – if still available – into a really well designed deep learning machine that was created to understand documents. Then you may get an AI machine capable of producing some kind of document.

There are certain prerequisites: you need to be confident that the documents used for training are accurate, that they cover all business scenarios, and that all such scenarios are represented sufficiently. At the end of the process, you may get a deep learning machine that can produce one type of document with a high likelihood of the output being accurate.

Comparing AI Document Engines based on deep learning and document automation prouducts in terms of accuracy and configuration.

If a high likelihood of accurate output is the desired outcome – and you don’t mind spending big bucks developing the deep learning machine for documents (someone will try building it sooner or later) – then great.

Most organisations attempt to get as close as possible to certainty of document accuracy. For better or worse, even the most basic fit-for-purpose document automation product will give you 100% certainty that your document is produced exactly the way you designed it, given the data you supply.

“Even the most basic fit-for-purpose document automation product will give you 100% certainty that your document is produced exactly the way you designed it.”

Introducing deep learning into document production creates an additional level of uncertainty. Deep learning engines, and the logic they learn or derive, are typically difficult to understand. You may consider building in some hard and fast rules, for sure, but what is the deep learning neural network doing then?

Deep learning is no doubt very valuable in many areas that interface with document generation. Extraction of data from legacy documents, analysing data and triggering actions based on the understanding of data (e.g. fraud detection, or any other exception detection where there is a large enough sample of data to analyse and train on) and many others.

Deep learning aside, if you need document generation done better than humans on their own can do, you should consider document automation as your AI. You will need to spend time capturing knowledge associated with document generation from your organisation, from the brains of humans, and translating it into your document automation product. As a result, you’ll have built your own AI Document Engine combining your document automation product and the knowledge of document creation that your organisation has always had.

Until AI is capable of connecting to human brains directly to extract the knowledge it needs to generate documents (in this instance) or to rule the world (in another), then document automation products will keep providing more effective ways of producing documents.

If you want to know more about building AI document engines based on document automation products, you can check out our white paper where we cover this topic more in-depth.

Martin Srubar

Senior Technology Evangelist

Martin’s engineering background and his passion for great products whether in physical or software form are complemented by his understanding of ActiveDocs applications and how they meet the requirements and fit the architecture of the company’s clients. Martin continues to engage with potential and existing customers, adding market intelligence and customer feedback into the company’s ongoing product development strategy.

Our potential clients’ existing automation knowledge and experience sits on a continuum from “none” to “nearly everything”. Overlay a second continuum of technology on a similar scale, and a third continuum of control ranging from minimal to maxed-out prescriptiveness.

In fact, “overlay” hardly does justice to the structure. Better to represent each continuum as an axis on a 3-D chart, to create a cube with a scatter mapping of processes. Those, taken as a whole, could touch any continuum at multiple points.

Mapping processes to technology, knowledge, and control

There is more: the technology continuum only quantifies. It does not qualify the actual technology, which may be any combination of bespoke solutions created by or for the customer, and third party products ranging from simple MS Word automation to full packages.

Thus, each document process uniquely combines automation, control, and aspects of technology; a tidy summary but over multiple processes it creates a complex overall picture. Where to begin?

Look to core strengths, then “Play to your core strengths”.

Generically meaning anything from common sense to the elixir of happiness, we see it as a pragmatic approach to document automation.

We subscribe also to not biting off more than we can chew, good practical advice that supports playing to strengths, because trying to fix everything at once plays to no-one’s. The best outcomes spring from well-managed proofs of concept and sympathetic pilot projects and rollouts.

To address one specific issue: most organizations we work with are not in the business of software development. It is nowhere near their core strength, yet some will forge ahead and develop software solutions for document automation.

Credit where it is due: we have seen some very good, thoughtfully conceived, well-structured applications. Most occupy the middle ground. Few sit at the other extreme; they tend to drop out of use if they do not work.

The common theme, however, is the difficulty of maintenance and adaptation, to meet not only changing business needs but also the constraints and opportunities of evolving technology. To build and keep such applications, and the expertise they demand, requires the organization to invest significantly in non-core strengths.

We have written more on this subject, from various points of view including adaptation of specific technologies and the pros and cons of build vs. buy. We invite you to read our related whitepapers.

The core strength that your organization can most efficiently leverage is the “gold in the organization”; not only the gold content – as highlighted in the whitepaper “Smarter Content Reuse” by my colleague Martin Srubar – but also the institutional gold, the knowledge of your own processes embodied in the knowledge and expertise of your people.

We, in turn, bring our core strengths to the table: our genuinely fit-for-purpose and cost-effective software and, for even better value for money, our people and our experience. My day job at ActiveDocs is Senior Solution Consultant; I look forward to engaging with you.

Nick Chivers

Senior Solution Consultant

Nick is an IT industry veteran with an eye for detail and a passion for doing things better. He’s been with us for 12 years and along with thought leadership has helped bring ActiveDocs products and services to many of our global customer base.

A number of technological prerequisites need to fall into place for it to happen. The primary being much broader and standardized spread of the IoT, giving blockchain protocols better ability to interact with the outside, non-blockchain, world.

So how does the shift from paper contracts to blockchain smart contracts look?

In the past, a lawyer created a legally binding document largely from scratch, every time such a document was needed.

In the present, creation of both low and high value legally binding documents can be fully automated or at least largely aided through document automation tools. In both instances, the actual execution of the contract is dependent primarily on the good faith of the contracting parties, and secondarily on the applicable jurisdictions and law enforcement.

In the future, working with smart contracts, the dependence on good faith, jurisdictions, and law enforcement will be nearly eliminated. All clauses and conditions will be defined in the code of the smart contract and executed by the blockchain network, interfacing with the real world through the IoT and a network of blockchain oracles.

What does it mean for some of the elements currently associated with the creation of legally binding documents?

How the transition from legally binding documents on paper to smart contracts impacts the elements of their creation

As smart contract technologies mature, the need will arise to make them more accessible to the wider audience of people who will need to understand what they’re agreeing to when they sign a smart contract. When more people want to create smart contracts, tools will be created to make it both easier and without needing blockchain coders.

Organizations currently utilizing document automation solutions will be well-positioned to leverage their deep understanding of the inner logic of their legally binding documents, which has in part been already codified during the document automation process, and will be best-equipped to translate them into smart contracts accurately.

For our part, we are paying close attention to the maturity and capability of blockchain smart contract technologies to enable our clients to take the leap into smart contracts when their time comes.

Martin Srubar

Senior Technology Evangelist

Martin’s engineering background and his passion for great products whether in physical or software form are complemented by his understanding of ActiveDocs applications and how they meet the requirements and fit the architecture of the company’s clients. Martin continues to engage with potential and existing customers, adding market intelligence and customer feedback into the company’s ongoing product development strategy.

The shipping industry deals with a large amount of paperwork – by necessity. Ports, customs, and customers need to track what is being shipped, where it is at the moment, and its estimated delivery. Beyond that, there are all sorts of associated operations, safety, and customs communications. And everything has to be secure.

A tailored blockchain network, such as the one being tried out by Maersk, can give all involved parties a reliable view of the process, contributing to the solution.

This solution is not here yet. Nevertheless, the digitization of the shipping industry can’t be stopped.

It may take some time for the involved parties to accept blockchain as a trusted and internationally recognized system of record. Until then, why not work with what you have? Shipping companies and their clients already have all their data in electronic form. Now it’s just a matter of using it correctly, in a way that will be accepted by authorities – ports, customs, or clients.

Work with what you have

While you can’t simply give a port officer a view into your blockchain network just yet, you can make sure that all documentation is produced automatically, with minimum or no effort.

Ideally, all relevant bills of lading, packing lists, letters of credit, and any other documents simply appear when and where they are needed. They could be triggered by the communication with the port authorities or even the ship’s proximity to a set GPS coordinate.

While it may all seem a little outlandish, it can be a reality for many.

ActiveDocs Opus is a mature document generation platform. It’s used by large organizations to generate business-critical documents, in real time, on a global scale, and with global reach. We give our customers confidence that they can deploy a solution that delivers efficiency quickly and can be plugged into their existing processes.

Getting data from a variety of disparate system, cherry-picking what’s relevant, and transforming it into the right type of document is what ActiveDocs Opus does best. From a technical perspective, this is enabled through our extensive API that can work with a number of ERP and business critical applications, utilizing the ActiveDocs Automated Document Production capability.

Imagine that all 200 of these communications simply take care of themselves.

Martin Srubar

Senior Technology Evangelist

Martin’s engineering background and his passion for great products whether in physical or software form are complemented by his understanding of ActiveDocs applications and how they meet the requirements and fit the architecture of the company’s clients. Martin continues to engage with potential and existing customers, adding market intelligence and customer feedback into the company’s ongoing product development strategy.

Pun or metaphysics? Stuck atop the elephant, can a mind shift get us closer to the ground?

As a Senior Solution Consultant and contributor to sales and services at ActiveDocs for over 12 years, I enjoy a lot of interaction with teams at the coalface of document automation, designing and deploying solutions in which our ActiveDocs suite plays a key role.

In a previous post, I mentioned the principle of not biting off more than one can chew. Experience says that a reliable way to jeopardize a project is to make it too big.

Document automation projects can go big, albeit for the best possible reasons. You have a clear driver to improve specific documents but once you start looking at other documents in that area of the business, there is no end of candidates.

Then, word gets around. Other areas of the business have been tolerating less-than-ideal documents. How can you turn them down? You know ActiveDocs can help you achieve great things. You will have teams in place, and while they are current and focused, they will do great things.

So stand up. Be a hero. Fix everything. Be proactive. Show some initiative and add some business process re-engineering before someone else does.

Well, there goes the scope and there is your elephant. Time to find a way down.

Proofs of concept, pilot projects, staged rollouts. These proven strategies empower change without exceeding the capacity of the business to absorb it, and allow project teams to be agile and adaptive. Set up for success and plan big or small projects without big bangs.

Our training syllabus covers how to identify candidate document types, determine their automation needs, and deploy the appropriate features of our product. We also emphasize product features that avoid the where-do-we-start syndrome.

For example, if you are already using Word templates – with macros or just markup – you could load these as-is into ActiveDocs and use it to serve them to the business. This improves business processes immediately by providing centralized management and maintenance, and by ensuring everyone gets the latest versions. Then, proceed with the automation via a stepwise and prioritized schedule.

ActiveDocs allows you to add and adapt automation without figuring it all out in advance. The concept is simple enough and the benefits are obvious, yet who else gets it? We never stop listening to our customers and our own service teams and these are the lessons they teach us.

Make it easy to share elements like common content, business rules, and access to data. At the same time, recognize that projects may not start with all of those in place, that those in place will change, and that new candidates will show up further down the track. Allow for rolling improvements and just make it easier to adjust and retrofit shared standards as they evolve.

There is a lot more to show and tell. We look forward to engaging with you and discussing how we can help you get down off your elephant.

Nick Chivers

Senior Solution Consultant

Nick is an IT industry veteran with an eye for detail and a passion for doing things better. He’s been with us for 12 years and along with thought leadership has helped bring ActiveDocs products and services to many of our global customer base.

CCM positions itself as helping organizations to communicate with their clients.

It typically does this by packaging some core software functions: communication generation, workflow, and marketing tools. What this means in practice is that you can send an email to a client, track their response action, and follow up if you need to.

CCM vendors often set out ambitious goals and outcomes, like helping organizations to increase revenue, drive engagement, and deliver exceptional customer experience.

In today’s software technology landscape, organizations ask for software products that meet all their needs, putting pressure on software vendors to broaden capabilities of their products either through development or acquisitions. The result is split focus and overlapping functionality across products in neighboring areas.

It is common that an organization owns several products with highly overlapping functionality. For example, take a look at Gartner’s Predicts 2019: Technological Convergence of Content Services analysis of the Content Services space:

Applicability of use-cases of various software in the Content Services area. © 2019 Gartner, Inc.

One of Gartner’s key findings from above states:

“Capabilities that are replicated in multiple products just to fill gaps in overall content strategy will lead to waste and overspending.”

ActiveDocs is a document generation engine. We provide a product that focuses on generation of high value documents and communications. The CIO of a large client, a multi-billion, Fortune 100 Company, told us:

“Considering what we’ve learned, we wish ActiveDocs could be the document engine of our CCM software!”

That testimonial was unsolicited. It arose directly from our client’s experience of ActiveDocs’ document generation capability, and its ease of use by business users.

ActiveDocs and CCM

So how does ActiveDocs sit in relation to CCM? Another client, interested in replacing their outdated CCM solution, labelled the area where ActiveDocs meets their needs as CCG – Customer Communication Generation. They created a picture like this to make their point:

ActiveDocs Document Engine in relation to CCM

ActiveDocs’ focus on document generation, together with ease of maintenance by business users – freeing the organization’s IT department from routine operation of the software – is unseen in the world of CCM.

Organizations that emulate their competitors’ use of CCM packages gain little or no technological edge and, in turn, miss opportunities for ongoing competitive advantage.

Why?

A solution that eschews packages, and instead integrates best-of-breed products for document generation, workflow, and marketing, is inherently more flexible and more readily tailored to the organization’s needs.

A well-architected solution also allows swapping-out of component products without high-risk all-or-nothing updates. You can maintain competitive advantage by adapting to internal and external change. You are taking advantage of new technology, new applications, and new features in individual applications, and at the same time you are avoiding single-vendor lock-in.

As part of a combination CCM solution, a best-of-breed document engine like ActiveDocs also offers a “universal document vending machine”. This works for areas of the business like HR, Purchasing, or Finance, that would never use CCM – let alone be able to leverage the inaccessible document generation capability of a monolithic CCM.

It becomes an enablement platform for their document and communication generation, and business users can do the work themselves.

Wise organizations will select best of breed products that fit their strategy, and build an organization-wide technology capability that gives them competitive advantage that is hard or impossible to replicate by others.

Is this going against the hype of all-in-one, no-worry, can-do-it-all solutions?

Yes, absolutely.

Industry landscapes were never changed, and market shares rarely won, by those who just go with the flow.

Martin Srubar

Senior Technology Evangelist

Martin’s engineering background and his passion for great products whether in physical or software form are complemented by his understanding of ActiveDocs applications and how they meet the requirements and fit the architecture of the company’s clients. Martin continues to engage with potential and existing customers, adding market intelligence and customer feedback into the company’s ongoing product development strategy.

For instance – a digital e-signature, Case Management, HR, Banking or Insurance application, or possibly a consulting company wants to become our “partner” in a specific field.

In reality what all these companies are looking for is another route to market for their products. In fact, this “partnership” is rarely in the client’s best interests.

A lot of clients we speak to already have these types of applications within their business, sourced after extensive analysis. In many cases, they have built bespoke applications or Line of Business (LoB) applications to fulfil their specific requirements.

What in every case these clients lack is the core document engine that powers the final solution. That is when they come to us.

I believe that being agnostic about who we work with, from an integration perspective and from a third party application perspective, is what sets us apart.

ActiveDocs has never recommended any third party application or company, and we never will. Rather, we believe that our clients should determine their own “best in breed” product that will fulfil their needs best. Our strength is our API’s ability to integrate deeply with whomever and whatever they decide.

A complete solution offered by large companies who have over the years acquired multiple applications, or built partnerships to offer a client a “one stop shop”, is appropriate for some.

However, I know based on my experience that in many cases the underlying codebases of these disparate applications are quite different. Once you look under the hood of the cute “wrapper” that binds them together, you find something ugly and less than optimum.

Mostly by that time you have purchased the product, and you have to live with the consequences.

Interlinkage

Another important area to note is the issue of “interlinkage”. This is where a company has already built modules into its core application to ensure tight integration with its partner’s application. This can, of course, be beneficial – but it can also be restrictive. It can create issues if you wish to disconnect or change out one application due to suitability.

Many of ActiveDocs’ clients prefer our approach. Not only does it provide flexibility and the ability to change out any third party application elements, it works for our application as well.

This fact ensures we maintain our core application and strive to continually evolve and improve its capabilities. Otherwise, we could and should be replaced.

We try to provide clarity to our clients on what we do. We are a Document Engine, and have been building it for over 20 years. We own all the core code and IP that makes up the engine. We like to state that “it does what is says on the box” which is why we always insist on undertaking a Proof of Concept. This way, we ensure our clients know the application is fit for purpose.

This single-minded focus on our application without the complications of trying to position another third party’s application is why we believe remaining agnostic is in our clients’ best interests.

Glenn Ricketts

CEO

Glenn has over 40 years of experience in the IT sector, and has been with ActiveDocs for 15 years. He has a strong international sales, marketing, and management background.

To help position the relevance of the question above, perhaps let’s start with a short explanation of the genesis of Document Automation (also called Document Generation).

Most people think that current Document Automation applications started with the legal profession, where in the late 90s lawyers’ secretaries used templates to create basic legal documents.

In fact, for the true genesis you need to go further back – to the early 70s in the Silicon Valley, and the Xerox PARC research facility in Palo Alto. Here were the true beginnings of Document Automation.

Xerox PARC in 1996. Credit: Xerox

In those days, speed and efficiency were the rationale. It used to take insurance underwriting assistants perhaps an hour or two to manually assemble an insurance policy with endorsements. They used a filing cabinet with coded paper endorsements inside.

Xerox PARC designed software to drive their large printers, principally for the insurance and banking markets. Using the new “collating” software, a printer could produce and staple the same policy in minutes. It saved companies hours by replacing manual effors with machines.

This technology endures today under the guise of Customer Communication Management applications. Many of these are amalgams of disparate applications acquired over time, and made to look pretty with a nice front end.

CCM’s genesis from this era means that these applications are very capable feature and function-wise; however, they are still mostly reliant on IT developers to “code” the templates. This dependence makes changes both time-consuming and slow to implement, depending on the availability of valuable IT development resources.

This creates a “time to market” challenge for agile corporations, where speed is of the essence in a changing and competitive marketplace.

The cry of most, if not all, Document Automation vendors is still based on speed and efficiency, as well as the resultant return on investment (ROI).

A simple calculation based on FTEs (Full Time Equivalent) ability to become more productive, and therefore reduce costs, is used to justify the implementation of this technology. Employees can be far more productive by using automation in their daily tasks.

While this is important, especially when producing a business case for the CFO, the reality of why automation applications are gaining traction is something far more important to clients.

With the world becoming more regulated, ensuring accuracy and compliance of whatever information you are providing to your clients is of paramount importance.

This was confirmed to me by the CIO of a large US insurer during a meeting in 2010.

I was sure that the improved efficiency gained from using our application was of significant benefit to her company. She agreed – but stated that this was not the primary reason they chose ActiveDocs.

For her it was ensuring that the documents sent out were correct, and the fact that because we enforced rules and logic, we removed human error. Any flaw in the policy document could result in millions of dollars of liabilities or fines. Our application meant they could be confident that all their policies were correct.

In the last nine years, regulatory compliance has gained worldwide traction. It started with the Sarbanes-Oxley Act of 2002, and grew in significance following the GFC worldwide. It is now the primary reason why clients choose to deploy Document Automation applications.

Regardless of market segmentation, the issue of compliance is applicable to every business.

The use of automated document production (ADP – or more commonly, application to application publishing) removes human error, and provides the ability to update a regulatory change across thousands of templates instantly. It makes businesses more agile and adaptable to the constantly changing regulatory landscape which defines the world we currently live in.

Today, corporations can face significant fines for non-compliance, not to mention that Senior Executives can, in some cases, be imprisoned if found to be knowingly negligent. This makes compliance a far more significant driver for change than efficiency.

Compliance is the nightmare that applications like ActiveDocs help solve for the CEOs, CFOs, CIOs, CTOs, or CCOs in large multinational companies.

Glenn Ricketts

CEO

Glenn has over 40 years of experience in the IT sector, and has been with ActiveDocs for 15 years. He has a strong international sales, marketing, and management background.

Somewhere in your business, a new or existing document-generating process needs attention. New processes may be candidates for automation. Existing manual processes may be candidates for automation. Existing automated processes may be candidates for new technology.

The rationale for giving attention to such processes is that they, and/or the documents they generate, are of sufficient value to the business to justify the attention.

The value proposition may be positive – contracts, agreements, sales proposals, employment contracts, and other documents that bring benefits to the business – or it may indeed be negative – resources better used elsewhere, or documents that simply carry too much risk for the bottom line or the business itself if they are not right.

It should come as no surprise that many documents and processes fall in both camps, but that only enhances the rationale.

The rationale drives the objectives: better document processes and better documents. The project gets the nod. The outcomes will depend on what happens next.

Document generation relies on institutional knowledge which is in turn built on institutional logic.

The logic derives from how the business must work, and is predictable. Sales proposals follow leads. Invoices follow sales. Offer letters follow candidate selections. Reports follow evaluations. But what is the knowledge?

Institutional knowledge speaks to the details: what is the source of the customer / employee / product / service data that populates a given document? How does content change from one customer / business area / sales type / job offer, to the next? What allowance applies to adjustment of standard pricing or other attributes? What aspect of a document determines whether or not it needs approval? Email or print for this customer? Which logo / page header / style applies to which business area?

Without automation, the knowledge may well be codified already into manual processes as written procedures, detailed instructions embedded in the text of documents, hand-me-down know-how, or even ‘everyone knows that’.

Knowledge codified this way is not easily updated and not guaranteed to be current, reliable, or even persistently applied.

When a document is automated, the institutional logic and knowledge is formally codified into an automated process.

This may happen within the templates that generate the documents, within the processes that deploy the templates, and anywhere else in the process.

Retained in this way, the codified knowledge can be easily updated, and is always current, reliable, and consistently applied.

The effectiveness of automation, and therefore the outcome for any automation project, relies on the capabilities of the people – and the tools – involved.

You bring your people to the project for their institutional knowledge. Subject matter experts, business analysts, and database and app specialists; together they know their business and how its documents fit with it. They know or can identify the prime candidates for the automation process. They can define in detail the content, business rules and information sources that will elevate templates and processes from mundane to cutting-edge drivers of quality and competitiveness. They can develop and execute proper testing plans to ensure fitness for purpose.

The toolset will largely determine whether or not the people and their skills, and therefore the project, are effective. On this topic, we’re less interested in what’s used for project management and communication. We are interested in the tools used for the core automation activities, and specifically in a couple of key characteristics of these tools: features, and usability.

Features are a large part of what drives purchasing of products and services. To pick one example – which we will explore in more detail in a future discussion – consider the feature that underpins most of the functionality and features: the markers used to embed automation in templates.

ActiveDocs tools – our products – are built on the use of sophisticated markers that facilitate and maximize all of the capabilities outlined above, running end-to-end, from template design through to document workflow and delivery. Yes, they matter; simplistic markers make for simplistic feature sets.

A tool’s usability – or lack of it – can stop a project in its tracks. If the tool’s interface is difficult to use, if it doesn’t allow you to identify dependencies or help you to avoid breaking them, if every change to a data source means revisiting all of your templates, if every new or changed data item requires a new or changed bookmark in the documents and then you must link that on another form to a placeholder field… your team might just spend more energy fighting the tool than improving the business.

Our products are built for enterprise-grade deployment. We are dedicated to their development and we build on our industry awareness, our own experience and the experiences of our global multi-vertical customer base to inform that development.

Given this deep and wide investment we are confident that our products can meet your challenges and we are unashamedly focussed on our products being part of enterprise projects for large organizations.

ActiveDocs brings its services expertise to the project, indirectly by training your people, from template designers to administrators, and directly by providing both kick-start and long-term template design services and other consultancy when we are needed. As with our product development we invest in great people as well, and as with our product development we are completely confident that our people and your people can do great things.

Nick Chivers

Senior Solution Consultant

Nick is an IT industry veteran with an eye for detail and a passion for doing things better. He’s been with us for 12 years and along with thought leadership has helped bring ActiveDocs products and services to many of our global customer base.

At face value this is way less fun than watching paint dry, but it matters and we should understand it because it underpins most features and functionality of document automation tools.

Document automation originated in the legal space, inspired by its use of ‘bracket and text’ notation. Without going into too much detail, this is human-readable ‘markup’ on a document template to indicate where to put variable information like names and dates, using start-and-end notations, textual instructions, and maybe colors for differentiation.

[First Name Here] [Last Name Here] agrees that…

It might also indicate where rules must be applied, to include or exclude a piece of content, based on something we know about the context of the document.

[IF the Party is a Private Individual] Transactions by private individuals… [ELSE] Commercial transactions are regulated under the… [END IF]

This looks good and clear for human users. Template Authors might settle on a small vocabulary for markup, but if some of it gets a bit idiosyncratic, the user will probably still understand it.

Unfortunately for everyone, it doesn’t take much to turn human-readable into not-readable as we move beyond very simple documents.

Need rules around variable placeholders? Rules with multiple conditions? Rules around other rules? Maybe multiple instances of information? It gets harder to create and harder to decipher.

[IF the Party is NOT a Private Individual] [Trading Name Here] [END IF]

[IF the Party is a Private Individual AND [the Transaction Value exceeds $100,000 OR [the Transaction Value exceeds $50,000 AND the Party is using Short Term Finance]] AND the transaction occurs within the current Tax Year] Transactions of this class in the current Tax Year are generally excluded from… [END]

[IF the Party is a Private Individual][IF the Transaction Value exceeds $100,000 OR [the Transaction Value exceeds $50,000 AND the Party is using Short Term Finance]][IF the transaction occurs within the current Tax Year] Transactions of this class in the current Tax Year are generally excluded from…[END][END]END]

The responding [IF single Responding Party] party [ELSE] parties [END] being [First Responding Party First Name] [First Responding Party Last Name] [IF multiple Responding Parties] and [Second Responding Party First Name] [Second Responding Party Last Name] [IF more than 2 Responding Parties] and [Third Responding Party First Name] [Third Responding Party Last Name] [END] [IF more than…] … [END] [END]

Template Authors will work exponentially harder for longer to maintain the markup. Users will work exponentially longer and harder to figure out what they need to do.

Presentation becomes an issue and there are surprisingly limited options for font colors that are both readable and different enough from each other.

Mistakes – easily made by authors and users alike – make a lot of extra work, might lose a lot of money, and can attract bad publicity. Or a law suit. Or criminal proceedings.

Given what we’ve seen so far, the bracket-and-text style markup is easily broken, hard to standardize, and difficult to present, so we are naturally bemused by its continuing use in tools for critical document automation. The real problem however, is its lack of support for real software-driven automation (which was the whole point).

You can’t layer an automated question-and-answer wizard over bracket-and-text style markup. You can’t link to data sources. You can’t add validation on the answers, to ensure dollar values are actual dollar values, dates are real dates, names aren’t left blank and do actually match what’s on your client list. You can’t facilitate good maintenance with reliable cross-referencing or drill-down through nested rules and placeholders. You can’t have reusable libraries of placeholders and rules and content.

It may seem like a trivial point to make but in reality marker technology underpins and is the primary determinant of most of the functionality of document automation tools. Reuse, common definitions, consistency, validation, data linking, recognition, searching, robustness, and plain old usability are only maximized with the most sophisticated markers.

We acknowledge that there are document automation products with template design tools layered over bracket-and-text style markup and with other automation features layered on top. We also know that there are document automation tools that eschew the old markup style but still don’t leverage the advantages of better markers.

ActiveDocs tools – our products – are built from the ground up on the use of sophisticated markers that facilitate and maximize all of the capabilities outlined above, running end-to-end from template design through to document workflow and delivery.

Yes, markers matter.

Nick Chivers

Senior Solution Consultant

Nick is an IT industry veteran with an eye for detail and a passion for doing things better. He’s been with us for 12 years and along with thought leadership has helped bring ActiveDocs products and services to many of our global customer base.