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, and some people have.

It usually produces one uncomfortable finding. The operation you were going to automate is third on the list, and the one at the top is the one held together by two long-serving people and a spreadsheet.

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 quoting. It is the sixty percent of quotes that are standard configurations, leaving the complex ones with a human.

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 working connection is spending your money to arrive at the same place.

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 quietly does not. A system with no owner has a shelf life of about a year, no matter how good it was on day one.

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 quietly 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

Note that 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.