Contracts are the blueprints of business. They define legal obligations, anchor commercial relationships, and shape day-to-day operations. Despite their importance, many of the world’s contracts are stored in archaic spreadsheets and SharePoint folders. These repositories quickly become cluttered, require constant manual upkeep, and throttle the speed at which you can accurately find key information.
Reliance on DIY tools might offer a sense of control on the surface, but underneath lies a critical mass of junk, inefficiencies and built-in bottlenecks at every turn, causing totally avoidable headaches. It’s like using a phone from 2008 to browse the internet – technically possible, but frustratingly inadequate.
Unlike casual web surfing, understanding business contracts leaves little margin for error. Yet, with a DIY approach, it’s a perpetual challenge to reliably locate, contextualise, and validate information when querying a contract. This inevitably leads to ballooned risks, recurring instances of operational oversight, and massive time sinks. We believe contracts should never be afterthoughts, crudely assembled with non-purpose-built tools, and left to busy legal teams (with little to no knowledge about data science) to build and maintain on the fly.
'Doing It Yourself' rarely leads to a single source of truth for your contracts—a sacred requirement for any viable contract management system. Even with an initially well-organised DIY system, the human effort involved is entirely devalued by the functional limitations of files, folders, and spreadsheets.
This article explores these constraints and how they hold companies back. It's not a pitch to buy Nomio– but a wider argument as to why you shouldn’t DIY a contract database.
“If you always do what you’ve always done, you’ll always get what you’ve always got.”
Navigating the complex realm of contracts through files, folders, and spreadsheets leads to a world of chaos. When important information is inevitably obfuscated behind layers of organisational neglect and technical limitations, what starts as a shortcut quickly becomes a roadblock.
After all, contracts aren’t just documents. A single overlooked agreement can have pernicious implications, ranging from missed opportunities to hefty financial losses. It’s, therefore, crucial to eliminate noise and frame your nexus of contractual agreements in an intuitive, organised fashion. In the age of information technology, sticking with antiquated DIY methods is the antithesis of this. It’s like locking up your most valuable assets in a chest and throwing away the key.
DIY systems typically snowball into digital landfills, where the lowest common denominator of anything legal-adjacent is indiscriminately dumped. This includes everything from drafts and unsigned agreements to duplicates and takeaway receipts. Cryptic file-naming practices only amplify this disorder – good luck trawling through a bunch of folders to find ‘MSA_v3_PleaseDocuSign_DRAFT_FINALLYSIGNED_COMPANY’.
Even with a standardised naming convention, it’s rare for a DIY setup to maintain complete fidelity towards a defined schema. Stragglers are inevitable, particularly when multiple people with varying degrees of respect for the rules are uploading to a shared repository. This leads to junk files and poorly named contracts sitting side-by-side, blurring the lines between actual agreements and irrelevant clutter. Without across-the-board consistency in naming and organisation, contract databases become murky pools where information is obscured, increasing the risk of overlooking important documents.
Effective contract management systems should operate with zero noise, ensuring every document is correctly identified and catalogued.
However, it’s not just human disorganisation that erodes the suitability of DIY models. Files and folders are inherently inadequate on a technical level for the task of modelling agreements that contain multiple documents. File systems cannot intuitively portray how different elements of a contract relate to each other and form an order of precedence. Instead, legal teams tediously locate and review individual documents to mentally model the structure of an agreement and determine how its constituent parts fit together. "How does this unorganised sequence of amendments fit together to vary the original agreement?" "Where are the T&Cs for this Statement of Work?" "I wish the terms of this MSA were reflected in the 37 different Purchase Orders we’ve got…"
Unfortunately, no level of individual competency can overcome this, not least because the human brain isn’t built to rapidly compute the anatomy of a contractual agreement by staring at a bunch of file names. Folders and spreadsheets do a poor job of assuming this burden – they can’t represent how contracts work on a structural level.
Folders also do a poor job of categorising agreements. Take a compliance software subscription agreement; do you place it in an IT, Supplier, or Legal folder? Given that it falls under all of these business areas, you may opt to duplicate it across the three folders to ensure completeness. However, this increases the chances of confusion if the agreement is ever amended or updated. When three decentralised versions of a contract are scattered across folders and sub-folders, there’s little guarantee that any changes will be uniformly reflected across the entire contract portfolio. Having competing sources of truth is fatal to the reliability of a contract database.
Duplication across sub-folders also silos documents within categories instead of providing visibility across a cross-section of multiple categories. For example, you might want to see all agreements that fall under the intersection of IT and Legal but have no intuitive way of executing this search.
Often, shared repositories will also employ sub-folders to segment agreements according to who they pertain to. The People folder exists so the HR department can see what matters to them without wading through agreements that are only relevant to other departments. This is a valid way of streamlining a contract database, but it neglects the importance of confidentiality. Folders don’t allow you to assign view/edit permissions based on a person’s role in the company, such that they can only access agreements that fall under specific categories or a combination of multiple categories. This often creates a reluctance to give employees access to an entire contract suite even though it would make their work easier and reduce the demand on legal teams to retrieve and review contracts.
Having a disorganised contract management framework is hugely inefficient. Valuable hours are sunk into maintaining an inherently flawed system that only breeds even greater inefficiency when it comes to actually using it. As the volume of documents stored within a DIY system increases, the difficulty in making sense of it all compounds. The task of cleaning it up goes from mammoth to gargantuan, thereby getting relegated on the list of priorities to the point where organisational rot sets in, and there’s no longer a sense of responsibility to keep things tidy. Legal teams then spend excessive time sifting through spreadsheets and folders, attempting to pinpoint the latest version of an agreement or decipher the connections between scattered documents.
DIY contract management produces a self-defeating loop where companies incur huge overheads for unproductive, non-legal work, and legal teams are set up to fail with the completely wrong tools for organising large volumes of contracts.
Legal expertise rarely comes with a complementary proficiency in data science. Lawyers know how to draft and interpret contracts better than anyone, but they know less how to manage a complex agglomeration of them within a database that accurately captures the information they contain. Legal teams also have notoriously busy workloads, meaning there’s little time for them to assume the responsibilities of full-time information architects tasked with adequately maintaining a contract database.
Capturing contract information using internally maintained spreadsheets exemplifies this issue. These databases demand the creation of a rigid taxonomy that outlines what data needs to be captured and how it should be captured. The problem is that contracts are an exercise in edge cases. The more important a contract, the more likely it contains bespoke clauses which behave uniquely and defy simple classification. Legal teams constantly have to adapt their approaches to accommodate new manifestations of a data point and often end up shoehorning information where it doesn’t belong. This leads to values within the same data point being expressed inconsistently from contract to contract rather than in line with established protocol. As a result, it becomes harder to trust that the data in a spreadsheet means what you expect it to mean.
This burden of maintaining a contract database never ends; information doesn’t just need to be correct and uniformly expressed at a given point in time, but perpetually. Ambiguities need to be identified and resolved, terms need to be updated to reflect amendments, rules need to be consulted and followed when capturing new data, and so on. In-house teams don’t have the time, resources, or extensive experience translating contractual quirks into fixed data points, to do this well.
The problems with doing it yourself become even more pronounced when one employee inherits another’s DIY system. The blueprint for the database is often siloed in one person’s head, presenting massive organisational risk if they leave the company. Suddenly, no one can make sense of the database, and it ends up having to be remodelled entirely to restore any clarity.
The flip side is when multiple people are responsible for maintaining a database, each bringing their own method of documenting information. This divergence complicates things further, transforming what might otherwise be a straightforward knowledge transfer from one brain to another into a complex puzzle. Each contributor’s individual quirks have to be understood to interpret the database, creating confusion about the correct approach in a sea of aberrations.
Most DIY contract databases also lack the computational ability to represent the dynamic behaviour of contracts. This means key information is left out or has to be tediously manually calculated, creating scope for human error and wasting precious time. For example, simply inputting the Initial Term Expiry Date won’t tell you the length of the Initial Term by relating that to the Active Date, and recording a Renewal Term alongside a Renewal Notice Period won’t generate a sequence of Renewal Dates and Deadlines for you. Spreadsheets don’t perform well at programmatically infusing the logic of contracts into your database. They demand too much of legal teams, rarely adhere to a properly fleshed-out blueprint and are hopelessly reliant on manual data entry.
Organising documents and capturing key data points within a spreadsheet provides a basic overview of how your agreements behave. Still, there’s no substitute for the contract itself.
A single data point isn’t always enough to paint the whole picture and capture any important nuance. You might record Indexation as “RPI + 3%”, but understanding the various extraneous conditions attached to effecting this price adjustment requires reading the relevant clause in the contract. Spreadsheets, however, don’t allow you to link any information you capture in a cell directly back to the exact phrase and clause from which it was captured. This is a fatal flaw of DIY spreadsheets. Anticipated time-savings are wholly negated when you have to manually dig out the provision in the contract to understand the practical application of a data point.
Even worse is that this means spreadsheets are not auditable. You can’t click into a data point and instantly trace where it’s been captured from in the contract to validate its accuracy. As a result, even a single mistake in a DIY contract database shatters any confidence in relying on the spreadsheet - there could be a litany of further errors that can’t be easily identified through an audit trail.
You don’t get 80% of the benefit from an 80% accurate database. Even a slight compromise in accuracy means you’ll avoid making any real decisions based on a spreadsheet and just go looking for the contract instead. An effective contract management solution solves this by relating data points to the wording within the contract it derives from, as well as showing it working for automatically generated values not explicitly contained in the text. Spreadsheets tell you how someone in the company has decided on a whim to translate a complex clause into a simple number or value. Without the surrounding context, it’s rarely much help.
DIY databases also lack the powerful search and filtering functions needed to get atomic insights into contracts and quickly answer questions about them. You might be able to sort a column in a certain way, but this doesn’t equate to having the option to intelligently filter the list of agreements down to ones that correspond to specific properties, e.g. agreements made with European suppliers that have a renewal date in the next three months. There’s also no in-built capability to universally search for certain words or phrases across a defined set of agreements. Without these functions, locating key information takes a lot longer, and there’s no way of having top-down visibility of a certain provision or data point across a number of documents at once. An effective contract database should empower you to demand information from it, not send you searching for a needle in a haystack.
Folders and spreadsheets are, therefore, poor solutions for contract management that don’t accommodate the fundamental importance of the actual wording of the contract or allow you to probe deeper into the terms of your agreements.
Relying on spreadsheets and folders hampers oversight and accountability. These systems are static and designed for reference, not purpose-built for the dynamic management of contracts.
There’s no means of generating timelines for upcoming obligations or producing detailed reports that list contracts that share certain data points. You end up having to find out the answers to questions like ‘What contracts do I need to stop from auto-renewing in the next few months?’ or ‘Which supplier contracts above a value of £1m are due to expire this year’ through a painstakingly manual process.
DIY systems don’t natively integrate feedback loops into the contract management framework. There’s no baked-in system that allows discrepancies and ambiguities to be flagged, reviewed and resolved. For example, contracts with conflicting terms or missing signatures. You also can’t add notes to add any additional context/information to a contract or upload non-legal attachments to an agreement, such as evidence of a deliverable being completed. This leads to the corollary problem of not having an auditable paper trail of who in the business has actioned something or manually populated a data field. Without these functionalities, the health of your contract database is compromised. A host of undetected problems metastasise until they eventually come to a head and cause damage to the business.
Spreadsheets and folders don’t facilitate seamless integration with external applications. This frustrates the efficiency of workflows that rely on synchronisation between contract repositories and other tools like CRMs, DocuSign, Salesforce and so on. Without this real-time data exchange, companies waste valuable time on manual data entry, and things inevitably slip through the cracks. Modern contract databases should interface fluidly with other platforms to ensure contractual information is being efficiently and accurately leveraged across the business.
Ultimately, the shortcomings of spreadsheets and folders extend beyond just inconvenience; they represent a significant misalignment with modern business practice and the need for innovation and agility. These aims can’t be fully achieved when the contracts that underpin every corner of your enterprise are managed through outdated tools that lack the functionalities and integrations necessary for effective workflows.
DIY contract management causes death by a thousand paper cuts. Answering basic questions about your contracts takes far too long, and the vulnerabilities of files and spreadsheets erode any confidence in the answers you eventually come up with. These outdated tools preclude access to valuable contract management and oversight features that offer critical visibility over your contractual estate.
From the hundreds of customers we’ve spoken to, it couldn’t be clearer that DIY’ing it almost always causes more pain than it alleviates. This is an entirely predictable outcome of employing dated systems that were never designed to accommodate the unique complexity of contract management.
Our competitor is the status quo, and we’re determined to change it.