The deciding variable was framing rather than tooling, because the capability was identical across teams that adopted fast and teams that resisted quietly
A procurement leader introducing AI is not running a technology project. They are running a change program in a function whose skepticism is earned.
Prepared by Redress Compliance · August 19, 2026 · Procurement AI adoptions. 15 to 20 teams supported, 2024 and 2025.
Executive summary
Teams told the technology would replace analysts resisted it quietly and thoroughly. Teams told it would return their worst hours adopted it fast and expanded it themselves.
The fastest adoption started with background jobs and inbox agents, which delivered value without asking anybody to change how they worked.
The senior analysts who feared replacement became the strongest advocates once they saw the tool take the tasks they hated rather than the judgment they valued.
Every stalled adoption measured success by license activity. None measured coverage or returned hours, so none could show the team what was working.
What does this actually change for a team?
Less than the hype claims and more than the skeptics fear. It does not replace the function; it moves the function up the value chain, from producing analysis to directing it.
The skill shift is a promotion in disguise
Buyers stop being producers of benchmarks, briefs and invoice checks and become editors of drafts and owners of the decisions those drafts support. The analyst who spent Friday building a benchmark deck now reviews one and spends Friday on the negotiation strategy it informs.
The asymmetry that is closing
The buyer side finally has the memory and evidence the vendor side always had. Account teams run on a deal desk and a customer record, and vendors ship this technology to their own sellers, from the productivity assistants to the sales agent platforms. Standing still is not neutral.
What should be automated first, and what stays human?
Two rules set the sequence. Automate where the work is worst and the risk is lowest first, and keep human anything that commits the organization or depends on relationship judgment.
| Task | Automate or human | Why | Where it sits in the sequence |
|---|---|---|---|
| Benchmark preparation | Automate | High volume, evidence based, no judgment in the production | First |
| Invoice reconciliation | Automate | Repetitive, rules based, and nobody wants to do it | First |
| Renewal alerts and first reads | Automate | Calendar and extraction work machines do better | First |
| Contract term extraction | Automate with human confirmation | The tool proposes, a person confirms the money fields | Second |
| Negotiation mandate | Human | Requires business judgment and internal alignment | Never |
| Vendor relationship | Human | Trust and escalation are person to person | Never |
| Final concession and signature | Human | Commits the organization; authority must be bounded | Never |
Start with the worst work
The politically smart first target is the low value, high volume work nobody defends: invoice checking, renewal calendars, first reads of inbound proposals. Automating it produces immediate relief and zero resistance.
That relief is the credibility you spend later
No analyst protects the tasks they dread, so the first win costs nothing politically. It is what buys permission for the harder changes afterwards.
The procurement platform buyer guide
What coverage a platform actually gives, where judgment still belongs to people, and how the two hand off.
Read the guide →What 15 to 20 procurement adoptions showed
Across the 15 to 20 procurement teams Morten Andersen helped adopt this technology in 2024 and 2025, the deciding variable was framing, not tooling. Three findings recur.
- The fastest adoption started with background jobs and inbox agents, which delivered value without asking anyone to change how they worked.
- The senior analysts who feared replacement became the strongest advocates once they saw the tool take the tasks they hated, not the judgment they valued.
- Every stalled adoption measured success by license activity, and none measured coverage or returned hours.
Teams told the technology would replace analysts resisted it quietly and thoroughly. Teams told it would return their worst hours expanded it themselves. The capability was identical.
- Your agreements decoded into plain English before the auditor interprets them for you
- Duplicate tools and unused capacity surfaced across the portfolio
- A ranked savings queue with dollar values, not license counts
How do you bring the team with you?
Adoption is a trust sequence, not a training event. Four moves decide whether the team leans in or waits it out.
The four moves in order
- Name the fear directly: say out loud that this returns capacity and does not cut the team, then prove it by pointing the tool at the worst tasks first.
- Meet the team where they work: inbox agents and alerts in existing systems get adopted; a new portal login is a tax the team refuses to pay.
- Make the senior analyst the owner: the person most threatened becomes the strongest advocate once they own the rollout.
- Show the returned hours: publish what came back and what the team did with it.
Adoption follows the interface
Where the work already happens is where the tool has to appear. A separate destination is a change request dressed as a feature, and teams decline it without saying so.
A team trusts a tool it understands
Governance standards give the plain language for how outputs are grounded and where the human stays in control, from the risk management framework to vendor technical documentation.
What should be measured, and what should not?
Coverage and returned hours. Not license activity, which is the metric every stalled adoption in the file was using.
Why license activity fails as a measure
It counts logins rather than outcomes, so it cannot distinguish a team using the tool well from a team opening it out of obligation. Nothing in that number tells anyone what is working.
What returned hours prove
At maturity the adoptions supported returned roughly 40 analyst hours a month. Publishing where those hours went, and what the team did with them, is the story that sustains the change past the first quarter.
The instrument side of the decision sits in the platform against advisory brief and the executive frame in the CIO guide.
Where the common advice on adoption is wrong
The common advice is to run this as a technology rollout: select the tool, train the team, measure the licenses. We disagree.
The skepticism is earned and the fear is the variable
This is a change program in a function that has watched two decades of tools promise transformation and deliver dashboards. The fear underneath the skepticism, that this time the tool replaces the person, is what actually decides the outcome.
The buyer side move is to name the fear, start with the work nobody defends, give the rollout to the person most threatened by it, and measure returned hours rather than logins. The agent level view sits in the procurement agents reference.
What the adoptions measured, 2024 and 2025
Two findings, and the second explains why the first kept happening.
Published back to the team along with what that capacity was spent on, which is the story that sustained the change.
The capability was identical across teams that adopted fast and teams that resisted; only what they were told about it differed.
Neither is a product feature. Both are decisions the procurement leader makes before the tool is switched on.
Your first five moves
- Name the fear directly before the first demo, because teams told this would replace analysts resisted it quietly and teams told otherwise expanded it themselves.
- Point the tool at the work nobody defends first, since invoice checking, renewal calendars and first reads produce relief and zero resistance.
- Put it where the team already works, because inbox agents and alerts get adopted and a new portal login is a tax the team declines to pay.
- Give the rollout to the senior analyst most threatened by it, who becomes the strongest advocate once they see it take drudgery rather than judgment.
- Measure coverage and returned hours, never license activity. The procurement practice runs the framing before the tooling decision, which is the order that decides it.
Frequently asked questions
What decides whether adoption works?
Framing rather than tooling. The capability was identical across teams that adopted fast and teams that resisted; only what they were told about it differed.
What does this change for the team?
It moves the function from producing analysis to directing it. Buyers become editors of drafts and owners of the decisions those drafts support.
Is that a demotion?
It is a promotion in disguise, and framing it as one is most of the adoption battle. The production work leaves and the judgment work stays.
What should be automated first?
Benchmark preparation, invoice reconciliation, and renewal alerts and first reads. High volume, evidence based work with no judgment in the production.
What must stay human?
The negotiation mandate, the vendor relationship, and the final concession and signature. Anything that commits the organization or depends on relationship judgment.
Why start with the worst work?
Because no analyst protects the tasks they dread, so it produces immediate relief and zero resistance. That relief is the credibility you spend on harder changes later.
Where should the tool appear?
Where the work already happens. Inbox agents and alerts in existing systems get adopted; a new portal login is a tax the team will refuse to pay.
Who should own the rollout?
The senior analyst most threatened by it. They become the strongest advocate once they see the tool take drudgery rather than the judgment they value.
What should be measured?
Coverage and returned hours. Every stalled adoption reviewed measured license activity instead, so none could show the team what was working.
How much time comes back?
Roughly 40 analyst hours a month at maturity. Publishing where those hours went is what sustains the change past the first quarter.