Ask the accounts payable lead at most mid-market companies where the week goes and you’ll get an answer in under a minute. Invoices that arrive as PDFs and get keyed in by hand. Purchase orders matched line by line. The same three vendors chasing the same payment status every Friday. Nobody in that team needs a consultant to tell them what’s broken.
Now ask the same company what its AI plan is.
Usually you get a different kind of answer. Licenses were bought. There was a demo. A handful of people use it every day and like it. Usage across the rest of the business is flat, and nobody can say what the spend returned. Somewhere above them, the CEO or the board has started asking “what’s our AI plan?” and the honest answer is “we’re still working it out.”
If that’s where you are, you’re not behind. It’s one of the most common places to be. And the reasons it stalls are rarely technical. They’re about where the work started.
Why mid-market is different
A mid-market company has exactly the kind of work AI is good at. Real volume: invoices, orders, service requests, policy questions, the report that gets rebuilt every Monday. Real budget, too.
What it usually doesn’t have is an AI team. No center of excellence, no data science group, nobody whose whole job is figuring out where AI fits. The people who would lead that work are already running finance, service or operations, and their calendars are full.
So AI lands where new technology has always landed: with IT. That’s a sensible place for the platform to live. It’s not a sensible place for the whole effort to live, because IT doesn’t own the AP team’s week.
How it stalls in a mid-market team
We’ve written about the four failure modes we find in AI programs of any size. In a mid-market company with no AI team, they tend to show up in a particular order, and the first one is set before anyone has spoken to the team that does the work.
1. It starts with the tool.
A product is chosen first, and then someone goes looking for a problem it can solve. That’s backwards, and it’s nobody’s fault. Vendors sell tools, and tools are easy to buy. But a tool can’t tell you which work, in which team, it should take on. So the work it ends up doing is rarely the work that costs the most.
2. The business doesn’t own it.
IT should own the platform, security, access and governance. That’s their job, and in our experience they’re good at it. But someone on the business side has to own the outcome: that the AP team’s week actually changes, that the hours go somewhere useful, that the next budget has a case behind it. When adoption is everyone’s job, it’s nobody’s job.
3. There’s no baseline.
If you don’t know how long the work takes today, you can’t prove what AI changed. Every result becomes an opinion. “It feels faster.” “People seem to like it.” That won’t hold up in a renewal conversation with the CFO, and it won’t fund the second project.
4. Pilots never reach production.
A use case gets picked because it’s interesting rather than valuable. Nobody agrees in advance what success looks like, and there’s no point where someone decides go or no-go. The demo works, everyone nods, and then it sits.
Look at those four together and a pattern shows up. None of them is about the technology. Each one is a decision that was made late, or not made at all.
What to do instead
The fix isn’t a bigger plan. It’s a better starting point, and it’s one the business already has.
Start with one team’s problem, not one tool.
Pick the team that’s most stretched. Finance, customer service, HR and operations are the usual places. Then sit with them and watch how the work actually gets done, not how the process document says it gets done.
You’ll find the same kinds of tasks again and again. Data re-keyed from one system into another. Approvals chased by email. Long threads summarized by hand so a manager can catch up. The same five questions answered every day. The same report rebuilt every week. The business already knows these problems. What it usually doesn’t know is whether AI can actually take them on, what it would take to get there, and how to get the team using it. That’s the gap worth closing.
Measure how the work runs today.
Before anyone recommends anything, write down the baseline. How many people do this task? For how many hours a week? How often does it go wrong, and what does fixing it cost?
Observed time beats estimates (why that matters more than minutes saved), so if you can, have the team log a few days of real work. Round down. A conservative number is a believable number, and a believable number is the one that gets the next budget approved.
Rank by value and feasibility, together.
Not every opportunity deserves to go first. Score each one on what the time is worth and how buildable it is with the tools you already own; our scoring method is here. High value and high feasibility is your quick win, and that’s where you start. The high-value, hard-to-build ideas are real, but they’re the second or third project, not the first.
Let IT set the boundaries.
This is where IT’s role changes, and it gets more important, not less. The business decides what problem to solve. IT decides how it’s allowed to run: who can access what, which data the solution can see, how it’s logged and audited, and what has to be true before it touches production.
Concretely, that means a first solution that is built in a test environment, under named accounts IT issues, with only the access the work needs. Permissions get checked before anyone uses it, because the real risk in most Microsoft 365 tenants isn’t the AI. It’s files that were shared too widely years ago. The business innovates; IT keeps it safe and lasting.
Prove it in stages.
Release the first solution to a small group first: the IT and project team, then a few pilot users, then a pre-production group. At each stage, someone on your side decides go or no-go against a threshold you agreed before you started. Then measure it against the baseline for a full month after go-live and report what happened, above or below target.
“Agreed before you started” is the part most teams skip, so it’s worth being specific. Before the first person outside the project team touches it, write down three things: the measure (time per invoice, say, from the same system you used for the baseline), the threshold that counts as success, and who decides. If the threshold is set after the results come in, it isn’t a threshold, it’s a story. A clear no-go is a useful result too. It tells you the idea needs a different approach, or a different team, before you’ve spent a year finding out.
That’s how a pilot becomes something people use, rather than a demo people remember.
A first step you can take this week
You don’t need a program to start. You need one conversation. Ask one team leader three questions.
- What does your team do every week that feels like copy-and-paste?
- Roughly how many people do it, and for how many hours a week?
- If you had that time back, what would you do with it?
The third question matters most. AI pays off when the hours go somewhere useful: a backlog cleared, faster service, growth handled without burning people out. It’s about capacity, not about cutting the team. If the answer to question three is a shrug, pick a different team.
Write the answers down. You now have the start of a baseline, a named owner and a reason to act, which is more than most AI plans have.
Where this goes next
This post is the first of five. Each one takes one part of starting AI from the business side and makes it practical:
- Why AI stalls (this post): start with the problem the team already has.
- Capacity, not headcount: how to put an honest number on an hour, one your finance team can check.
- What an AI Business Analyst actually does: the missing role between the business and IT.
- Getting your Copilot licenses to pay back: mapping the work a license should take on.
- AI governance that keeps up with the business: a few decisions made early, tested in stages.
If you’d like to see where your organization stands before then, our AI readiness self-assessment scores 24 statements across six areas: data, process, technology, people, governance and leadership. Your answers stay in your browser. Take the self-assessment, or see how the AI Value Blueprint works.
CB5 Solutions helps organizations understand the layers of AI, get the most from what they buy, and build an AI program that pays back inside their IT standards. We start every engagement with one business problem and a governance baseline. Let’s pick yours.
Next in the series: Capacity, not headcount, or how to put an honest number on the hours AI gives back.