What Implementing AI in a $5M Company Actually Looks Like

The order matters more than any individual step, and most of what goes wrong is caused by doing step four before step one.

Step 1: assessment, before anything is chosen

Every operation in the company: how you get customers, how you deliver, how the place runs. For each one, what it costs, whether it can be automated, and what it is worth if it is.

This is written down and handed over. You can build from it with anyone, including without us.

It usually produces one uncomfortable finding. The operation you came in about is third on the list, and the one at the top is the one that has been propped up by the same two people for years.

Step 2: pick a narrow target inside the expensive operation

Not the whole operation. A slice of it that can go live in weeks and shows up in a number you already track.

Quoting is a good example. The first build is rarely all of quoting. It is the standard configurations, and the complex ones stay with a person on purpose.

Step 3: data preparation, the part nobody advertises

This is the largest chunk of the work and the least interesting to describe. Pulling three years of quotes, or two thousand support replies, and finding where documented policy and actual practice disagree.

That disagreement is always there. It is not a failure of your business, it is what happens when a policy written in 2021 meets a customer in 2026. Resolving it is a series of decisions only you can make, and it usually improves the manual process on its own.

Step 4: build

The shortest phase, and the one everyone imagines is the whole project. Models are selected for the work and trained on your material, escalation rules are wired in, and it connects to the systems the operation already touches.

Where existing tools work, they stay. Rewriting a connection that already works is a line on your invoice and nothing on your P&L.

Step 5: testing against real historical cases

Not synthetic examples. The last two hundred real cases, where the correct answer is already known because your team produced it.

Two things come out of this. A measurable agreement rate, and a list of case types the system should not handle, which becomes the escalation rules.

Step 6: handover to a named person

One person in your company owns it. They watch it run on live work, they see where it is corrected, and they learn how to change it.

This is where the project either lands or does not, and the not is never announced. A system nobody is named on will not last, and how good it was on day one has nothing to do with it.

Step 7: the week everyone stops working around it

There is a specific week, usually two or three after go-live, where the team stops double-checking every output.

Before that week the system is a cost. After it, the number moves. If it never arrives, something is wrong with the system or with the training, and either way the work is not finished.

Where it goes wrong, in order of frequency

1. The wrong target, chosen before any assessment, attached to a cost that was never the problem
2. No named owner, so it decays after handover
3. Trained on published documentation instead of what your team actually does
4. No escalation rules, so one bad output destroys trust permanently
5. Scope too wide, so nothing is live for a quarter and momentum dies

Four of the five have nothing to do with the technology. That has been true of every project we have run.

What the timeline actually looks like

Assessment is measured in days, not weeks. Data preparation and build together are the bulk of it. Handover overlaps the end of the build rather than following it, because training on a finished system teaches less than training on one being finished.

The whole thing is weeks. Anything quoted in quarters is either much wider in scope than it needs to be, or is not really a build.