Each step ends in a document or a system you own, so you can stop at any boundary and still be further ahead than when you started. Nothing is held back to force the next stage.
/ 01Assess
In one line: We find out how the business actually runs.
What happens: We sit with the operations we agreed to scope and follow the work through them. That means reading the systems your team already uses, watching where information gets re-entered by hand, and interviewing the people doing the job alongside the people who own the process. We time the tasks that get repeated. We collect the artifacts: the proposal templates, the intake forms, the spreadsheets somebody maintains that nobody asked for.
Why it is done this way: Process documentation describes the intended workflow. Interviews with the person doing the job describe the actual one. The distance between those two is where most of the recoverable time is sitting, and it does not show up in either account on its own.
What you get: A workflow map of the scoped operations, and a plain-language write-up of where time and margin are leaking.
How long: Most of the two to four weeks.
/ 02Prioritize
In one line: We rank every opportunity honestly, including the ones we would not take.
What happens: Each candidate opportunity is scored on three axes: the return it would produce, the effort to build it, and the risk it carries if it goes wrong. Return is modeled rather than asserted, using the volumes and durations collected in step one. Risk covers what happens when the system is wrong, not only whether it works, because a tool that drafts a client email and a tool that quotes a price fail very differently.
Why it is done this way: Ranking by return alone produces a roadmap that starts with the most expensive item and stalls. Sequencing from fastest payback funds the rest of the program out of its own results, which is the difference between a roadmap that survives a budget review and one that does not.
What you get: A phased roadmap with sequencing and owners, a modeled return on the top recommendations, and a written statement of what is not worth automating and why. A walkthrough session to hand it over.
How long: The back end of the assessment window.
/ 03Implement
In one line: We build the thing, inside the software you already use.
What happens: Production build, integrated with your existing systems, tested against a set of real cases pulled from your own records rather than demo data. Your team gets trained on it while it is being built, not after. Documentation is written for the person who will do the job, not for a developer who might inherit it.
Why it is done this way: A system tested only on clean examples fails on the first messy one, and the messy ones are the majority. Real cases surface that before launch, when it is a fix, rather than after, when it is a reason to stop using the tool.
What you get: A working system you own outright, documentation, handover, training, and a measurement approach wired to the metric agreed up front. No vendor lock-in.
How long: Typically 4 to 8 weeks per system. Multiple systems are sequenced rather than run in parallel, so nobody on your team is absorbing two changes at once.
/ 04Measure and refine
In one line: We report against the one number until it moves.
What happens: The KPI was agreed before any work started, so there is nothing to negotiate about at this point. We report against it monthly, with the baseline shown alongside, and we keep tuning the system while the number is short of target. Where a system is doing its job but the KPI is not moving, we say so and look at why, rather than quietly reporting activity instead.
Why it is done this way: One metric agreed in advance is the only version of this that cannot be gamed after the fact. A dashboard assembled at the end of an engagement will always find something that went up.
What you get: Monthly reporting against the agreed KPI, and continued refinement until it is met.
How long: Every engagement targets a first measurable result within 90 days.
