The History of Contract Lifecycle Management

The history of contract lifecycle management (CLM) software begins with a clay tablet.

That tablet is the first known business record, which was etched on a cuneiform tablet 5,000 years ago.

Understanding the importance of that ancient tablet is important to understanding the history of CLM (which has mostly taken place over the last thirty years) because ledgers and contract management remain as important to businesses now as they were then. Every business runs on a ledger, and every ledger is built on contracts.

For commerce to exist, you need a record of every purchase and every purchase fulfilled. Without contracts, there can be no guarantee of payment or fulfillment. In other words, ledgers and contracts are the foundational elements not just of every business, but of human cooperation and society. But recording the details of an agreement, as any businessperson will tell you, is the easiest part of any contract negotiation. It’s coming to an agreement that’s complicated.

To understand the history of CLM, you need to understand that managing signed documents is the least complicated part of managing contracts and contracting processes. 

For the past thirty years, contracting and CLM tools have sought to bring the analogue process of contracting into the digital age. Unfortunately, the challenge of contracts has proven too complex for these tools, largely because they have failed to take into account how lawyers and companies actually assemble, negotiate, and finalize contracts.

Legacy CLM solutions have not only failed to digitize the contracting process, they have introduced a separation between companies’ contracts (which are usually DOCX or PDF files) and the information within them (e.g., a contract’s value or duration).

This separation is a business liability. If your (analogue) contracts say one thing, and your databases say another, courts will likely side with your contracts.

Here, we’ll explain why the broken promises of CLM have set business and legal teams back, and why new technologies can finally change the way teams draft, edit, track, and store contracts.

In Adam Fisher’s Valley of Genius, there’s an interview with Charles Simonyi, an early Microsoft employee and the creator of Microsoft Word, in which he explains that he left Xerox PARC to join Microsoft in 1981 because he thought the company was poised to change the way all businesses operated.

It was an ambitious goal, but it still sells Simonyi’s accomplishments short. Although the word processor that he and Microsoft created wasn’t the first, it has endured the longest. Today, most contracts in the world pass through Microsoft Word at some point. (WordPerfect still has its place at some law firms, but that’s a more involved discussion best saved for another time.)

The proof of Microsoft Word’s ubiquity is how difficult it is to imagine a world before the software existed. Unlike Atari and Xerox, both of which are profiled in the book’s early chapters alongside Microsoft and seem like relics of another era, Word gives one the impression of standing outside of time, as if every document ever created has been a Word document, even if Word is not yet 40 years old.

There is an inevitability to Microsoft Word that makes it difficult to imagine the software ever being replaced. One might as well try to imagine a world without laptops, or without email.

On the other hand, the history of business tools — and of business software, in particular — makes it clear that rapid obsolescence is the norm, even when it comes to tools for managing vital business processes.

For business and legal leaders that want to give their companies a competitive advantage, the key is to understand which tools are likely to stick around, and which tools need to be upgraded ASAP. Switch tools too soon, and the business is likely to experience unnecessary friction. Switch tools too late, and competitors may gain the upper hand.

Keeping track of changes across all of them may seem daunting, since today’s enterprises tend to run on, at minimum, dozens of critical software applications (and, according to the Wall Street Journal, sometimes hundreds), whether it is software for managing sales, procurement, HR, or other key functions.

The good news is that understanding CLM is a shortcut to understanding enterprise business technology, as almost every business process touches a contract at some point.

But if contracts and CLM are so important, why is business software today dominated by two other categories of software: customer relationship management (CRM) and enterprise resource planning (ERP)?

The answer, in a word, is timing.

In 1999, the fastest-growing public company in the United States was Siebel Systems, a customer relationship management (CRM) technology company. Siebel’s software helped large companies manage their sales prospects — a universal business need — and the company commanded nearly half of the CRM market. Founded in 1993, the company went public in 1996 and saw its stock price grow by 1,200% in the next three years. When Fortune profiled Siebel in its 100 Fastest-Growing Companies issue, it put a picture of a wheelbarrow overflowing with money on the cover (an apt if unintentional analogy for the dot-com crash, which would hit six months later.)

Coincidentally, it was in 1999, the year of Siebel’s zenith, that Marc Benioff founded Salesforce in a one-bedroom apartment in San Francisco’s Telegraph Hill.

Today, Salesforce is worth $240 billion and accounts for roughly one fifth of the CRM market. Meanwhile, MBA students study Siebel as a cautionary tale, not as a playbook for software growth.

The CRM market grew rapidly in the 1990s and 2000s because the core technological requirements for tracking prospect and customer information are simple, and because sales interactions differ from contracts in three key ways:

1. Sales interactions are routine. Unlike tracking contracts, which can vary greatly in scope, complexity, and risk, tracking most sales interactions is simply about keeping track of the status of the deal.
2. Sales interactions only need to be recorded by the seller. CRM could grow rapidly even before the widespread use of the internet, as only the seller needed to record the details of each interaction.
3. Sales interactions are easy to record and understand without special training. CRM differs from CLM in that the key moments of a sales interaction do not require special training to understand, while the key clauses in a contract do require a legal background to understand.

But the rises and falls in the CRM market also point to a broader rule: No lead is safe in business technology, and the future of most software categories seldom looks anything like the past.

Every business runs on contracts. Contracts dictate terms of employment, business relationships, and countless other critical business details. Simply put, contracts are the atomic unit of commerce, the building blocks of every economic activity and business process.

Follow a contract through a company, and you’ll know everything you need to about that company’s approach to technology, process optimization, and risk management.

Does a company prioritize speed over security? Does it maintain a number of systems that don’t communicate with each other? Does it save money by automating high-volume processes?

Perhaps it’s the ubiquity and variety of contracts that makes them a technological challenge, since contract management is the Gordian knot of business software. Technology providers have approached the problem from every conceivable angle — largely unsuccessfully.

Some companies focus on a specific contract stage or function, such as document generation, while others focus on a specific type of contract. Still others have entered the contract management from adjacent legal domains, such as matter or spend management.

Today, there are at least 150 contract management software providers, but not one solution that helps modern companies streamline every step of the contracting process.

Managing contracts, it turns out, presents more technological, operational, and legal hurdles than any other business task. Software has consistently failed to meet the challenge of contracts. In the past, this was because of technological limitations. Today, it’s because of the burdens of legacy software.

To understand how CLM has evolved over time, it’s useful to reference a broad investment framework on enterprise software: Greylock’s concept of systems of record, systems of engagement, and systems of intelligence. Our use of the framework won’t match Greylock’s, exactly, but the concepts will be the same.

The thesis, in a nutshell, is that every major business system first provides value as a source of truth (e.g., as a database). The difference between a paper-based business and a digital business is that the digital business can access, query, and distribute records in seconds, whereas the same tasks would take hours, if not days, with paper files.

At a certain point, however, it’s not enough to just have a database. Companies and industries look to systems of engagement to further streamline common operations. These systems sit between databases and end users, and they help automate and streamline the collection and retrieval of data, whether that data is information on prospects or information on contracts. This is where most technologies — regardless of industry or use case — stand today.

The future of software lies in systems of intelligence, or systems that don’t just record and retrieve data, but also analyze it to detect patterns, surface insights, and improve business outcomes. The track record of these types of systems is mixed and depends in large part on the domain in which they’re applied.

One way to better understand this framework is by applying it to systems for personal finance:

1. System of Record. Your bank’s database is a system of record, or the source of truth about your finances. This is the oldest and most developed of the systems, and is unlikely to change significantly in the future.
2. System of Engagement. The banking app on your smartphone is a system of engagement. It helps you view your records from anywhere, as well as conduct routine tasks like transferring funds between accounts. These systems, while relatively new, have seen widespread adoption.
3. System of Intelligence. Early versions of a system of intelligence for your finance might be apps that provide guidance on how to spend your money, or that predict what your retirement needs may be. If you’ve interacted with these systems, however, you know that they’re still far from perfect. As such, they can supplement, but not replace, human inputs.

How do these systems look when applied to contracts?

Beginning in the 1990s and continuing into the 2000s, the cost of business computers fell dramatically, the Internet gained widespread adoption, and e-mail became the de facto standard for business communication. Just as importantly, in 2000, Congress passed the ESIGN act, a law that ensured the validity of contracts signed electronically.

Together these changes revolutionized a number of business processes, none more so than contracts.

Throughout the 1990s and 2000s, most contract management systems were actually document management systems, or systems of record. As companies began to digitize their contracts and their contract records, their main priority was to make sure that their contract databases were accurate and comprehensive.

Because software tended to be hosted on-premise during this time, customers expected to spend months, if not years, implementing and configuring enterprise software systems, and they did not expect frequent software upgrades. The leading vendors for contract systems of record through the 2000s were, for example, Oracle and SAP Ariba, both of which were founded in the mid-1990s. The contract management systems of this time were glorified databases. They were where contracts went to die. Sure, businesses purchased contract management software, but few companies saw this software as a competitive necessity.

By contrast, the CRM market saw explosive growth in the 1990s.

Why? Because lead or prospect management—unlike contract management—didn’t depend on digitizing documents or signatures. It didn’t require that your customer use email or sign a document electronically. It was a one-sided system, rather than a transactional or two-party system: all it required was that your salesperson enter prospect details and interactions into your systems.

That’s why, in the 1990s and through the 2000s, companies could rely on CRM in a way that they could never rely on contract management tools or CLM—the information in the CRM was generally accurate and up-to-date, while information couldn’t even be entered into contract systems until contracts were finalized by both sides and signed. The same was true of Enterprise Resource Planning (ERP) systems, which were (and are) the systems Procurement teams use to keep track of purchases.

In other words, key parts of the contract process could not live in contract management tools, while CRMs and ERPs didn’t face the same barriers.

As a result, CRMs and ERPs flourished while contract management software saw modest growth in these decades.

In the 2010s, Software-as-a-Service (SaaS) became the norm. In this model of software delivery, companies purchased subscriptions to software rather than perpetual licenses. In return, they could expect continuous product development and product support.

Perhaps no technology company benefited from this change as much as Salesforce, which climbed the Fortune 500 and saw its annual revenue grow to $17 billion.

Over the same time period, two types of new contract management tools emerged — both of them early types of systems of engagement.

These weren’t the document management tools of the 1990s and 2000s. They monitored contracts in-flight, and they integrated with other tools like cloud storage solutions and eSignature tools. During this decade, “contract lifecycle management” became the new category of contract management because it referred to tools that handled document generation, processing, and archival — capabilities that had previously been handled by disparate tools.

Because CRM and ERP were already ubiquitous, CLM tools often went to market by targeting segments of CRM and ERP customers. For example, some CLMs targeted exclusively Salesforce customers, since they knew that Salesforce customers were already tracking prospect information in a CRM, and that this information could be fed into contracts. Moreover, CLM vendors knew that they could tap into a large market by building and selling their product through Salesforce’s AppExchange.

In the 2010s, the two broad types of contract management tools were:

1. Custom enterprise contract management tools. These tools were highly customized and aimed at large companies. It could take months, if not years, to deploy them, but they took Siebel’s approach to bespoke configuration and implementation, knowing that their customers would commit to using their solution for years afterwards. New CLM vendors like Apttus (founded 2006) and Icertis (2009) adopted a cloud-forward approach and adopted a go-to-market (GTM) approach that emphasized configurability and scalability. Notably, many of these companies, including Apttus, indexed heavily on going to market as a Salesforce complementer, rather than as a standalone solution.
2. Modular “point solutions,” or contract tools that specialized in one stage of contract management. As the cost of software development declined, a number of startups decided to enter the contract management space by focusing on one stage of contracts (e.g., document creation, signature, or storage). Unlike the comprehensive enterprise solutions, these tools could be deployed relatively quickly and inexpensively. However, there was no guarantee they would work with each other, and it was difficult to know which solutions would be best-in-class in the long-term. We’re still grappling with the effects of this rapid unbundling today.

These solutions left companies with two options: invest in a large, highly customized tool (and risk losing hundreds of thousands of dollars, if the implementation was unsuccessful), or invest in a suite of smaller solutions (and risk creating data and process silos across the company).

There was one more issue: every vendor in the second category advertised the capabilities of the first. In other words, many specialized contract tools began to call themselves end-to-end contract management solutions.

Why did companies insist on claiming to offer an end-to-end solution? The phrase “end-to-end” was what got prospects in the door. Once companies had their prospects’ attention (or their business), they could afford to clarify that their tool only handled one part of contract management, or that the tool only handled one part of contract management well.

Here’s an overview of the contract stages:

1. Contract creation. Put simply, this is how companies create contracts, whether from a template or from scratch. This stage of the contract lifecycle is also called drafting or generation. Microsoft Word documents and PDFs are the de facto standards for contract files, so software solutions designed for document generation focus on enabling custom Word and PDF generation.
2. Contract negotiation. After contracts are created, but before they are signed, they may need to be negotiated with counterparties (i.e., the companies with whom you sign contracts). During contract negotiations, legal teams on both sides need to be able to track document changes, comments, and versions.
3. Contract approval. At small companies, it may be the case that a General Counsel can review and approve every part of a contract on their own. As companies grow, however, contracts tend to require functional and regional departments to approve different parts of contracts. The manual way to handle this would be to have someone review every contract, check to see which departments need to approve it, and route it to all parties for review. CLM tools automate and track review progress.
4. Contract execution. Once both parties are ready to agree to a contract, they both sign it. This step poses interesting logistical and technical challenges for CLM because the dominant tools for this step — eSignature solutions — have tended to be sold as separately solutions.
5. Contract storage. There are different levels of contract storage functionality. The most basic requirement is that contracts are stored securely. But it is also important to ensure the company folders are easy to navigate, that metadata is recorded in a relational database for easy reporting and filtering (e.g., show me all contracts with a value of over $5,000), and that the contextual history of a contract is stored — not just the executed contract itself. Contract storage is an excellent example of a contracting task that might be handled adequately by general software solutions (e.g., Dropbox) in the early stage of a company, but not as the company scales.
6. Contract management and analytics. The final stage of the contract lifecycle is contract management and analytics, which we define here as everything from contract administration and search to renewal and analytics. Because contract management is not as important to most companies as contract execution, and because it requires accurate contract data from across the previous contract stages, this category of CLM capabilities remains the least developed in the CLM space.

The formation of companies across every stage of the contract lifecycle offered companies more choices, but it also left many companies with tools that could only handle part of their contracting process and that failed to connect to their other systems (e.g., cloud storage or eSignature tools). We’re still grappling with the effects of this rapid unbundling today.

Unfortunately for consumers, the industry’s tendency to market specialized tools as “end-to-end” offerings led to a significant amount of confusion, especially for first-time CLM buyers.

It also led to a disjointed contract management approach: it might have been less expensive and less risky, in the short-term, to buy several point solutions for specific contract tasks, but this approach ended up being more costly and riskier in the long run, especially if those contract systems created information silos.

That’s why, even near the end of the 2010s, businesses looking for contract software had to choose between costly, highly customized contract management systems and low-cost, disjointed point solutions, or tools that only handled one part of contract management.

What changed by the end of the 2010s is that all the necessary components for a full-featured CLM began to reach enterprise maturity.

The contract management systems of the 1990s and 2000s were document management systems. They did not handle the contract lifecycle (from generation to approval to execution) so much as store completed contract files. These tools didn’t contract over email and incorporate eSignature capabilities, so there was no way to collect or store contract status or versions in real time.

The contract management systems of the 2010s were either costly and highly customized or inexpensive and limited in capability. The highly customized tools took months, if not years, to implement and were difficult to maintain and update. At the same time, the inexpensive, limited tools claimed to be full CLM solutions. These point solutions were easy to implement, but struggled to handle complex contract tasks.

Heading into the 2020s, the noise is beginning to die down. The CLM market has seen significant consolidation, with previous specialists like DocuSign attempting to create a general-purpose CLM by combining their eSignature expertise with the acquisitions of SpringCM and Seal, or Apttus acquiring Conga. At Ironclad, we’ve focused on building a single digital contracting platform—one that connects all the people, processes, and data involved in contract—from the ground up.

Meanwhile, the pace of innovation in enterprise software continues to accelerate. Rapid advancements in artificial intelligence (AI) and machine learning (ML) have changed the limits of what CLM can achieve. In our next piece, we’ll examine what that means for legal teams trying to choose a CLM that will help them over the next decade.

Understanding the history of CLM helps you know why certain business technologies have succeeded and others have failed, but it may not be enough to help you choose the right CLM solution for your company. For a comprehensive list of features to meet different CLM needs, check out our Contract Management Capabilities List.