Most AI operations projects fail in the first month, and predictably. They fail because the team started building before establishing what "better" would look like, or because they picked a problem too large to finish.

Here is the plan that works.

Week 1 — Measure the thing you are about to change

Do not build anything. Pick one workflow and instrument it.

How many times does this happen per week? How long does each instance take, end to end, including the waiting? Who does it? What percentage requires an exception? What is the error rate today — and be honest, because the current process is not perfect either.

This baseline is the entire foundation of the project. Without it, you will finish in six weeks with a system that feels faster and no way to demonstrate it, which is how pilots quietly die.

Week 2 — Shadow, do not act

Build the smallest version that processes real inputs and produces real outputs — and does nothing with them. Every output goes into a review file that a person grades against what actually happened.

Two things come out of this week. First, real accuracy against real inputs, which is always lower than accuracy against test cases. Second, the actual distribution of inputs, which is always messier than anyone expected.

Resist the urge to skip this week. It is the cheapest place to discover that your input assumptions were wrong.

Week 3 — Build the exception path first

Before improving accuracy on the standard case, decide what happens when the system is unsure.

Where does the low-confidence case go? Who sees it? How quickly? What does the person see when they open it — the draft, the reasoning, the sources?

Teams that build the happy path first and the exception path later end up with an exception path that is an afterthought, and the exception path is where user trust is actually determined.

Week 4 — Go live, narrow

Turn it on for one team, one location or one category. Not the whole business. With the gate in place, with the exception path working, with per-request cost and latency instrumented.

Then watch the number that matters: the human edit rate at the approval gate. High edit rates mean the output is not good enough yet, regardless of what your accuracy testing said. Low edit rates with high volume mean you are ready to expand.

What to report at day 30

Against your week-one baseline: time per instance, volume handled, exception rate, edit rate, cost per instance, and errors compared to the previous process.

Report honestly, including where it underperformed. A pilot that produced a 40% improvement and a clear list of what did not work is a successful pilot. A pilot that produced enthusiasm and no numbers is not, and it will not survive contact with a budget conversation.

The four mistakes

Starting with the hardest workflow. The most painful process is usually painful because it is genuinely complex. Start with something high-volume and mechanical.

Skipping the baseline. Guaranteed to make the results unarguable in the wrong direction.

Launching broadly. A narrow launch that works expands easily. A broad launch that has problems damages trust across the whole organization at once.

Optimizing the model before the workflow. If nobody has decided who reviews the output and what happens next, prompt tuning is premature.

What month two looks like

If month one went well, month two is not a new workflow. It is deepening this one — reducing the exception rate, loosening the gate where evidence supports it, and connecting the corrections back into the system.

The temptation is to sprint to the next use case. The compounding value is in making the first one genuinely excellent, because that is what convinces the organization the second one is worth doing.