Ask a procurement lead at a mid-market manufacturer what software they use to manage supplier contracts and the answer is almost always some variant of the same thing: a shared Excel file, a folder on SharePoint, and email. Sometimes Outlook tasks for reminders. Occasionally a tab in a project management tool that nobody opened after February.
We built Atira specifically because of how many procurement teams we found operating this way — not out of ignorance, but because the alternative they'd been shown was a £60,000 enterprise CLM platform that required six months of configuration and a dedicated contract manager to maintain. The spreadsheet, at least, works on day one.
This piece is an honest look at what the contract management tooling landscape actually looks like for teams with 2 to 8 people managing supplier relationships — what they use, why they use it, and the specific failure modes that tend to finally push them to look for something different.
The spreadsheet as a perfectly reasonable starting point
A well-built contract register in Excel does a lot of things adequately. It holds supplier name, contract value, start date, renewal date, notice period, and owner. It can be filtered. It can be sorted by renewal date to produce a quarterly view of what's coming up. For a team managing 40 or 50 active supplier contracts, that's often enough.
The problems emerge at the edges, and they emerge slowly. The spreadsheet doesn't know when a contract has an unusual notice period — say, 120 days rather than the standard 30. It doesn't capture the escalation clause buried in Section 7.4 that means your costs will increase by RPI + 3.5% automatically each April. It doesn't flag when a volume rebate threshold was crossed eight months ago and nobody claimed it. All of that lives in the PDF of the original contract, which is either in a shared drive folder that has three different naming conventions, or in someone's email inbox, or both.
The spreadsheet is a metadata layer. It tracks that contracts exist. It doesn't read them.
Where SharePoint and network drives fit in
Most mid-market procurement teams have some form of document management — typically SharePoint or a mapped network drive — where the actual contract PDFs live. The quality of this varies enormously. In one case we looked at, a building materials distributor with around 180 employees had a SharePoint folder structure that had been set up by three different people over six years, resulting in contracts appearing in up to four different locations depending on whether the person filing them thought of the relationship as a supplier, a vendor, a partner, or a service provider.
Finding a specific clause in a specific contract in an environment like that isn't a five-minute task. It's a twenty-minute search, followed by a PDF scroll, followed in some cases by a phone call to the person who negotiated the contract to ask if they remember what the notice period was.
We're not saying SharePoint is the wrong tool for document storage — it's a reasonable place to keep contract files. The issue is that storing a PDF and being able to extract structured intelligence from it are completely different problems, and mid-market teams have historically had to solve both with manual effort.
Why dedicated CLM platforms haven't taken hold in this segment
Enterprise CLM platforms — the category that includes tools designed for legal operations teams at large organisations — are genuinely capable software. They can track obligations, set automated alerts, handle multi-party workflows, and integrate with ERP systems. For a company running a legal department with dedicated contract managers, that capability set makes sense.
For a procurement team of three people at a £50 million turnover business, it's usually too much. The configuration burden is significant — you need to define your contract types, map your approval workflows, set up your fields, and often integrate with existing finance systems. The commercial model is typically structured around users and modules in a way that prices smaller teams out. And perhaps most importantly, the value proposition is built around workflow and compliance rather than around the financial intelligence — the clause-level data that tells you what your contracts are actually costing you.
This is the gap we designed Atira to sit in. Not a full workflow platform, not a dumb spreadsheet — but a tool that reads what's in the contracts you already have and surfaces the things that are costing you money you didn't know you were committed to spending.
The DocuSign and e-signature layer
One area where adoption has genuinely happened in this segment is e-signature tooling. Most mid-market procurement teams are now using some form of electronic signature — either DocuSign, Adobe Sign, or increasingly, the e-signature functionality bundled into their existing Microsoft 365 subscription.
This has created an interesting asymmetry. The execution layer of contract management is now reasonably well digitalised — contracts are signed electronically and a record exists. But the intelligence layer — what those contracts say, how they renew, what they commit to — is still almost entirely manual. You end up with a clean record of the fact that a contract was signed, and no systematic way to understand what you signed.
The specific failures that force a change
Teams don't switch away from spreadsheets because they've evaluated the market and concluded that modern tooling is superior. They switch because something broke. The most common triggers we've encountered are:
A contract auto-renewed unexpectedly and the team is now locked in for another year with a supplier they wanted to exit. The notice period was 60 days and nobody had set a calendar reminder early enough. This one is painfully common.
A price increase arrives from a supplier and nobody can find whether the contract actually allows for it, what the mechanism is, or what the cap should be. Three people spend two days reading through the contract and its amendments before a definitive answer emerges.
Someone leaves the procurement function and takes with them the context about which contracts have which quirks. The handover notes don't mention that the facilities management contract includes a 15% uplift clause if headcount exceeds 250, and the company hit 260 employees four months ago.
In every case, the underlying problem is the same: the intelligence is in the contract documents, and nobody has a systematic way to get it out.
What we've learned from building tooling for this use case
The thing that's taken us time to understand is that the right framing for what we build isn't "contract management software" — it's contract reading. The management — deadlines, owners, workflows — teams have mostly solved, imperfectly but adequately. What they haven't solved is the problem of knowing what their contracts actually say at the clause level.
When we run a contract through Atira, we're not replacing the spreadsheet or the SharePoint folder. We're answering the question the spreadsheet can't: what is actually in this document, and what is it going to cost you if you don't pay attention to it? The auto-renewal alert is useful. The price escalation extraction is more valuable. The MFN clause sitting unclaimed in a contract signed three years ago is often the most valuable thing of all.
For procurement teams still working primarily in Excel: we're not saying the spreadsheet is the wrong tool for what it does. It's fine for what it does. The question is whether what it does covers the full scope of your exposure — and in most cases we've looked at, it doesn't get close.