Building an AI Operating System for Mid-Market: A 22-Week Rebuild at a $410M Commercial Equipment Distributor
By Ed Hitchcock, Enterprise AI Systems Architect, SupplyTech Solutions
An AI operating system for mid-market is not a platform you buy. It is an organizing principle that decides which systems own which decisions, where knowledge lives, and where AI is allowed to help. This case study walks through a 22-week build at a $410M commercial equipment distributor where we rebuilt the operating backbone on M365 first, added three domain systems on top, exposed a customer-facing portal underneath, and only then layered two AI agents into specific roles with named guardrails. The order matters. AI added to a fragmented operating environment amplifies the fragmentation. AI added to a coherent operating system compounds the coherence.
The Distributor and What "Fragmented" Actually Meant
The client is a commercial equipment distributor in the Southeast, about $410M annual revenue across twelve branches, roughly 380 employees, serving foodservice operators, hospitality groups, healthcare facilities, and light industrial. They carry about 47,000 SKUs across kitchen equipment, commercial refrigeration, laundry systems, and parts. Their ERP is a legacy on-prem instance of Infor SX.e running against a SQL Server database that IT was afraid to touch. Sales lived in a five-year-old HubSpot instance. Service dispatch ran out of a homegrown Access application. Field techs used a mix of paper forms and iPad photos emailed back to a shared inbox. The controller reconciled everything into QuickBooks Enterprise every Friday.
"Fragmented" here did not mean bad data. The data was fine inside each system. Fragmented meant that no one on the executive team could answer three questions without pulling four spreadsheets: margin on Class 8 refrigeration this quarter, customers late on service contracts they still pay for, and time from field visit to invoice on emergency calls. Every crossing was a person doing a job that a coherent operating system would do on its own.
The CFO had tried the platform route. Two years earlier they signed a $470K per year contract with a mid-market ERP replacement vendor. Migration stalled at month 9 and they walked away paying a $180K cancellation. What they wanted from us was not another migration. They wanted an operating system that respected the existing ERP, CRM, and controller's process, and made the crossings between them stop being manual.
What We Built: The Operating System First, AI Second
The frame borrowed from a systems architecture we built for a non-distribution client the year before. Modular operating system on M365 as the backbone. Three domain systems above it. One customer-facing portal below. AI as a support layer across the top, added last and only where the underlying data model could hold it up. 22 weeks. Fixed hourly. Handoff to a named Operations Lead by week 21.
The backbone is a SharePoint hub site with strict information architecture: one subsite per domain, one document library per business process inside each subsite, one Power BI workspace per domain reading from a shared Azure SQL analytical layer. Nothing exotic. What made it different from the prior state: the architecture was written down, versioned, and enforced. If a process did not fit the architecture, we redesigned the process before we automated it.
The three domain systems above the backbone are Customer Acquisition and Contracts, Central Administration, and Service Delivery. Each is standardized on the same Microsoft stack (SharePoint subsite, Forms, Power Automate, Power BI) so a Citizen Dev on the internal team can extend any of them without learning a new environment. Below the backbone we built a customer-facing portal in Power Apps on Dataverse, exposing account details, invoices, open service tickets, and contract status. The customer never touches SharePoint. Internal complexity, external simplicity.
Customer Acquisition and Contracts (Domain 1)
This is the growth engine: prospect capture, qualification, quote generation, contract renewal tracking. HubSpot stays as the top of funnel. Power Automate flows sync qualified prospects into SharePoint deal rooms where the internal team assembles quotes against real Infor SX.e pricing pulled nightly into the Azure SQL analytical layer. Renewal tracking, previously five spreadsheets one contracts manager rebuilt on Wednesdays, moved into a SharePoint list with automated 90-60-30-day alerts routed through Teams to the assigned account manager.
Quote turnaround on standard commercial refrigeration bundles dropped from an average of 2.8 business days to about 5 hours. Contract renewal miss rate (renewals that lapsed and had to be re-sold at higher acquisition cost) dropped from an internal estimate of 14% to about 4% in the first quarter of steady operation. The contracts manager stopped rebuilding spreadsheets.
Central Administration (Domain 2)
This is finance, knowledge management, and facilities. The controller's Friday reconciliation between Infor SX.e and QuickBooks Enterprise was the highest-value automation in the whole engagement. Power Automate flows now stage the reconciliation nightly into a SharePoint list, flag exceptions above configurable thresholds, and hand her a Monday review queue instead of a full Friday rebuild. Her weekly close time dropped from roughly 11 hours to about 3.
Knowledge management got its own SharePoint subsite with a strict document taxonomy: policies, SOPs, vendor contracts, warranty terms, and internal how-to guides. Every existing document that survived the audit was tagged with an owner and a review date. Everything else was retired. This is unglamorous work. It is also the precondition for the AI knowledge agent that came later. An LLM implementation grounded in a badly organized document library produces confidently wrong answers. An LLM implementation grounded in a taxonomy someone owns produces answers you can defend.
Service Delivery (Domain 3)
This is dispatch, field service, and invoicing. The homegrown Access application was retired. Dispatch moved to a Power App backed by Dataverse, integrated to the ERP for parts availability and to the customer portal for status. Field techs got a Power Apps mobile form that captures the visit report, photos, parts used, and the customer signature. The invoice draft is generated automatically and lands in the controller's queue by end of day, not end of week. Median time from service completion to invoice sent dropped from 9 days to about 36 hours.
The AI Support Layer Sat on Top of the Operating System, Not Underneath It
Two AI agents went live in the final six weeks. Both were scoped narrowly and both had explicit guardrails written into their system prompts and reviewed by the Operations Lead before go-live.
The first is an internal knowledge agent for staff, built on Azure AI Search over the curated SharePoint document library, using GPT-4o via Azure OpenAI. It answers questions like "how do we handle a warranty claim on a leased ice machine" or "what is our standard net-30 exception process for hospitality groups". It cites the source document on every answer. If the answer is not in the library, it says so and offers to route the question to a named human owner. Adoption was fast because the answers were traceable. Weekly usage sits at roughly 340 authenticated queries across 62 staff users after 60 days live.
The second is a product-lookup and specification agent grounded in the manufacturer specification library, the internal parts compatibility matrix, and the current pricing view from Infor SX.e. Inside sales reps use it when a customer calls asking for a replacement part or a spec-match on a piece of equipment that came in used. It surfaces the correct part number, the compatible SKUs, and the current price, and formats a quote-ready line item. The rep still confirms the recommendation. Median call-to-quote time on parts inquiries dropped from about 22 minutes to about 6.
We refused two AI proposals mid-engagement. The COO asked for an AI dispatch optimizer that would auto-assign field techs to service calls. We said not yet. The dispatch data was three weeks old, the service radius rules were tribal knowledge held by two dispatchers, and an optimizer trained on that state would learn the wrong lessons and be hard to correct. We told him we would revisit it in Q3 next year after six months of clean dispatch data through the new Power App. He accepted. The CFO asked for a customer-facing chatbot in the portal. We said no. Their customers wanted a human on the phone for anything involving a piece of equipment that costs $40,000 to $180,000. A chatbot in the portal would have signaled the wrong thing about how the company sold.
Guardrails, Written Down
Both AI agents share a written guardrail policy that lives in the same knowledge library the internal agent reads from. No autonomous decisions on pricing, credit, or contract terms. No answers on questions the source library does not cover. Every answer surfaces its source document and the last-reviewed date. Human oversight on any answer that leads to a customer-facing action. Church-controlled equivalent for a distributor: distributor-controlled knowledge, not vendor-hosted.
Writing guardrails down is the piece most AI implementation consulting engagements skip. It is also the piece that gives an internal team the confidence to extend the agents themselves after handoff. When the Operations Lead added a third agent in month four post-handoff, a returns triage helper for the service team, she pulled the guardrail template from the library and adapted it.
The Architecture at a Glance
L1 Data Platform: Azure SQL analytical layer, nightly Infor SX.e extract, QuickBooks connector, Power BI on three domain workspaces. Owner: IT Director.
L2 Operating Backbone: SharePoint hub site, one subsite per domain, curated document taxonomy, versioned information architecture. Owner: Operations Lead.
L3 Domain Systems: three Power App front ends (Contracts, Reconciliation Queue, Dispatch), five Power Automate flows across the domains, HubSpot connector, Dataverse for the customer portal. Owner: Operations Lead plus one Citizen Dev.
L4 AI Support Layer: Azure AI Search over the curated library, GPT-4o via Azure OpenAI for both agents, written guardrail policy, source citation on every response. Owner: Operations Lead.
Everything runs inside the client Azure tenant. Incremental Azure and OpenAI consumption sits at roughly $2,850 per month at current volumes. Zero net-new SaaS licenses. HubSpot, Infor SX.e, and QuickBooks Enterprise all kept.
What Changed at 90 Days Post-Handoff
Weekly close time: 11 hrs to about 3 hrs. Quote turnaround on standard bundles: 2.8 days to about 5 hrs. Contract renewal miss rate: ~14% to ~4%. Time from service completion to invoice sent: 9 days to about 36 hrs. Parts-inquiry call-to-quote median: 22 min to about 6 min. Knowledge agent weekly usage: ~340 queries across 62 staff after 60 days. The Operations Lead has since built one net-new agent (returns triage) without our involvement, which is the actual measure of whether an AI operating system for mid-market has taken hold.
When an AI Operating System for Mid-Market Fits
This frame fits distributors, manufacturers, and industrial services companies in the $150M to $600M range with a working ERP they do not want to replace, an existing Microsoft footprint, and one internal person who can be trained as the ongoing owner. It does not fit companies below $100M because volume does not justify the domain build cost. It does not fit companies committed to ripping and replacing the ERP, because the sequence is different when the ERP is in motion. It also does not fit companies where AI is expected to arrive before the operating system does. The order is backbone, domains, portal, agents. Every time.
Comments