Four phases, a concrete output at the end of each, and a clear split of decisions. Including the part most sites leave out: the conditions under which we will tell you not to start.
Each phase ends in a document and a decision about whether to continue. That is not a formality — a project can end after the first or second phase, and that is an anticipated outcome rather than a broken engagement. The structure applies to anAI implementation whether the work is automating a process, building an assistant for a team, or integrating with a system you already run.
| Phase | What it produces |
|---|---|
| 1–2 wksAudit and process selection | A list of candidate processes with time and cost estimates, one process chosen to go first with the reasoning for it, and measurable success criteria agreed before anything is built. |
| 2–4 wksPilot | A working solution on your real data rather than sample data, measured against the criteria from phase one. This is where the “production or stop” decision is taken. |
| 4–12 wksProduction rollout | Integration with your systems, handling of edge cases and failures, logging and quality monitoring, technical documentation, and a route for reporting problems. |
| ongoingHandover and growth | Training for the team, handover of code and documentation, agreement on who watches for failure and how they would notice, and a plan for the next processes based on data from this one. |
The durations are indicative, and what usually stretches them is not engineering but data access and client-side decisions. What actually drives the cost is broken down in our piece onwhat an AI implementation costs.
Most projects that stall do not stall on technology. They stall because nobody has the authority to settle an argument about what the process should look like once it changes. So the split is agreed at the start:
The fastest route to a wasted budget is applying AI where the problem is not an AI problem. We check the following in phase one, and if any of them holds we say so immediately — before invoicing for a build.
In each of those cases you get the reasoning in writing and, where one exists, a cheaper route to the same goal. Advising against a project costs both sides less than delivering one nobody uses.
From the first conversation to a process running in production, usually two to four months — and the time goes not into building but into data access and decisions on the client side. A pilot alone is typically two to four weeks. Anyone promising the whole thing in a fortnight is describing a demo, not an implementation.
Yes, and that is normally where we start. A strategy written before the first implementation rests on assumptions nobody has tested. One process taken all the way to production produces hard numbers about what it actually costs and where your organisation’s bottleneck really sits — and that is what a plan for the rest should be built on.
We stop at the pilot and you get a written account of what we learnt: where the model failed, what condition the data was in, and whether the problem was the technology or the process itself. That is an anticipated outcome rather than a failed project — which is exactly why the pilot is a separate phase with its own decision, not a deposit against the build.
One person who knows the process from the inside and has the authority to change it, plus someone from IT for access and integration. Without the first of those the project will not succeed — not for want of hands, but because there is nobody to settle what the process should look like once it changes.
The code, the configuration and the documentation are yours, and we hand them over at the end of the implementation. We treat that as a condition of working honestly: if a support contract only makes sense because nobody else understands the system, that is not support, it is a lock.
In two ways. First, the output is probabilistic — the model will sometimes be wrong, so we design for what happens when it is rather than assuming it will not. Second, quality depends on data more than on code, which is why a data audit is a phase in its own right rather than a line item in pre-implementation analysis.
A free consultation that ends with knowing which process makes sense to go first — or whether it is worth starting at all.