Warning: we have them.

“Our current system doesn’t work because we didn’t set it up properly.” That’s the sign of a brainwashed customer.

Draw a blue horse with wings. If both you and Leonardo da Vinci did this, you’d both satisfy the functional spec.

All-in-one (wide) vs best-of-breed (deep)? Some problems need you to go extremely deep just to get an acceptable solution.

“On the 29 February each Contract Year, Service Provider shall…” This is a real life snippet of a contract put together by a “top” law firm.

Picking the cheapest vendor is like picking the cheapest parachute. It’s quite expensive to resurrect someone after a big splat.

Why do heavyweight, sprawling software deployments always seem to fail? The answer: People are idealistic.

Did you get invoiced (and therefore pay) more than was agreed in the contract? This is a real pain point for larger companies and government projects.

The problem looks easy but is actually hard. This is why for some domains, all the available solutions suck.

Create more categories and you create more of a maintenance burden. Even if you stick to your strict system, your colleagues won’t.

Contractual risks are things you’ve agreed to that could hurt you in the future, like uncapped liability.

Remember the murderous maze from Harry Potter and the Goblet of Fire? That’s what our system of laws and regulations is like.

A greedy algorithm is where you take the best possible next step. You incrementally improve the system, always focusing on what’s right in front of you.

Your counterparties are far less keen than you to use your end-to-end contracting workflow. They may well insist that you follow their process, not yours.

Contracts are a minefield for unlikely or poorly understood hazards. Especially if the contract is bespoke or has been heavily negotiated from a template.

The system is clogged. It is slowly strangling us. We keep adding more laws than we remove. We yawn when rules are put in place only to complain when their removal is threatened.

Files and folders are fundamentally insufficient for contracts. They can’t model the relationships between contractual documents and their constituent obligations and data.

Every good thing has a negative tradeoff. Or so we’re told. Sure… in the pursuit of simplicity, you might upset someone. You have to say “no” a lot.

Your HR system overlaps employee compensation data with your accounting system which overlaps customer billing data with your CRM etc.

Is there anything more desk-smashingly frustrating than a product that doesn’t work? Not just when it doesn’t work, but when it doesn’t behave as expected.

If you’ve ever done a clear-out of your possessions, you’ll know how amazing it feels afterwards. Get rid of junk data, software, and features. You will feel great.

You can instantly find the price you paid for your cheapskate toaster 3 years ago. Yet it takes you untold hours to figure out your liabilities across your customer contracts.

It takes seconds to burn a book that took years of meticulous work to create. There is a jarring asymmetry between order and chaos.

The same person who’d happily pay £6 for a pint of beer will go to any lengths to avoid paying 69p for an app.

“We keep missing key dates in contracts.” Why hasn’t this problem been solved? It looks so simple on the surface but it’s incredibly deep.

The more places you back up your data, the lower the risk of data loss. The more people you entrust a secret to, the greater the risk of a leak.

Organising, storing, and retrieving information… there is literally a science to these things. Do lawyers learn any of this science? Procurement professionals? Commercial teams?

Imagine a world where all contracts are ultra-standardised. Data capture becomes incredibly easy; each document is the same.

Unlike your sales contracts, your procurement contracts look different to each other because they originated from your multiple different suppliers.

When building a contract database, you don’t start knowing exactly what you want. You don’t know what data points you care about capturing.

A contract database is only useful if it’s tailored. It needs to conform to your business, your processes, your contracts, and the data you care about inside them.

Even simple contracts contain hundreds of potential data points. In any given scenario, you probably only care about a small subset of those.

If your piano is missing half its keys, even the best pianist will struggle. They’ll spend more time working around the problem than playing beautiful music.

Why does so much “perfect” software fail? Implementation and maintenance. Features and functionality are only as good as the manual effort required to make them possible.

If your business model is predominantly consulting / time-and-materials, you might be missing a trick.

The total business value of 10,000 NDAs is probably worth less than your single most important customer contract.

How do you standardise chaos? A contract database needs to do exactly this. Contracts are extraordinarily variable from one to the next. This is why they’re so tough to manage.

It’s hard to appreciate a solution until you’ve tried solving the problem. This is why it’s a good idea to first try building your own contract database first.

You’re losing money because your teams have no way to collaborate over contracts. Let’s go through an example.

The term of this agreement shall be two (3) years from the commencement date. It’s scary how often we see errors like this.

The blacksmith crafts the sword and the knight wields it. So why do we expect lawyers to be information architects?

Today’s contracts are optimised for production, not consumption. For decades we have been using them to write contracts faster, write more of them, and make them longer.

Cost. Price. Contract Value. These are data points we’re often asked to capture from our customers’ supplier contracts. We then peel the cost onion.

1,000 contracts representing £1,000 each are collectively 10x less valuable than one £10M contract. Value and importance are not evenly distributed across your contracts.

All-in-one Contract Management Systems (or CLMs) are far more expensive than what you think. You need to pay a person full time to setup and maintain the system.

Your system that works 99% of the time might crumble 1% of the time due to an edge case. Accounting for that edge case is disproportionately costly.

“Ten business days prior to the end of each Contract Quarter, Service Provider must <do very important thing or suffer a penalty>”.

In any network, you have nodes and links. Like how cities are connected with roads. Data points within a contract are like nodes.

There’s a big difference between a program and a data file. You could boil an invoice down to a row in a data file or spreadsheet, since it’s simply a flat list of key-value pairs.

“Can you get me all data processing clauses across our contracts?” We hear this one a lot. It’s not a very good question.

Different contracts within the same organisation contain different types of information. Sometimes this information is specific to the organisation.

Optimise your important contracts for ease of management, not convenience pre-signature. There are so many examples but we’ll focus on one.

“I could easily build it myself”. This is the voice of someone who hasn’t tried building it. If they think it’s easy but it’s actually hard, they won’t want to pay what it’s worth.

Imagine you have a fantastic accountant. However fantastic he is, his head isn’t the best place to store your bookkeeping data.

To analyse data, it first needs to be accessible. Both to humans and computers. Humans need a good interface to see and explore that data.

Unpopular opinion: auto-renewals make contract management easier. It’s easy to see why for your customer contracts.

You will sign a healthy proportion of your contracts on someone else’s e-signature solution. There are hundreds of e-signature solutions out there.

Contracts are a composition of atomic pieces. Those pieces may link to each other. A list of parties.

Buying a contract management system (or CLM) is like buying a computer in the 1970s that you have to program yourself.

When you buy an all-in-one product, don’t complain about the bloat. You signed up for it. Most of the buttons clogging up your view and confusing your team were added for someone.

Maybe you think you can “get away” with sloppy contract management because your counterparties are also sloppy.

When you go on holiday, the destination is what matters. You probably just book the cheapest flight you can find.

Your contracts represent your most important business relationships. They are lists of self-imposed rules that if breached, threaten those relationships.

When you buy an all-in-one contract management system, make sure you actually need all of it. And that you need all of it straight away (spoiler: you probably don’t).

Contract negotiations often drag. A contract database can turn a headache into a secret weapon for closing deals faster.

Sometimes you want a data grid that you can filter and manipulate. This is the structured, numerical world.

Poor contract visibility is ruining your customer relationships. Do you have customer contracts that deviate from your standard terms?

A sword to the chest is more dramatic than a thousand paper cuts, but both can hurt. The paper cuts are dangerous.

With text-based information like contracts, you might be tempted to just train a large language model (LLM, or “AI”) on a bunch of text and ask it questions.

90% of your contract data is invisible. Even if you flawlessly copy and paste contract data into all your other systems. CRMs, HR systems, risk and finance systems, etc.

The contract is the source of truth, not the systems you copied it into. And that source of truth isn’t static.

Let’s look at a common scenario that beautifully illustrates how important, hard, and neglected contract structure is compared to data capture.

Do you have standard terms of service your customers sign when they purchase from you? Customers will often push back on these terms.

The only justification for a complex solution is a complex problem. A complex solution can’t be designed or built straight away.

If you’re establishing a system of record, you should optimise for minimising effort over anything else.

Your customer needs to pay you for a product or service you’ve delivered. You need an invoice. You type a bunch of numbers into a structured form.

The digital revolution made collection and storage of information extremely easy and cheap. That wasn’t always the case.

For any interpretation of a contract to make sense, you first need to make sure you’re looking at every single one of the documents that make it up.

All you need to do once you’ve signed a contract is get hold of the PDF, correctly file it away in our shared drive that our IT team arbitrarily restricted your access to.

Your contracts are set up for failure. Not because of what’s in them (maybe that too), but because of how their information is stored.

Negotiations happened and janky terms were agreed. Even if the people responsible are still around, nobody is going to remember all of those sharp edges before they cut you.

Every part of a business has contracts and every contract has multiple stakeholders, usually sitting across different parts of the business.

Contracts aren’t just data, but instructions. A contract database therefore not only needs to capture that data, but simulate the instructions that surround it.

Imagine paying for a hotel and then sleeping on the street instead. That’s exactly what so many companies do with their contracts.

Events, opportunities, mistakes, and unconsidered risks manifest at a moment’s notice, lurking in the shadows before pouncing at the worst possible time.

While a deal is in flight, both parties have their eyes on the contract. Once the deal is done, attention fades.

Much like a mathematically-inclined rabbit, contracts are fuzzy and logical at the same time. They are written in legalese.

You probably have hundreds of other places that poor contract visibility is costing you. But it is a stone-cold guarantee that you won’t solve them until you solve these ones first

When you sign a contract with a new customer, there’s a good chance they negotiated your price increase clause.

Business software articles suck. They’re too long and they’re miserable to read. Half the time they’re written by offshored content farms. No flavour. Yuck.

Over time, we’ve seen all of our competitors morph into end-to-end contract management systems. Some of them have been acquired and stuffed into portfolios.

Some IT teams really don’t like the idea of their colleagues buying us. They insist that “we can build our own contract database using SharePoint”.

There’s so much work involved to set it up. To get used to a new process. To watch those horrible training videos.

Our technology and focus mean that we can do an incredible job with contracts of any complexity. We routinely deal with contracts over 1,000 pages.

Fully autonomous self-driving cars have worked well along a standard highway for more than 10 years.

Contracts are made up of multiple documents. Information sits across those multiple documents and often conflicts with or overrides information in other documents.

Complex contracts are often completely unique. There is no training data for them. They don’t at all fit into the pre-defined taxonomy.

Trying to build a contract database on top of PDF and Word is like trying to teach calculus to a chicken.

There’s a gigantic gulf between how you think you’re going to use a piece of software and how you actually end up using it. So many naive assumptions.

AI is expressed through software, but that doesn’t mean that AI has the same characteristics of “classic” software.

The majority of contract database projects fail miserably. Why? Because the people behind them don’t go deep on The Blueprint.

If you’re building a fruit-processing plant, you want to know what kind of fruit you’re going to be dealing with. If it’s just oranges, that’s great.

Most of the work involved in building a rock solid contract database is incredibly resistant to AI, so to us it’s always been strange to see AI pedalled as the solution.

There are many products out there pitching themselves as “document processing”. A lot of them even mention working with contracts.

Many of our customers have moved to us from less powerful (and harder to use!) contract “repositories”.

“Data entry”, “data labelling”, “quality assurance”. These jobs are typically offshored to developing countries with low-paid and low-skill workers.

In a market for lemons, like used cars, the buyers don’t know how to buy. What questions to ask, what makes a good used car vs a bad one, how to test it themselves, etc.

Processing agreements is extremely costly; to do it pre-execution where the agreement has not been finalised means that you're going to have to perform an analysis several times.

When there is no naming convention, names cease to be helpful. Without predictability of names, you cannot search your documents by name.

Contracts are written and negotiated by people. People make mistakes. Therefore the world of contracts contains mistakes.

In the pre-execution world you need to act fast. There are deal timelines, documents are going back and forth getting negotiated.

If you set up a self-maintaining contract database that comes with a blueprint, then it doesn’t matter who comes and goes.

A simple 2-page NDA and a convoluted 500-page project infrastructure agreement are both contracts, but that’s where the similarities end.

Bringing in a new piece of software is hard enough. Doing so with end-to-end CLM bloatware that sits across everything you do is virtually impossible.

With documents like invoices where there isn’t much data, you may as well capture everything. But even simple contracts contain hundreds of potentially-useful atoms of information.

Every important business relationship appears in a contract. Business relationships happen all over the place: customers, suppliers, partners, employees, shareholders.

Whatever contract database you choose, it needs to link any captured or “extracted” (eugh!) information back to where it came from.

Without Nomio, there are at least 19 steps required to build a contract database. With Nomio, there's just one.

Contracts are touched by every part of a company. It’s a myth that they are the domain of the legal team. In fact, the legal team is the direct stakeholder in very few contracts.

The contracting pipeline is an extremely complex beast. Contracts are littered with edge cases and exceptions.

We don’t invest any resources in G2, Capterra, Gartner etc.Why? They are pay-to-play. Everyone on there is between 4 and 5 stars.

From day 1 we said that there would be no mess for our customers to clean up, which means that we would make sure everything was done to 100%.

Contracts have different ways of expressing the same information. So in addition to capturing the raw information in your contracts, you need to also standardise it.

When it comes to building a contract database, any subsequent steps aren’t going to be useful unless you first do the work of organising your documents into agreements.

Creating an exhaustive record of all key contract dates extends well beyond merely extracting them, and very few solutions actually do this.

The key dates you most care about cannot be “extracted” because they are almost never in the contract. You need to go further than extraction.

We had one very angry customer ask us why they weren’t notified of a key date, only to find that they had never set up a notification rule to begin with.

Imagine building a building without a blueprint. You don’t bother with the effort of planning and standardising spaces, plumbing, or electricity.

Imagine you’re creating a spreadsheet to act as your contract database.Your colleague reads through each contract and enters key information into each cell of the spreadsheet.