AI Strategy
A four to six week engagement that produces a ranked list of where AI pays in your organisation, a written refusal list, and a baseline you can hold us to.
Most AI strategy work produces a deck. This produces a ranked list of processes, a measured baseline for each, and a written record of what we recommended you not automate.
The distinction matters because the common failure is not choosing badly. It is never choosing at all: a year of pilots, an adoption dashboard, and nobody able to say whether anything got cheaper.
The question the engagement answers#
Not "should we use AI". That question has no answer, invites opinion, and is settled by whoever is most senior in the room.
Instead: which twenty processes consume the most human hours, and which of those can be automated or augmented? That has an answer, the answer is a list, and a list can be wrong and therefore corrected.
What happens#
| Week | Work |
|---|---|
| 1 | Process inventory. Hours measured from system logs and observation, not from asking. People underestimate routine work and overestimate exceptional work, consistently |
| 2 | Ranking by annual hours, then scoring each candidate on volume, structure, reversibility and tolerance for error |
| 3 | Baselines for the top candidates, defined so they can be measured again afterwards |
| 4 | Sequencing, costing, and the refusal list |
| 5 to 6 | Optional: a costed implementation plan for the first two changes |
What you receive#
- The ranked inventory, with hours attached, so the argument about priorities is settled by data
- A scored shortlist, with the constraining axis named for each candidate
- Frozen baselines for the top candidates, which is what makes any later benefit claim checkable
- A written refusal list: what we recommend you do not automate, and the condition that would change that
- A sequenced plan with costs and dependencies
The scoring rule we will not bend#
A process scoring low on reversibility or tolerance for error does not go to full automation, whatever its volume. It may go to augmentation, where a person still decides.
That rule is the difference between a transformation programme and an incident, and we would rather lose the argument now than be right about it later.
What we will not do#
- Recommend automating something because it is technically possible. The test is reversibility and accountability, not capability.
- Produce a benefit forecast without a measured baseline. A forecast with no baseline cannot be checked, which is usually why it is offered.
- Claim a saving that is really a reallocation. If four hours of work becomes twenty minutes of work plus three hours of supervision, nothing was saved.
How we work, in public#
The operating model we use internally is published in full: the KPIs, the procedures, the templates and what we deliberately do not let an agent decide.
You can read exactly how we would run this before speaking to anyone. That is deliberate: it is easier to judge a method you can inspect than a capability you are asked to take on trust.
Getting started#
The inventory is the part with the most value and the least glamour, and it is where we would begin. Get in touch with which function is most expensive to run, and we will tell you whether this is worth doing before you commit to it.