Weeks 1–2: find where it pays back, then pick one thing
The temptation at the start is to buy a tool and look for somewhere to put it. Resist it. The first two weeks are for looking at your own business, not at software. Where does work pile up? Where do the same questions get answered by hand every week? Where does a job stall while someone waits on paperwork?
Walk the actual route. Sit with whoever quotes the work and time how long a quote really takes from enquiry to sent. Follow a job from booking to invoice and mark the points where it sits idle. You are looking for one workflow that is repetitive, costs real hours, and has a clear before-and-after you can measure.
By the end of week two you should have picked one. Not three, not a roadmap. One workflow, chosen because it pays back and because you can prove it.
Weeks 3–6: build it and get it into real use
Now you build the one thing. The goal for these four weeks is not a clever demo. It is the workflow running on live work, used by the person who does the job, every day. A pilot sitting in a corner that three people log into when they remember is not a result. It is a way to spend money and learn nothing.
Keep the first build narrow. Take the quoting bottleneck, or the chasing of supplier prices, or the writing-up of site reports, and make that single task faster and more consistent. Get it in front of the person who owns that task in week three or four, not week six, so the last fortnight is spent fixing what real use exposes.
Expect the first version to be wrong in small ways. That is the point of getting it live early. The rough edges show up only when someone uses it under real pressure on a real job.
Weeks 7–12: embed it, train the people, count the result
This is the half of the rollout most owners skip, and it is the half that decides whether anything sticks. Building the workflow is the easy part. Getting people to use it when you are not watching is the hard part, and it is won with the people doing the work, not with a tool you bought.
So train them properly. Sit with the team, watch them use it, fix the bits that annoy them, and write down how it is meant to run so a new starter can pick it up. Then count what changed: hours saved a week, days off the quote cycle, money that used to leak out of the process. Believable numbers for a business your size, the sort of thing where a quoting workflow saves a typical firm £5–15k of admin time over a year, not headline figures you can't back up.
Only when that one workflow is embedded and the numbers are real do you choose the next one. Prove one thing, then move on. That sequence is the whole discipline.
Name an owner for every system
Every workflow you put in needs one named person responsible for it. Not the firm, not "the team", a person. They are the one who notices when it drifts, who flags when a supplier changes a format and breaks an input, who answers when a new starter asks how it works.
Systems without an owner rot quietly. The person who set it up moves on or gets busy, nobody is accountable, and within a few months people have gone back to the old way and forgotten the new one existed. A named owner is cheap insurance against that.
What goes wrong when you skip the embed
The common failure is not a bad tool. It is a good tool that nobody adopted. The workflow gets built, the owner sees it work once, declares victory, and moves straight to the next idea. No training, no named owner, no measurement. Three months later the team has drifted back to spreadsheets and the spend has bought nothing.
The other failure is doing too much at once. Five workflows half-built, none of them embedded, the team overwhelmed and quietly resentful. Nothing is proven, so when money gets tight the whole lot is the first thing cut, and the verdict becomes "AI didn't work for us."
Ninety days is enough to do one thing properly: diagnose, build, embed, measure. Do that once and you have a result you can repeat. That is what a rollout that sticks looks like.