Most AI ideas are not worth doing. The job is finding the ones that are.
AI consulting is the work of deciding what not to do. Most of the ideas a business arrives with are demonstrations rather than savings — impressive to watch, expensive to run, and answering a question nobody was being paid to answer. The job is to find the few that genuinely pay, put them in an order, and be straight about which are not ready.
Personal reply from Andrew within one business day.
What is AI consulting?
AI consulting is the work of establishing which parts of a business would genuinely be cheaper, faster or more accurate with a model involved — and, more usefully, which would not.
Almost every business has now seen a demonstration. Somebody typed a question, something impressive came back, and the impression it left was that the technology is capable of nearly anything. That impression is not wrong, and it is close to useless for deciding what to build. Capability is not the constraint. The constraint is whether a particular task in a particular business has the shape that repays automating at all — which has nothing to do with how clever the demonstration was.
Three conditions decide it, and a candidate has to meet all three. It has to happen often enough that removing it is worth something — volume, not difficulty, is what pays for a build. Its input has to be something a model can actually read, which usually means text or a document rather than a conversation, a photograph of a whiteboard, or knowledge that only exists in somebody’s head. And there has to be a right answer that can be checked, because a task nobody can grade is a task nobody can tell is going wrong. Most ideas fail on the second or third condition, and they fail quietly, months into a build.
An AI strategy that is not attached to a task is a document. Businesses are regularly sold a roadmap, a maturity assessment, a set of pillars. None of it survives contact with the first real project, which immediately discovers that the data it needs sits in three systems that disagree, or that the process it was going to sit on has never been written down, or that the person who was going to own it already has a full-time job. The useful assessment starts from a list of actual tasks and works outwards. Everything else is a slide.
The blocker is usually not AI. More often the honest finding is that the business would get more from settling a definition, connecting two systems that already disagree, or switching on something it is already paying for. Those are not consolation prizes. They are usually cheaper, faster and more valuable than the AI project that was being considered, and they are also what makes the AI project viable later. Where that is what the work finds, it is what gets said — and being sent to data and reporting, systems and API integration or process automation instead is a normal outcome of this conversation rather than a disappointing one.
There is a sharper version of that point worth stating plainly. Where a process is fully repeatable and needs no judgement, the recommendation will be ordinary automation rather than anything agentic, every time. That is a workflow problem, not an AI problem, it costs nothing per run, and it behaves the same way next year. A model earns its place only where something genuinely has to be read or interpreted — which is the subject of AI workflows, the page next door.
How does a long list of AI ideas become a short one?
Five filters in a fixed order. The first two are cheap and can be applied in a conversation. The last two are the expensive ones, and they are the ones almost always deferred.
-
01
Everything that has been suggested
Every idea from the demonstration, the conference, the board, the vendor and the team. All of it goes on the list, unfiltered, including the ones you already suspect are silly.
falls out here if: nobody can name the task it removes, only the technology it uses -
02
It happens often enough to matter
Volume, not difficulty. A hard task done twice a month stays a person’s job; an easy one done two hundred times is where the money is.
falls out here if: the hours it removes would not pay for the build in any reasonable period -
03
A model can actually read the input
Text, documents, structured records. Not a conversation, not a photograph of a whiteboard, not something that only exists as knowledge in somebody’s head.
falls out here if: the information the task needs was never written down anywhere -
04
There is a right answer, and it can be checked
Something external to compare against, or two people who would independently agree on the same answer for the same case.
falls out here if: two experienced people label the same sample differently and cannot say who is right -
05
Somebody will own it after handover
A named person who is told when it fails and is allowed to change it, with capacity that actually exists rather than capacity in principle.
falls out here if: the only honest answer to who owns this is the person who built it
The filters are in this order because of what each one costs to apply. Volume can be established from a conversation and a look at the last three months. Whether a model can read the input takes an afternoon. Whether there is a right answer takes a sample somebody labels by hand, and whether anybody will own it takes a conversation with a person who has to say no to something else in order to say yes. Which is why so many projects get most of the way to go-live before discovering that nobody can agree what a correct result looks like. Neither discovery is cheaper later.
Two or three survivors is a good outcome, not a disappointing one. A list that comes out of this with eight candidates has usually had the filters applied generously, and the eight will then compete for the same scarce thing — the attention of the one or two people in the business who can actually specify and own them. Doing two properly beats starting eight. The businesses that get value from this technology are consistently the ones that finished something.
What fell out matters as much as what survived. The record of which ideas failed, at which filter, and why is the part that keeps working after the engagement ends: it stops the same idea being re-proposed every six months by somebody who was not in the room. A shortlist on its own is an opinion. A shortlist with the rejected list attached is an argument.
What are the actual options right now?
Four routes a business can take today. The first is a genuine option rather than a straw man, and it is the one recommended most often.
| Do nothing yet | Buy the assistant licences | One narrow pilot | A platform or programme | |
|---|---|---|---|---|
| What it is | Deliberately wait. Fix the data, the definitions and the processes any later project would have depended on anyway. | Give the team the AI already built into the products you run, and see what they actually use it for. | Pick one task that clears all five filters, build it properly, and measure it against the way it is done now. | A platform, a set of agents, a programme of work with a roadmap attached. |
| Where it wins | Where the data is in three places, or nobody has capacity to own anything new. Far more often the right answer than it gets to be. | Cheap, reversible, and it shows where the appetite actually is — which is usually not where the strategy said. | Where a real task clears the filters and somebody has been complaining about it for a year. | Where several proven workflows already exist and the constraint has genuinely become coordination. |
| What it costs | Nothing new. The opportunity cost is real and worth naming out loud. | Per-user licences, and the time to find out what the tools actually do. | A build, a labelled sample, a parallel run, and a small running cost per item. | The largest commitment, usually made before anything has been proven. |
| How it fails | By becoming permanent. Waiting is a decision that needs a review date attached or it turns into a position. | By fizzling. Nobody is told what to use it for and the licences renew unnoticed. | By being chosen for interest rather than volume, so it works and saves nothing anybody notices. | Expensively and slowly, with the failure visible about three quarters of the way through. |
| What it needs from you | A date to revisit, and honesty about what is actually being fixed in the meantime. | Somebody to look at what people used it for after a month. | A labelled sample, an agreed threshold, and a named owner. | Proven workflows first. If there are none yet, this is the wrong column. |
The first column is the one this page will recommend most often, and it is worth being explicit about why that is not evasion. A business whose month-end figures depend on a spreadsheet only one person can drive does not have an AI problem. Layering a model over that produces faster access to numbers nobody trusts. The work that has to happen first — settling a definition, connecting two systems, removing a manual step — is unglamorous, it is what data and reporting and systems and API integration cover, and it is what makes the AI project viable rather than what delays it.
The fourth column is not wrong, it is out of order. Platforms and agent programmes have real uses, and almost all of them appear after a business already runs two or three workflows it trusts, because at that point coordination genuinely is the constraint. Bought before that, the platform becomes the project: months are spent configuring a thing whose value depended on workflows that were never built. The question that sorts this quickly is whether anything is currently running unattended and trusted. If the answer is nothing, the fourth column is a year early.
How does the assessment work?
An AI opportunity assessment establishes where and how AI would fit a business, and where it would not. It runs from a short call to a multi-week review depending on how much of the business is in scope, and it ends in writing.
Inventory the work, not the technology
- Time with the people doing the tasks
- What actually arrives, and in what form
- Volume and frequency, per task
- The tasks nobody thinks to mention
The list that comes out of this is always different from the list the business started with, because the tasks that cost the most are rarely the ones anybody thinks to mention. They have been absorbed into how the week works and stopped being visible as tasks at all.
Apply the filters, and record what fell out
- Volume, readable input, checkable answer, owner
- Each candidate against all four
- The filter each rejection failed at
- The alternative that would actually help
The output that matters is not the shortlist; it is the record of what failed and at which filter. That record is what stops the same idea being re-proposed every six months, and it is what makes the shortlist credible rather than arbitrary.
Cost it whole, and put it in order
- Build, measurement, running cost, ownership
- Doing nothing costed alongside as a real option
- An order, with the dullest first
- A written plan with costs against it
The order starts with whichever survivor is dullest, most measurable and most reversible, because the purpose of the first project is not to be impressive. It is to still be running in six months, which is what makes the second one possible.
- Candidates assessed, and how many survivedcounted, both ways
- Hours each survivor currently costsestablished before any build
- First project still running at six monthsthe one that matters
- Recommendations that were not AIa test of honesty
The third is the only one that matters in the end, and it is the one nobody asks about at the start. A pilot quietly abandoned four months in is more damaging than never starting, because it settles the question of whether this works here — wrongly, and for years. No figures appear on this page. Every number above is measured in your own business against its own starting point.
The first conversation costs nothing, and a single process is enough to start with. The free audit covers where AI would and would not help.
Book a free process auditWhen is the answer to do nothing yet?
Often, and on this page that is the argument rather than a caveat at the end of one. Four situations account for most of them.
The data is not in one place yet. If the figures the workflow would depend on live in three systems that disagree, no model resolves that. It produces faster access to numbers that are already contested, which makes the disagreement more visible without making it smaller. The work that comes first is connecting the systems or settling the definition, and both are covered elsewhere on this site precisely because they are what the AI project turns out to have been waiting for.
Nobody has capacity to own it. Every workflow needs somebody who is told when it fails and is allowed to change it. In a small business that person almost always already has a full-time job, and adding an unowned system to their week is how a project becomes an outage nobody can debug. If the honest answer to who owns this is the person who built it, the right recommendation is to wait until it is somebody who works there.
The process it would sit on is still being argued about. Automating a contested process does not settle the argument; it awards it to whoever was in the room, and encodes the result in something considerably harder to change than a habit. Settle it on paper, run it that way for a month, and revisit what survives contact with a real month.
The pressure is coming from outside the business. A board paper, a competitor’s announcement, a vendor’s roadmap, a conference. None of those is a task, and a project started to answer one of them has no way to tell whether it worked. Wanting to be seen to be doing something about AI is a real commercial pressure and it is not a reason to build. The cheapest way through it is usually a written assessment showing the work was done properly, rather than a system nobody uses.
Questions about AI consulting.
Are you going to tell us not to do it?
Frequently, and it is worth knowing that before engaging rather than after. The three conditions a candidate has to meet are demanding — real volume, an input a model can read, and an answer that can be checked — and most ideas fail at least one of them. Where that happens the recommendation is to say so, name which filter it failed and why, and point at the work that would actually help instead — regularly a definition to settle or two systems to connect. The commercial position is straightforward: recommending a build that will not repay itself is a way to lose a client slowly.
Do we need an AI policy?
Something written down, yes, and it does not need to be long. The questions worth settling are practical rather than legal: what personal information ends up in the input, who can see the output, how long anything is retained, whether your privacy statement already covers it, and which tools staff are and are not to paste customer information into. Most small businesses discover the last one is already happening informally, which is a better reason to write something down than any regulation. To be clear about the limits of this: XBA is not a law firm and does not give legal advice, holds no certification in this area, and cannot tell you that you are compliant. What can be done is making sure the questions get asked before anything is built rather than after somebody notices.
Will this mean fewer people?
Usually it means the same people doing different work, and the reason is worth stating rather than just the reassurance. The tasks that clear the filters are the low-judgement, high-repetition ones, and very few small businesses are fully staffed for the judgement work they already have — so the realistic outcome is a week that gets its afternoons back, spent on the exception rather than the ordinary case. It would be dishonest to promise no role is ever affected anywhere. What can be said plainly is that the projects which go well are the ones where the people doing the task helped design its replacement.
Which vendor or model do you recommend?
It is close to the last question worth asking, and it is almost always the first one asked. The work is built on the mainstream API tiers — Claude, OpenAI, Azure OpenAI inside your own tenant, Gemini and Vertex AI — alongside what you may already own in Microsoft 365 Copilot or Power Automate, and open-weight models run locally where nothing may leave the building. Which is chosen matters far less to whether a project succeeds than whether the task had volume, whether the input could be read, and whether anybody could say what a right answer looked like. The models are also close enough in capability, and moving fast enough, that picking on the benchmarks of the day is picking on something that will have changed by the time the build is finished. What matters is that the workflow is built so the model can be swapped, and that nothing important lives inside a vendor interface where it cannot be read or moved.
What do we actually get at the end?
A written evaluation of the current state, and a proposed action plan for the future one with costs against it. That means the list of candidates that were assessed, which ones fell out and at which filter, what the survivors would cost to build and to keep running, and the order they should be done in — with doing nothing yet costed alongside them as a real option rather than a rhetorical one. It is yours to keep and to act on with somebody else if you would rather. The starting point is the free process audit, which is written, costs nothing, and is enough for a single process; a wider review across the business is scoped and quoted before it begins, so there is never an invoice you have not already agreed to.