Make the AI decision before you fund the build.
AI consulting turns an operational problem or broad AI ambition into a credible implementation path: the job, the source boundary, and the first intervention worth making.
The work is not a generic tool shortlistNineteen years of delivery since 2007 across six countries
- What work should changeWhere the decision belongs
- What information is reliable
- Who owns a high-consequence exception
- How useful output will be judged
- A model, agent demo or competitor announcementWhere teams start
Most AI initiatives begin too far downstream.
What we help decide.
Teams start with a model or a demo. The decisions that matter arrive later: what work changes, what information is reliable and who owns a high-consequence exception.
Where AI has a real job
Identify workflows, customer journeys and product moments where interpretation, generation or automation can remove meaningful friction. In practice this means separating three things that get discussed as one: work that is repetitive but already fast, work that is slow because a person has to judge something, and work that is slow because two systems do not talk. Only the middle one is usually an AI job. The first is not worth automating and the third is an integration problem.
What should happen first
Separate a near-term build from work needing better data, clearer ownership, a simpler process or a different product decision. This is the part that saves money, and it is usually unwelcome. A meaningful share of AI opportunities turn out to be blocked by something cheaper to fix: a field nobody fills in, an approval with no named owner, or a process that has three steps because of a rule that no longer applies.
What safe use looks like
Make source material, output standard, system boundary and human responsibility visible before a capability is treated as ready. Concretely: which sources the system is allowed to answer from, what a good answer looks like well enough to test, what the system may change on its own versus propose, and who resolves a case it cannot decide. A capability missing any of the four is not ready, regardless of how well it demonstrates.
How implementation connects
Route the decision into the right service build, integration, workflow fix or transformation work with dependencies visible. The dependencies matter more than the route. Most stalled AI work was sequenced wrongly rather than chosen wrongly: the build was correct but needed information, access or an owner that did not exist yet.
What this work will often tell you not to build.
No consulting page says this, so it is worth saying plainly. These are the four conclusions we reach most often, and three of them reduce the work available to us.
What we frequently find
The output cannot be judged. Nobody can say what a correct answer looks like, so nobody can test one.
What we recommend instead
Agree the standard first. Until then any build is unfalsifiable and will be argued about after launch instead of before.
What we frequently find
The source information is not usable. It is out of date, contradictory across systems, or not permitted for the purpose.
What we recommend instead
Fix the source. An AI layer over unreliable information produces confident wrong answers faster than a person would.
What we frequently find
The real constraint is a process rule, not a capability.
What we recommend instead
Change the rule. This is frequently a same-week fix that removes the need for the build entirely.
What we frequently find
The work is repetitive but nobody is waiting on it.
What we recommend instead
Leave it. Automating something with no queue behind it produces a system to maintain and no recovered time.
The fourth is the one teams resist most, because repetitive work feels like the obvious target. The test is not whether a task repeats. It is whether anything is waiting on it.
The decision test.
Four clear answers means the work is ready to scope.
Is there a recurring job?
What a bad answer sounds like
“We want to use AI somewhere in support.”
Why it matters
The opportunity starts with work, not a tool.
Can useful output be recognised?
What a bad answer sounds like
“We will know it is good when we see it.”
Why it matters
A team needs an agreed standard before users are asked to trust it.
Is the source usable?
What a bad answer sounds like
“It is all in the shared drive somewhere.”
Why it matters
Information must be current, authoritative and permitted for the job.
Who owns the exception?
What a bad answer sounds like
“It would escalate to the team.”
Why it matters
A named person must resolve a case the system cannot decide.
Two or more unclear answers means the next step is not a build, and saying so early is cheaper for everyone than discovering it in month three.
How the work operates.
Four steps, in the order they have to happen, and the plan they leave behind.
Frame the decision.
Define the outcome, affected people and problem that made the team consider AI.
Test assumptions.
Examine workflow reality, source material, system boundaries and ownership.
Prioritise intervention.
Select the first problem worth addressing and state what should not be attempted yet.
Route to implementation.
Connect the decision to the relevant build, integration, workflow or transformation path.
What a useful plan leaves behind. A named outcome and owner. A workflow, source and exception map. A first implementation route with explicit dependencies. A way to review whether the intervention is helping.
Published operational context, not consulting proof.
We have no published AI-consulting engagement. What follows is evidence of operating judgement inside delivered work, not a consulting contract.
Fitelo
An AI product running in production with evaluation and cost controls in place, rather than shipped and watched.
That is the same discipline this page argues for before a build.
Milo
A documented 70% faster check-in journey.
Evidence of operational improvement, not of consulting.
Conscious Chemist
A documented 38% faster product-question response.
In a customer-facing product experience.
Vizitor
A platform in daily multi-site use across 500+ workplaces in 15+ countries.
Cited as scale context only.
Deliberately absent
Read those two percentages carefully: they are engagement-specific operational results, not AI-consulting outcomes and not projections for a future engagement.
- No published AI-consulting engagement
- No AI-consulting outcome figure
- No projection for a future engagement
- No consulting contract, and none presented as one
Choose the right starting point.
When the first issue is a known operational handoff, see AI Workflow Automation. When the work needs a defined AI capability built, explore Generative AI Development or AI Integration Services.
- One failing workflow diagnosed and the first fix chosenBroken Workflow AssessmentIf the need is one known workflow, the assessment can be narrower.
- Several AI opportunities prioritised with an implementation pathAI Consulting & Strategy · you are hereIt is for a decision that needs to be made before implementation.
- A defined chatbot, agent, document system or feature builtThe relevant AI serviceA capability built, rather than the decision about whether to build one.
- Wider systems and operating-model changeDigital TransformationWider change than one workflow or one capability.
Talk through the AI decision your team needs to make.
Bring the desired outcome, the workflow or product moment it concerns, the relevant systems and source information, and the person who owns the decision.
Questions teams ask.
Pick a topic, or ask us directly. We answer every inbound within one business day.
Still have questions?
Talk to a senior engineer, not a bot.