The AI Maturity Curve in Procurement

TL;DR: This eight-stage curve is an editorial framework drawn from practitioner experience, not a benchmark dataset. Use it to identify the capabilities and operating-model questions that tend to appear as procurement moves from office tools and systems of record towards AI-enabled and agentic work. Teams can occupy different stages in different workflows, and the purpose is to expose the next constraint—not to award a maturity score.

By Daniel Barnes, procurement practitioner and writer at World of Procurement.

I’ve seen this play out over the last eleven or so years.

People start with nothing but the office suite of tools their company already uses. It used to be predominantly Microsoft. Then Google ate away at this. But it’s where the tech stack for getting started in procurement begins, and a surprising number of teams still live there today.

Then they hit a wall, push against it, find what’s possible, and look for what’s next. Each stage on the curve is a wall hit and then crossed. Each stage looks like progress from the inside and obvious-in-hindsight from the outside.

What follows is the eight stages I’ve watched teams move through. With the wall at the end of each one, and what unlocks the move to the next.

Microsoft. Google. Outlook. Excel. Word. SharePoint. Drive. It’s where procurement starts in nearly every business under a certain size, and it’s where a surprising number of large procurement functions still live.

This is fine for a while. Then volume hits. Or audit hits. Or someone asks “what’s the status of the X contract?” and nobody can find the email thread. That’s the wall.

People get fed up with the basic kit, so they push it. SharePoint as a contract repository. Power Automate or Google Apps Script flows between the office tools. Excel dashboards that feel almost like a system.

This is creative work and a lot of it is impressive. But it depends entirely on the person who built it. When they leave, the workaround leaves with them. And the office tools weren’t designed for the load you’re putting on them. Eventually something breaks, or the maintenance burden outweighs the benefit. That’s the wall.

Some teams move to a no-code tool. Trello. Notion. Monday.com. Airtable. Anything that lets you store data and track tasks more rigorously than a spreadsheet, without buying enterprise software.

This step isn’t mandatory. Many skip it. Many are actually missing a trick.

If you’re an SMB and your volumes aren’t high, and procurement is less complex, you may find this is where you can stop. I vibed with Notion last year and built a supplier database and a small set of workflows in a focused working session using their agents. For a lot of teams, this genuinely does the job.

For teams with more volume or more complex requirements, this gets stretched too. The wall here is the limit of what generic tools can do with procurement-specific work.

This is where many teams turn to the market. They look at what their colleagues at other companies use. They start looking for a system built for procurement.

Many start with a system of record. Somewhere to keep the contracts, the suppliers, the spend data. Coupa is the biggest in the category and is, arguably, first and foremost a system of record. Other names show up here depending on what you’re looking for.

This is good for the auditor. It’s good for the new hire who needs context. It’s where most procurement digital transformation projects start, because it’s the foundation everything else gets built on.

But a system of record on its own doesn’t change how the work happens. It just gives you somewhere to put the artefacts of the work. The wall is that the team is still doing the same work, just storing it more tidily.

The next move is to layer digital processes on top of the system of record. Auto-completion through workflow automation built for procurement. Approval routing. Conditional logic. Forms that pre-populate. Notifications. The full kit.

This is where it gets difficult. And this is where most procurement teams I see are stuck.

Up to this point, you’ve been able to take your old manual processes and apply tools to them. Now you have to rethink the work itself. You don’t need a step that says “email X, Y, Z stakeholders, detail the review, explain what needs to happen.” The tech handles that orchestration through workflows and automations. So what does the human step actually involve? Many teams don’t know. They’ve never had to write it down.

A lot of teams don’t have the in-house expertise for this kind of rethinking. So they go external, or they partner with their tech vendor. Both can prove useful, depending on the relationship. The teams that pull through it tend to be the ones who treated this as a process redesign exercise rather than a software implementation.

This stage is where the bar is for many. They have the tools. They have the workflows. They don’t know what to do next.

The wall here is not a tech problem. It’s a thinking problem.

The next wave is when your existing procurement vendor starts shipping AI features inside the tools you already use.

You can deploy AI that reads and extracts supplier documentation. Quotes. Invoices. Contracts. Anything that has words on it. You can deploy agents that sit across the workflows you’ve already built, if you’re fortunate enough to have a tech vendor that has built agentic capabilities and made them deployable for you.

I won’t comment on which vendors are doing this well. The market moves too fast for any specific call to age well. The thing to recognise is that this is a real stage, and it lives inside the platform you’ve already adopted.

The wall is what the vendor gives you, and what they don’t. If your vendor’s AI is good for contract extraction but not for negotiation, you’re stuck with that ceiling unless you go outside the platform.

Or maybe a team takes a different route. They start using a chat interface with a foundation model. Claude. ChatGPT. Whatever they get on with.

They start playing with the capabilities. Plugins. Skills. Projects. They realise this stuff is actually good. They start moving real work through it.

It’s not without friction. The foundation models still produce a lot of confident nonsense, so this requires a heavy hand in review and constant working with the output. But it moves the work. It lets the team move faster than they could without it. And the more recent generations can connect to existing systems via MCP, so the chat isn’t trapped in its own window.

The wall here is the gap between “I can use this for my own work” and “this can run unsupervised against our supplier base.” It can’t, yet, in this form.

This is where it gets interesting. And it’s where I’m spending my time going forwards.

There’s a new wave of capability that not enough procurement people know about. Agentic platforms purpose-built for procurement work, that can deploy agents across your tasks irrespective of which system of record you bought, which workflows you’ve built, or which vendor you’re tied to.

The substance of these platforms is what makes them different from “ChatGPT plugged into your stack.” They’re trained on real procurement decisions and outcomes, not just text from the internet. They’re built with guardrails and validation layers, not raw LLM exposure. They connect across systems through proper integrations, not just chat. And they take action — they actually transact with suppliers, run negotiations, monitor for changes — they don’t just suggest. All four together. That’s the difference.

The guardrails matter most. The agents can’t hallucinate their way into a six-figure mistake, because they’re much more than the foundation LLM. They’ve got more substance.

We’re only just getting started here. This is the exciting piece of the puzzle. The piece where I’ll be spending my time going forwards.

If you read this and tried to place your function on the curve, you probably landed somewhere between Stage 4 and Stage 5. That’s where most procurement teams I talk to actually are. They have a system of record. They have some workflows. They don’t

yet know how to think about the AI layers above.

That’s fine. The curve is a journey, not a race. The teams that pull ahead are not the ones who skip stages. They’re the ones who do the thinking at each stage properly before moving up.

Automation runs scripted steps in a defined order. Someone wrote the rules. The system executes them. It’s deterministic.

Agentic AI takes a goal and works out how to achieve it. It can read unstructured input, apply policy, take action, and adapt when something unexpected happens. It’s not following a script. It’s reasoning.

In procurement terms, automation handles “email the requester when the PO is approved.” Agentic AI handles “negotiate this renewal within these parameters, escalate to me if the supplier won’t agree to the walkaway point.”

In my read, there are eight. Office suite. Office suite pushed to its limits. No-code tools. System of record. Workflows built for procurement. AI inside your procurement tools. Foundation models used standalone. Vendor-agnostic agentic platforms. Most teams are stuck somewhere between stage four and stage five.

RPA is rule-based scripted execution. Same input, same output, every time. It does the boring work that humans used to do.

Generative AI produces content. Text. Drafts. Summaries. It’s the layer that writes things in context.

Agentic AI takes goals and produces actions. It uses generative AI as a component, but it also reasons, plans, and executes. The difference is that you give it an outcome, not a procedure.

It will replace some routine tasks. The transactional buying work. The routine reviews. The chasing-for-status work. The judgement work — supplier strategy, complex negotiation, executive commercial decisions, relationship management — stays with humans.

What changes is the ratio. More time on judgement. Less time on orchestration. New roles will emerge: AI portfolio manager, agentic operations lead, supplier-side intelligence roles. Procurement will keep being procurement, with the time spent on it redistributed.

Maybe not yet, and that’s fine.

If your volume is low and your processes are simple, a no-code tool can give you a supplier database and basic workflows in a couple of hours. You’ll know when you’ve outgrown it. The signs are: forms that no longer hold the data you need, approval routing getting complicated, audit requirements that need a real trail. When you hit those, the move to a proper procurement system makes sense.

Skipping stages costs you. Going from spreadsheets straight to enterprise procurement software usually means you spend a year configuring something for processes you haven’t redesigned. Better to grow into the stage above.

Pick one process where you have high volume and clear rules. Standard contract reviews. Vendor onboarding. RFP scoring. Don’t pick the most complex thing first.

Get the criteria documented. What does “acceptable” mean? What gets escalated? Where are the exceptions? AI deployed against unclear criteria amplifies the chaos.

Set up a small pilot with a clear definition of success. Cycle time. Hours saved. Error rate. Three months. Measure it.

Either deploy through your existing vendor, through a foundation model, or through a vendor-agnostic agentic platform depending on where you are on the curve. Don’t try to deploy at a stage higher than your function is at. That’s how pilots fail.

A platform that can deploy agents across your procurement work without requiring you to rip out and replace your existing tools. It sits on top of your stack, connects via integrations, and runs agents that act across systems.

This matters because most procurement functions are an accumulation of systems bought at different stages by different leaders. A platform that demands you consolidate before you can use it is asking you to do another year of replatforming first. A vendor-agnostic platform lets you start now, where you are.

Three reasons I see most often.

One: the pilot ran against a process that wasn’t actually documented. The AI produced inconsistent output because the function it was running in was inconsistent. The team blamed the AI.

Two: the pilot was a single workflow in isolation. The gain was real but capped. There was no path to scaling it across the lifecycle.

Three: no plan for what happens after the pilot. The pilot succeeded, the team moved on, no one operationalised it. The pilot quietly died.

The teams that scale do the thinking work before the pilot. They document the process. They define the criteria. They pick a workflow that can hand off to another agent later. The pilot is a step in a plan, not a check-the-box on an innovation roadmap.

Daniel Barnes is a procurement practitioner with ten years of operational experience and more than fifty AI agents deployed in production. He writes World of Procurement, a Substack and YouTube publication on the future of procurement work, read by 18,000+ procurement, legal, and operations leaders across the globe.