A tool went in a year ago. It worked. Customer service uses it every day, or finance does, or sales does: pick the team. And a year later it is still running inside that one team, doing the same job it did in month one, while every other function in the company runs the way it always has. Nobody killed the project. It just never left the room it started in.
At a small business this rarely happens, because there is no room to leave; one person usually owns the whole problem and the whole budget. At a large enterprise it rarely happens either, because a formal rollout process already exists to carry a pilot from one team to the next. It is a mid-sized company's specific failure mode: big enough to have real departmental boundaries, not yet big enough to have a process for crossing them.
The tool was never the problem
The instinct is to blame the software, or the team that "didn't push hard enough" to spread it. Both explanations are usually wrong, and both are convenient because they put the problem somewhere other than the handoffs between departments.
A pilot that works inside one team almost always improved a single step: the enquiry gets logged faster, the invoice gets matched automatically, the ticket gets routed on its own. What it did not change is what happens on either side of that step. The work still arrives by hand from the team before it, and still leaves by hand toward the team after it. The pilot got faster; the chain around it did not get shorter. Spreading a working pilot is an integration and an organizational question, not a referendum on whether the tool was any good.
The real chain crosses desks the pilot never touched
A single workflow inside one team is worth something. A chain that runs from the first enquiry to the money landing is worth a great deal more, and it is also the harder thing to build, because it crosses 4 functions that each own one piece of it: marketing owns the enquiry, sales owns the qualification, operations owns delivery, and finance owns the invoice. Every handoff between them is a place where information gets retyped, delayed, or quietly lost, and every one of them sits between two managers with different targets and different weeks, neither of whom asked to be part of someone else's automation project.
That is why the chains most worth automating at this size are usually the ones with the most handoffs and the least documentation: enquiry to invoice, order to delivery, hire to first day. Where a chain touches finance and accounting specifically is its own question, covered on automate finance and accounting; where it touches sales and the CRM, on automate sales and your CRM; the back-office and reporting side on automate your back office; and customer-facing work on automate customer service. The technical work of joining two systems is usually the easy half. Getting two function heads to agree what "qualified" or "done" means is the other half, and it is the half that decides whether a pilot spreads or stalls.
The org chart is the actual obstacle, not the tooling
At a small business, the person with the problem, the budget, and the authority to say yes is one person, so a decision is a conversation. At a large enterprise, that authority sits with a steering committee that already knows how to sponsor a company-wide program. A mid-sized company sits in the gap between those two shapes: there are enough people that no single one of them can say yes for the whole company, but no committee exists yet to say yes on everyone's behalf.
The way past that gap is not a bigger kickoff meeting. It is starting inside one function, with one head who has a budget line and a broken process, and producing a first result specific enough that a peer in another function believes it and asks for the same thing, rather than trying to get buy-in from three departments before anything has shipped. Sequence follows the org chart before it follows the process map: the highest-value chain to automate is often not the first one to attempt, because it crosses a boundary nobody has agreed to cross yet, and a pilot that tries to cross that boundary on day one usually stalls there instead of inside a single team.
What makes the second team believe the first team's result
The reason a working pilot fails to spread is often that nobody outside the team that built it can verify it actually worked. A slide with a percentage on it does not travel between departments that do not trust each other's numbers. What travels is a baseline the receiving team's own finance function set and signed off on before anything was built, and a result measured the same way afterward by the same independent party. That is a structural point about how a mid-sized company is organized, not a claim about what any one program achieved; the full detail on how that measurement and the pay structure behind it work is on how you pay: a share of the profit AI makes.
None of this needs a steering committee to get started. It needs one function head with a broken process and a genuine handoff worth fixing. What that looks like specifically for a company already carrying a CRM, an ERP, and a help desk it does not want to replace is covered on AI automation for mid-sized companies, and the sequence a first engagement actually runs in is on how AI implementation works, step by step. Getting the sequencing itself right before any tool is chosen is the work of AI implementation consulting; getting the org chart's incentives to actually cooperate across that boundary is AI change management, and doing this across the whole operating model rather than one chain at a time is digital transformation.