“Can AI make my supply chain better?”
It's the question every board is asking, and it's being asked with growing impatience: how can AI make my business better? The pressure behind it is real. Most companies are pouring money into AI yet very few feel they're getting much back. In one recent McKinsey survey, 92% of companies planned to increase their existing AI spending, yet just 1% felt they were getting the full value back from it. Plenty of money going in, not much coming out, at least not yet.
You can see how we got here. Most of the first wave of AI spend went into engineering. Teams effectively handed their developers a blank cheque, told them to go for it, and the token meter ran. Now the bills are landing, some of them eye-watering. Salesforce is reported to be spending around $300 million a year on AI tokens for its engineering team alone, which means it needs to be seeing many times that back in return. Boards are starting to ask a blunt question: what did we actually get for this? Spend at that scale should be tied directly to the objectives it's meant to deliver, and to the return you'd expect at that level. Anchor it to a clear outcome and the number is easier to justify, and very probably smaller. Leave it loose and the bill simply arrives, with nothing to measure it against.
In the supply chain, there isn't a shortage of ideas. It's that most teams reach for a use case before they've worked out whether it's the right one. They pick the shiny project and hope the return follows.
Before you ask if AI can help, you need a way to find the use cases that will actually move the needle in your operation. I’ve put together a practical framework for doing exactly that. It'll help you work out where, in your specific business, AI is most likely to make a real difference.
Start with the goal
Teams ask "where can we use AI?" when the far more useful question is "what is the business actually trying to achieve, and what's holding it back?" Begin with the goal your leadership is measured on this year. Is it a higher gross profit margin? Top-line growth? Freeing up working capital? Protecting service as volumes rise, without simply adding people?
That answer is the anchor for everything that follows. If you can't draw a line from a use case back to a number the business genuinely cares about you will always struggle to prove the effectiveness of the project. And it pays to be specific. "Improve efficiency" isn't a goal. "Hold headcount flat while we grow volume 20%" is.
Find the levers that move the goal
Once you know the goal, the next question is which parts of your supply chain most influence it, and why. This is where the framework earns its keep, because the same goal points at very different areas depending on the lever you pull.
If the goal is margin, the areas that move it are the ones quietly leaking cost: freight spend, demurrage and detention, invoice errors, and the mode and routing decisions that add expense without adding value. If the goal is growth, look at service reliability and your ability to scale volume without service slipping or costs running away: whether your plan is actually being met against what was promised, and which carriers can reliably hit the volumes they've contracted to, rather than the ones that look good on paper. If the goal is working capital, the levers are inventory and safety stock, lead-time reliability, and payment terms that match how long product actually takes to land. If the goal is cost-to-serve, look hardest at the manual processing that grows head-for-head with volume.
Working from the goal to the areas, rather than from a tool to a problem, is what stops you optimising something that was never going to matter to the board.
Find where it actually hurts
Now overlay the reality of your own operation. The teams that are best at spotting AI opportunities tend to hunt for three things, and they translate neatly to the supply chain.
The first is repetitive, "low-value" work: the manual tasks nobody values but everybody does, like keying container numbers off emails, chasing milestones across carrier portals, or reconciling invoices line by line. I put "low-value" in quotes deliberately, because automating this work, and turning it into structured workflows and data you can build on, often turns out to be some of the most valuable groundwork you can lay. The second is bottlenecks, where work stalls waiting on a particular skill or a particular person. The third is decisions made in the dark, where your team is going on instinct because the data to decide well isn't to hand or isn’t trusted..
A few starter questions. Where does your team spend the most manual hours, and does that effort scale with volume, so every bit of growth means another hire? Where do mistakes cost you the most when they happen? Where are the big calls being made on gut rather than evidence? A specific one I ask in our discoveries - Do you suffer demurrage and detention, and if so, do you actually understand why?
The answers tell you which of your impact areas is bleeding today, as opposed to which one looks worst on paper.
There's no shortage of examples to draw on. There are now published libraries of well over a thousand real-world AI use cases spanning every function and industry, supply chain included. But don't mistake a long list for a high success rate. Genuine, value-creating wins are still the exception rather than the norm, which is exactly why this matters. Imagination isn't the constraint. Disciplined prioritisation is.
Score them, then start small
Now you can rank. The approach I'd use is the one most serious AI adopters have converged on, an impact versus effort framework: score each candidate on two axes. Impact is how much it moves the goal you started with. Effort is how hard it'll be to deliver, and in supply chain that's driven mostly by how ready your data is.
That gives you four boxes. High impact and low effort are your quick wins: real value, on data you already have, and the best place to start because they build momentum and credibility. High impact and high effort are the transformational bets, worth doing but only with proper planning, and usually better tackled once the quick wins have bought you the goodwill. Low impact and high effort can wait. And it's worth re-scoring every quarter, because as the tooling improves, something that's high-effort today can quietly become a quick win tomorrow.
Here's a simple template you can copy and use.
Effort is fairly intuitive to judge, but impact is harder, because at this stage you're dealing with unknowns. It's tempting to reach for a gut number, and I'd resist it. Better to break impact into three questions you can actually estimate. How big is the prize, even as a rough order of magnitude in dollars? How directly does it move the goal you chose, or is the link indirect? And how often does can it be affected, constantly or once a quarter? A large, direct, frequent prize scores a 5; a small, indirect, occasional one scores a 1. Most sit in between, and that's fine, because you're ranking candidates against each other, not forecasting to the penny.
One caveat though, if you genuinely can't estimate the impact at all, that's usually a sign the data to quantify it doesn't exist yet. That's useful in itself: treat the use case as a bet rather than a quick win, and accept that the first job might simply be capturing the data that would let you size it. Once you've scored everything, anything landing top-left is where to begin.
A false instinct is to aim straight at the biggest, most complex problem, because that's where the largest prize sits. But the size of the prize isn't the same as the odds of success. Match your ambition to how ready your data is, or you'll spend six months learning why the return never came.
Your use cases live and die by data quality
Only now does the feasibility question make sense: is there data to work with, or a realistic way to capture it? AI can only help where information exists in some usable form. For most teams, the honest answer is that it's spread across inboxes, spreadsheets, carrier portals, an ERP and a pile of PDFs, and a lot of it only really lives in people's heads. In our own research across supply chain leaders, that fragmentation was close to universal.
It matters because a use case sitting on data you can already reach is a very different proposition to one you'd have to capture from scratch. It doesn't rule the hard ones out. It just tells you honestly what you're taking on.