What 90 Days of Fractional AI Ops Actually Looks Like

Most AI projects don't fail during the build. They fail after it.

The demo works. Everyone claps. The vendor sends a final invoice and disappears. And ninety days later the system that was supposed to change how the business runs is a tab nobody opens, full of stale data, quietly rotting while the team drifts back to the spreadsheet they trusted all along. Nobody decided to abandon it. It just never became theirs.

I've watched this happen enough times that I built my whole delivery model around preventing it. In our methodology the build phase has a name, but so does the part everyone else treats as an afterthought: the handoff. That's the phase where a system stops being ours and becomes the customer's. It's also where I think the real work of AI operations actually lives.

So let me walk through it honestly. Here's what the first ninety days after go-live actually look like when you do the handoff on purpose.

Day 0: the system is live, and that's the easy part

Go-live is a milestone, not a finish line. On day zero the system is deployed, running on real data, and a couple of people on the team have used it in a controlled way. That's genuinely something. It's also the most fragile the system will ever be, because right now it works because we're watching it.

The goal of the next ninety days is to remove us from that sentence. To get to a place where it works because the customer's team is running it, understands it, and trusts it. Everything below is in service of that one transition.

Weeks 1–2: write it down so it survives you

The first thing we do after go-live is unglamorous: we write the system down.

Every deployed system accumulates knowledge that lives in the builder's head — why a field is set up that way, what to do when an integration hiccups, how to add a new user, what "normal" looks like versus "something's wrong." If that knowledge stays in my head, the customer is renting their own operations from me forever. That's a bad deal for them and, honestly, a trap for me.

So we produce two things. Standard operating procedures — the short, specific "here's how you do the recurring task" documents for the people who use the system daily. And a runbook — the "here's what to do when something breaks" document for whoever owns it. Not a 200-page manual nobody reads. The three or four pages that actually matter, written for the person who'll be holding it at 4pm on a Friday when something looks off.

Weeks 2–4: train the operators, not the executives

Then we train the people who'll actually run it. And I mean the operators, not the person who signed the check.

This is a distinction a lot of vendors get wrong. The executive bought the system; the coordinator, the estimator, the office manager is going to live in it. If you train the buyer and not the user, adoption dies quietly the moment the buyer's attention moves on. So training is hands-on, with the real people, on their real work — not a webinar, not a recorded walkthrough. They do the task themselves, with me next to them, until it's boring. Boring is the goal. Boring means it's theirs.

Somewhere in here there's usually a wobble. A week or two where the team is doing the new thing and the old thing at once, not trusting the system yet, and it feels slower than before. That's normal and I tell them it's coming, because a team that expects the dip doesn't panic and abandon ship in the middle of it.

Weeks 3–6: the tuning window

The first month after go-live, the system is watched closely and tuned against reality. This is the window where the difference between a demo and a product shows up.

Real data is messier than test data. Real users ask things the design didn't anticipate. Edge cases surface — the weird job type, the client whose name breaks the parser, the workflow that has an exception nobody mentioned in scoping. During the tuning window we're monitoring what the system does, catching where it's wrong or uncertain, and adjusting. Not rebuilding — tuning. Tightening the thing that already works so it holds up under the full, messy weight of the actual business.

The discipline that matters here is regression: a fix for one problem can't quietly break two others. So changes get checked against what already worked before they ship. A system that improves in one place and degrades in two isn't improving. This is the unglamorous engineering that separates something you can trust from something that merely demoed well.

Days 30–90: the monthly rhythm

Once the tuning window closes, the relationship settles into a rhythm. Not daily firefighting — a predictable monthly cadence:

An optimization review. Once a month we look at what the system is doing, where the friction is, and what small improvement would matter most. One or two things, done well, not a wishlist.

A data-quality check. AI systems live or die on the data feeding them, and data quality decays silently — a field stops getting filled, an integration drifts, a source goes stale. We check it on a schedule so the decay gets caught early instead of discovered during a crisis.

Small additions. The team, now fluent, starts seeing the next thing. "Could it also do this?" Small, bounded additions that compound on the infrastructure that's already there. This is where the leverage stacks up — each addition is cheap because the foundation exists.

That's the shape of it. Increasingly, the customer runs the monthly rhythm and I'm just there for the harder calls.

The goal state no vendor likes to say

Here's the part that's bad for business to admit and true anyway: the goal is for the customer to run it without me.

A vendor whose incentive is to be indispensable will build systems that need them forever — undocumented, opaque, dependent. That's not partnership, it's a leash, and small-business owners can feel it even when they can't name it. My incentive is the opposite. I want the handoff to be so clean that ninety days out, the system is genuinely theirs: documented, understood, owned by their own people, improving on a rhythm they control. If they want us around after that, it should be because we keep earning it — not because leaving would break something.

That's what fractional AI operations is actually supposed to buy you. Not a dependency. A capability you keep.

How to tell if a vendor is building for the handoff

Since the handoff is where these projects live or die, it's worth knowing how to spot whether a vendor is even planning for it — ideally before you sign, not ninety days in when it's too late.

Ask three things. First: what documentation do I get, and who is it written for? If the answer is a vague "we'll provide docs," push. You want SOPs for your daily users and a runbook for your owner, and you want to hear that distinction come back at you unprompted. Second: who, specifically, on my team will you train, and how? A vendor who plans to train "your staff" via a recorded video is not planning for a real handoff. One who asks which of your people will run this day to day is. Third — the honest one — what does month four look like, and what happens if I don't renew whatever you're offering after that? A vendor building for ownership will describe a system you keep running without them. A vendor building for dependency will get cagey, because the cageyness is the business model.

The answers tell you almost everything. Anyone can build the thing. The question is whether they're building it to leave in your hands or to keep in theirs. The whole ninety days I've described only happens on purpose — so make sure it's on the vendor's mind before it's on your invoice.

If you've been burned by a system that showed up impressive and left you stranded, let's talk about what a real handoff looks like.