Replacing a CEO-run spreadsheet process with an automated shipping operating system

The situation

A multi-location, founder-led specialty healthcare provider had stood up a new shipping operation: kits go out to patients, and patients ship them back. The CEO had built it over about six months, and it worked.

That was the problem. It worked because the CEO was personally holding it together, and running it was manual and painful. Every cycle depended on their attention, which meant the ceiling on volume was the CEO's calendar. Any real growth would have needed either more of their week or a second person trained to think exactly like them.

The CEO had also tried to automate it themselves, and put in around twenty hours before the engagement without getting to something usable.

The real constraint

The shipping process had no operating system behind it. Intake, fulfillment, return tracking, and exceptions all depended on spreadsheets and individual attention.

That distinction mattered for what we built. This was not a case of one bad spreadsheet that needed replacing with a better spreadsheet. There was no underlying system that held the rules, moved work forward, or surfaced the things that needed a human decision. Every part of the process was reconstructed by hand, every cycle.

What we built

We built a shipping operating system covering the full path: kits out to patients, kits back, and everything in between. It brought the moving parts into one place with real data flow between them instead of manual handoffs, added a dedicated shipping software layer, and documented how the process actually runs.

Rather than replacing the organization's existing systems, I connected and extended tools it already used. The operating system runs on Microsoft 365: SharePoint holds the operational records, Power Automate moves the work forward, and the AI agent is built in Copilot Studio. A production Azure Functions integration with EasyPost brings carrier tracking events into those records automatically, so shipment status stays current without anyone checking a carrier's website.

Every shipment is planned and coordinated from one central record. Status changes are validated, duplicates are blocked before they are created, and overdue items and missing returns surface in exception views that show which ones need follow-up.

Automation handles the routine cases so they move on their own. The team has visibility into the data, so anyone can see the state of a shipment without asking the CEO. The rules that used to live in the CEO's head are now encoded in the system, and the cases that genuinely need judgment surface as exceptions rather than arriving as a weekly pile of work to sort through.

On top of all of it sits an AI agent the team runs the operation through. They can create patient records, start shipments, and update operational data just by asking it, with no digging through screens or spreadsheets. The agent watches the system continuously, flags data exceptions and shipment issues, and tells the team what needs attention and what to do about it. The work that used to require the CEO's judgment now surfaces on its own, with a recommended next step attached.

The result

The weekly process no longer depends on the CEO. What took four hours of hands-on work every week became about fifteen minutes of oversight, about 94% less, and the operating team got six to ten hours a week back on top of that.

The system was built to carry roughly three times current volume without adding headcount. That is the capacity it was designed for, not a level it has been run at yet.

The time savings got them started. The better data is what changed how they run. In the CEO's words:

"We're not only saving time by automating. We're now receiving data automatically that would have been too costly to obtain manually. It's a better process that gives us more insight into our operations."

What the CEO valued most went beyond the numbers. The cost savings were real, but the bigger shift was no longer having to watch the process closely or carry it in his head. That peace of mind, he told me, made the biggest difference.

Expanding into operational intelligence

Once the operation ran on its own, the next question was whether leadership could see how the organization was performing. I built a functional prototype of a performance dashboard for the same client, organized around the decisions its leaders make: operational performance, productivity, goals and pacing, and trends over time, with each role seeing the view that fits its job.

The two are at different stages. The shipping operating system is in production. The dashboard is a working prototype that has not been connected to production systems, and it has no measured results yet.

What happened next

The engagement is expanding into patient-scheduling alerts and financial-operations reporting.

This is the pattern the whole practice runs on. Land on one specific problem, deliver something that works, and let the next piece of work be earned rather than sold. The second and third projects came from the first one being right, not from a proposal.