Why a document, and why first
An ROI Blueprint is the deliverable from our scoping engagement, and it exists for an unglamorous reason: it forces every assumption into writing before anyone commits budget to building something.
Automation projects rarely fail because the technology didn't work. They fail because the workflow chosen wasn't actually expensive, or because the savings were real but nobody could demonstrate them afterwards, or because a dependency nobody flagged turned a six-week build into a six-month one. All three are catchable on paper, in days, for a fraction of what they cost to discover during a build.
Part one: what this workflow costs you today
This is the section that does the most work, and the one clients are most surprised by — because most organisations have never costed a workflow end to end.
We're after the fully loaded picture, not just headcount:
- Time spent per case, measured across the whole path rather than the happy path.
- Volume — how many cases per week, and how much that number moves seasonally.
- Rework: the proportion of cases touched more than once, and why.
- Downstream cost of errors — corrections, escalations, credits, remediation.
- The queue. What waits behind this work, and what that delay costs elsewhere.
That last one is routinely the largest number in the section and the one nobody has counted. When a workflow is a bottleneck, its true cost isn't the labour inside it — it's everything held up behind it.
Part two: the intervention, in specifics
Not "we'll apply AI to this." Specifically: which decisions move to automated handling, which stay with people, and what happens at the boundary between them.
This section names the architecture — where deterministic logic sits, where a model reasons, where a human reviews — and it names the escalation path. If a case is ambiguous, who sees it, with what context attached, and how fast? A blueprint that doesn't answer that is describing a demo, not a system.
It also states plainly what isn't in scope. Scope that isn't written down has a way of arriving later as an assumption someone else was making.
Part three: how you'll know it worked
Defined before the build starts, because a success metric chosen afterwards is a metric chosen to be met.
Two things need to exist. A baseline — the current-state numbers from part one, captured as a measurement you can re-run rather than a figure in a slide. And a small set of metrics that would move if the intervention is working, with the interval at which you'll check them.
We also try to name a counter-metric: the thing that shouldn't get worse. Throughput improvements that quietly degrade accuracy are common, and they're only visible if someone decided in advance to watch for them.
Part four: what could go wrong
A risks section that doesn't hedge. In our experience the recurring ones are boring and predictable: data that's less accessible than assumed, a system whose integration path is undocumented, a regulatory requirement discovered halfway through, and — most often — the person who actually understands the workflow having no time allocated to the project.
Each risk gets a rough likelihood and what it would do to the timeline. The purpose isn't to be pessimistic. It's that a risk written down in week one is a planning input, while the same risk in week eight is a crisis.
The part people skip
The recommendation not to proceed.
A blueprint that always concludes "yes, build this" isn't an analysis, it's a sales document. Some workflows aren't worth automating: the volume is too low, the process is about to change anyway, or the real problem is upstream and automating the symptom would entrench it.
Finding that out from a scoping engagement is a good outcome, not a wasted one. It's a materially cheaper way to learn it than the alternative.
If you want to see how this connects to delivery, our flow lays out what happens after the blueprint.