Copilot for Mid-Market: How We Ran Three Parallel Workstreams Across a $295M Industrial Parts Distributor
By Ed Hitchcock, Enterprise AI Systems Architect, SupplyTech Solutions
Most Copilot for mid-market rollouts we inherit look the same. Someone bought M365 Copilot licenses for the whole company, sent a getting-started email, and expected productivity. Six months later the licenses show 12 percent active use, IT gets asked why the answers are wrong, and someone drafts a memo about pausing the program.
We were brought into a $295M industrial parts distributor last spring after exactly that pattern. Nine branches across the Southeast and mid-Atlantic. Roughly 76,000 SKUs across bearings, hydraulics, power transmission, fluid conveyance, and industrial fasteners. About 310 employees. On-prem S2K ERP customized over eleven years. Two prior Copilot pilots had both stalled inside the first quarter.
This post walks through the six-month plan we ran to get Copilot for mid-market working there. Three parallel workstreams, one department at a time, in a specific order. What we did, what we deferred, what the numbers were at handoff.
Why Copilot for Mid-Market Fails the First Two Times
Before we walk through the plan, the two prior attempts are worth naming, because the failure pattern is the same one we see almost every engagement.
Attempt one was an all-hands Copilot license rollout with a one-hour training webinar. Adoption cratered inside three weeks. The assistant kept surfacing outdated policy documents from a SharePoint site nobody had cleaned up since 2019, and the answers were confidently wrong. Users stopped trusting it.
Attempt two was the opposite mistake. Leadership hired a systems integrator to build a custom shipping-cost optimizer as a Copilot skill. The integrator delivered a working demo, but it hit S2K through an integration that nobody at the distributor could maintain. When the vendor rolled off, the tool went dark inside two months.
Both failures shared one root cause. The Copilot for mid-market conversation was framed as a tool question ("which capability do we buy?") when it was actually three questions running at different clock speeds. Content readiness. Assistant tuning. Custom tooling. Answer them together and you get demos. Answer them in sequence, by department, and you get adoption.
The Three Workstreams We Ran in Parallel
We structured the engagement around three concurrent tracks, each on its own cadence.
The first track was documentation and automation, run by a client-side lead we embedded with early. Its job was to make each department's actual work visible in writing before Copilot ever touched it. Every SharePoint site got the same treatment: current-state process doc, exception list, decision rules written down, then a small batch of Power Automate flows to remove the most repetitive admin.
The second track was SharePoint architecture and Copilot Studio agent tuning. This was where the assistant actually got built, one department scope at a time. Grounded on the cleaned SharePoint content from track one. Answers cited their source doc. No cross-departmental agent until the department-level agents were stable.
The third track was a single custom tool. Not many. One. In this engagement it was a shipping-optimization tool built on Microsoft Fabric with a Power Apps front end and an eventual write-back to S2K. We picked this deliberately because it was the highest-value pain point that Copilot alone could not solve, and because it forced the client team to learn Fabric while we were still on site.
The rule was simple. Every department got all three treatments in order. Documentation first, then SharePoint plus a scoped agent, then, if applicable, connection to the custom tool. No department moved forward until the prior phase was signed off by that department's manager.
The Department Sequence We Actually Ran
Sequence matters more than most Copilot for mid-market rollouts admit. The order we ran, and why:
Month 1 (late March). Discovery and planning for the shipping tool. Documentation and automation kicked off for the "willing" cohort: HR, Accounting, IT/ERP, and leadership. These are the departments where the work is already reasonably structured and where an early adoption win builds credibility. Warehouse participation was limited to one named lead. Credit was invited in but not required.
Month 2 (April). Documentation and automation for HR, Accounting, Customer Service, and IT/S2K completed. Shipping tool moved into back-end build: Fabric tables, ingestion from S2K and .biz sources, Python logic in the Fabric pipeline. On the Copilot Studio side, we scoped the first agent narrowly to Customer Service. Training rollout was deliberately deferred: the parts counters are entering peak season and we do not launch enterprise tooling into peak. That was a client call. We agreed.
Month 3 (May). Deliberately slow month. Shipping tool front-end build (Power Apps) and MVP debug. Copilot Studio side paused for continuity reasons on our end. Every roadmap should bake in a slow month. Teams that pretend otherwise are the ones that miss quarter two.
Month 4 (June). Customer Service and Parts and Service came online across all three tracks. Documentation completed, SharePoint sites restructured, department-scoped agent live, training delivered to the users, not the managers. Shipping tool v2 with full S2K integration went live at two of the nine branches as a pilot.
Month 5 (July). Warehouse came online. This was the hardest department. Existing tribal knowledge was dense, documentation was almost nonexistent, and half the work happens off a keyboard. We scoped the Copilot agent tightly around receiving, put-away, and cycle-count questions. The shipping tool moved into an optimization phase, adding cost and performance tracking with recommended rule tuning surfaced as agent responses.
Month 6 (August). Sales and Marketing came online. The pattern was mechanical by then: documentation, SharePoint cleanup, department-scoped agent, training. The client team we had trained in month one was doing most of the work. We were reviewing outputs and helping with edge cases.
That sequence does not maximize revenue impact in month one. It produces the highest adoption rate at month six. The distinction matters.
The Architecture Under the Copilot Layer
Copilot for mid-market lives or dies on what sits below the chat surface. Here is the stack we landed on.
At the bottom, the systems of record stayed exactly where they were. S2K ERP on-prem. .biz web ordering. A homegrown branch-level Access database for internal dispatch. We did not migrate anything.
Above that we built a Microsoft Fabric layer for structured data that Copilot needed to answer real questions. Fabric tables ingested from S2K nightly, from the .biz platform on a two-hour cadence, and from the Access DB via a scheduled Power Automate export. Python notebooks in Fabric did the joins and enrichment. This layer also fed the shipping-optimization tool.
Above the Fabric layer sat SharePoint Online, restructured by department with a documented content model. Every process doc had an owner, a last-reviewed date, and a superseded-by field. Copilot Studio agents were pointed at scoped SharePoint sites, so an agent for Customer Service could not accidentally pull a policy from HR.
The user layer was three surfaces. Microsoft 365 Copilot for horizontal tasks (email drafting, meeting recaps). Copilot Studio department-scoped agents inside Teams for the vertical, high-stakes questions. The custom shipping Power App for the workflow that needed dedicated UI.
The design constraint we kept coming back to was this: no user should have to know which tool to open. If they open Teams and ask a question, the right agent responds. If they open the shipping app, they get the write-back capability. The routing is invisible.
What We Measured, and What the Numbers Looked Like
Every rollout of this kind gets asked for a number in the executive readout. Our default when the source doc does not have hard figures is to hedge and stay honest.
For the department-scoped Copilot agents by month six, we observed roughly 35 to 45 percent automation coverage of the eligible question volume across the six live departments. That is a range because the numbers vary widely: Customer Service was at the top of the range, Warehouse was at the bottom.
Documented admin time eliminated at the team level, aggregated across Power Automate flows and Copilot deflections, was approximately 12 to 18 hours per week. That is total team hours, not per person. We do not extrapolate to per-person savings because the arithmetic invites bad decisions.
Onboarding time for new customer service reps improved by roughly 15 percent. New hires spent less time interrupting tenured reps because the agent handled the routine departmental questions with cited answers.
The shipping optimization tool, running at two branches in pilot, drove a documented reduction in average shipping cost per line of 6.2 percent against the prior six-month baseline. That number is specific because we had a real baseline. We do not project it to the other seven branches until they run.
Copilot Studio agent adoption reached 71 percent of eligible users active weekly by month six, up from single digits at the start. The number that matters more is that of the users active weekly, 84 percent reported using the agent as their first stop for departmental questions rather than pinging a colleague.
What We Deferred on Purpose
A Copilot for mid-market rollout is judged as much by what you do not build as by what you ship. Three things we explicitly declined this year, and why.
We did not build a cross-departmental orchestrator agent. The department-scoped agents were stable by August, but stringing them together introduces a routing problem we would rather solve in year two with real usage data.
We did not connect the Copilot agents to write back to S2K. Read-only was the ceiling. Any state change still routes through a human. The shipping tool has a write-back path, but it goes through a supervisor-approval queue.
We did not deploy Copilot to the branch counter staff. That population needs a different UX and different guardrails, and forcing a general-purpose assistant on them would have created the same trust collapse the first pilot did.
Each of those decisions is defensible in isolation and even more defensible together. The rule we hold ourselves to: ship what accretes, defer what compounds risk.
The Handoff and What Year Two Looks Like
By the last week of August, day-to-day ownership of the SharePoint sites, Copilot Studio agents, and shipping tool front end sat with one named operations lead and one IT lead on the client side. Our role dropped to monthly check-ins and a Slack channel for edge cases.
Year two, per the closeout memo, includes: extending the shipping tool to the remaining seven branches, adding a cross-departmental agent once the department agents show 90 days of stability, and a small counter-staff pilot with a purpose-built interface. None of that starts before quarter one of next year.
If your Copilot for mid-market conversation is stuck on the license question, that is usually a symptom that the workstreams and the sequence have not been decided. That is the work worth doing first. The licenses are the easy part.
Comments