At some point the planning is done. You've picked the job, counted the baseline, named the return, and checked whether your people, process, and data can carry it. You have a plan with a number on it.
Then the build starts, and this is where a lot of AI projects quietly turn into something else. The tool gets switched on. A few people try it. Six weeks later nobody can say whether it worked, and the plan that had a number on it is sitting in a folder.
The plan wasn't the problem. Usually the build just left things out. Here's what it should include, so you can hold any build to it, ours included.
Start with what the plan hands over
A good plan, whether you made it yourself or worked through it in a Blueprint session, should hand the build five things in writing:
- One job, with a start and an end. "Reply to new website inquiries and book the first call," not "AI for sales."
- The baseline. How often the job happens, how long it takes, how long it waits, how often it's missed, and who does it.
- The return you're after. Revenue protected or added, cost that actually leaves, or capacity your team gets back. One of them, stated plainly.
- The roadblocks. Whatever the people, process, and data checks turned up.
- The order of work. What has to happen first, second, and third.
If any of those is missing, the build is starting from a guess. It's worth stopping to fill the gap before anyone writes a line of setup. It's a lot cheaper to fix on paper than in a half-finished system.
The build should clear the roadblocks before it automates anything
Most of the risk in a build sits in the unglamorous work that comes before the AI does anything at all.
If three people do the job three different ways, the build starts by agreeing on one way and writing it down. If the customer records are split between a spreadsheet and a CRM, someone cleans that up and picks the source of truth. If a step exists only because it always has, cut it instead of automating it.
The order we use is cut, standardize, then automate. Remove the work that shouldn't exist, make the rest consistent, and only then hand it to a system. Automating a messy process mostly gets you the same mess faster.
This part rarely shows up in a demo. It belongs in the scope anyway, with time and an owner attached.
Then the workflow itself, written down step by step
The actual system should be described clearly enough that someone on your team could explain it without the person who built it:
- What starts it. A form submission, a new invoice crossing 15 days, a calendar event ending.
- What happens at each step, and which tool does it.
- Where AI drafts and where it decides. Drafting a reply is different from sending it. Suggesting a price is different from quoting one.
- Where the result lands. The CRM, the shared inbox, the job board, the accounting system. If the output lives in a separate AI tool nobody opens, it isn't really part of the business yet.
That last point catches more builds than you'd expect. The work has to end up where your team already looks.
Every build needs human checkpoints and an exceptions path
AI is good at the routine version of a job. Your business is full of the non-routine version: the client with a special arrangement, the inquiry that's really a complaint, the invoice that's late because you agreed to it.
So the build should say, in plain language:
- Who reviews what, at least in the early weeks.
- What counts as an exception, and how the system recognizes one.
- Where exceptions go and who owns them. A named person, not "the team."
- What happens when that person is out.
This is also where the judgment calls live. A well-built system handles the routine work so your people can spend their time on those calls, serving customers and solving problems, rather than retyping the same email for the fortieth time.
Measurement starts on day one, not after a quiet month
The baseline you counted during planning is the yardstick. The build should track the same measures from the first day the system runs: volume, time, wait, misses.
Keep it simple. A short weekly check against the baseline beats a dashboard nobody opens. And the stop sign you set during planning stays in force. If the target isn't moving and the review work is eating the time saved, that's a signal to pause and look, not to wait another month.
Keep the returns separate, too. Hours your team gets back are capacity. They turn into cash savings only if a cost actually leaves, and into revenue only if those hours go toward work that brings it in. Don't let the build report count the same hours twice. (We covered that trap in AI ROI for small businesses.)
Training and documentation are part of the build
A system your team doesn't trust won't get used, no matter how well it works.
The build should leave behind:
- A written procedure for the new way of doing the job, clear enough to train a new hire from.
- Short training for the people who touch it, built around real examples from your business.
- A one-page "what to do when" for the common exceptions.
If the only person who understands the system is the one who built it, you've traded one dependency for another.
Go live in stages
Big-bang launches are where trust gets lost. A staged go-live is calmer and tells you more:
- Run it alongside the old way for a short period and compare the results.
- Turn it on for one slice of the work: one service line, one inbox, one person.
- Widen it once the numbers and the team both say it's working.
Each stage should have a clear "ready for the next step" test, written down before you start, tied back to the target.
Support after go-live, scoped to the system
Tools change. A field gets renamed in your CRM, a vendor updates a model, your pricing changes, a new service gets added. Any of those can break a workflow that ran fine last month.
So the build should end with a support arrangement that says who watches the system, who fixes it when something changes, how fast, and how often you review whether it's still producing the return. It doesn't need to be elaborate. It needs to exist.
A hypothetical, carried through to the build
Here's an illustration with made-up numbers, not a client result. It picks up the IT services example from our guide on turning industry AI ideas into a business case.
The plan says: reply to every website inquiry within one business hour, and stop losing the four a month that never get a reply. Baseline is about 30 inquiries a month, next-day replies, and a service coordinator who handles them between tickets.
A build that includes everything above might look like this:
- Roadblocks first. Agree on one reply standard and three or four approved reply templates. Make the CRM the only place inquiries live.
- Workflow. A new inquiry creates a CRM record. AI drafts a reply using the inquiry and the firm's service list, and offers booking times.
- Checkpoint. For the first few weeks, the coordinator approves each draft before it goes. Anything that reads like a complaint or a current client goes straight to the coordinator.
- Measurement. Weekly count of inquiries, median reply time, unanswered inquiries, first calls booked.
- Staging. Two weeks running alongside the old process, then live for website inquiries only, then email inquiries.
- Training and support. A one-page procedure, a 30-minute walkthrough, and a monthly check that the reply times are holding.
None of that is exotic. It's just complete. And that's usually the difference between a system that runs and a tool that got switched on.
Questions to ask before you sign off on any build
Whether you build it yourself, hire it out, or work with us, these are fair questions:
- What number is this build meant to move, and what's the baseline today?
- What gets cleaned up or cut before anything is automated?
- Where does the AI draft, and where does it decide?
- Who reviews the output, and where do exceptions go?
- How will we know in the first month whether it's working?
- What's the stop sign?
- What documentation and training do we get?
- Who supports it after go-live, and what does that cover?
If the answers are vague, the build will be too.
Where to start
If you haven't picked the job yet, start with where to put your first lever. If you have an idea but no numbers, the business case guide walks you through the baseline. For a view of where the return usually shows up in businesses like yours, grab the free AI Leverage Report for your industry.
And if you've got a plan and want a second set of eyes on what the build should include, that's what the free 30-minute AI Leverage Call is for. Bring the job, the baseline, and whatever scope you're looking at, even if it's rough.
