What Is AI Consulting, and When Do You Actually Need One?

AI consulting is someone working out where AI will genuinely help your business, building that, and usually keeping it running afterwards. The useful version is not a strategy deck. It is a person who maps the repetitive work in your company, tells you honestly which parts are worth automating and which are not, then builds the ones that are. You need one when you can see the opportunity but have nobody who can scope it or build it.

That is the short answer. Below is what the work actually involves, what it costs, how the different kinds of firm differ, and the cases where you should not hire anybody.

What does AI consulting actually involve?

Three things. Some firms do one of them, some do all three, and which you are dealing with is the most important thing to establish about any AI consulting firm you talk to.

They work out what is worth doing. Someone goes through your week, finds the tasks that repeat, puts a rough cost against each, and hands you a ranked list. Done well this is the most valuable part, because most businesses guess wrong about where their time goes. We wrote a full walkthrough of how to find the AI use cases worth doing if you want to try it yourself first.

They build it. The ranked list becomes a working system connected to the tools you already use: your email, your CRM, your documents. This is where most of the difference between firms shows up, because recommending something and building it require completely different skills.

They keep it running. Systems drift. The client changes a form, a tool changes its layout, an edge case appears that nobody planned for. Someone has to notice and fix it.

The gap to watch for in AI consulting is a firm that stops after the first. A ranked list of opportunities is genuinely useful, but it is not a working system, and a roadmap you cannot act on has cost you money and bought you nothing.

When do you actually need AI consulting?

Five signals, and one is usually enough.

The same work happens every week and a person does it by hand. Formatting documents, chasing replies, copying information between two systems, assembling the same report. Frequency is what makes automation pay.

You can describe the task but not build it. This is the common case. You know exactly what should happen because you have done it a hundred times. What you do not have is anyone who can turn that into working software.

You tried a tool and it did not stick. Usually this means the tool solved a generic version of your problem rather than yours, or nobody was trained on it properly. Both are fixable, but not by buying another tool.

The knowledge lives in one person's head. If a single person is the only one who knows how something works, you have a risk rather than a process. Getting it out of their head is often the real project.

You are about to hire for a role that is mostly coordination. Before you commit to a salary, it is worth knowing which parts of that role a system could do and which genuinely need a person. Sometimes the answer is that you should still hire. At least you will know.

When you do not need AI consulting

This section costs us work and it belongs here anyway, because hiring the wrong help is worse than hiring none.

Your problem is a process problem. If three people disagree about who owns a step, automating it will make the disagreement faster, not smaller. Fix the process first.

One ordinary tool already solves it. Plenty of problems are solved by a scheduling link, a shared inbox, or a form. If something off the shelf covers it, buy that and spend the difference elsewhere.

You have someone technical with spare capacity. If you already employ a developer who is not fully booked, hand them one task and see what happens. You will learn more from that than from a discovery workshop.

You cannot say what a good outcome looks like. "Be more efficient" is not a target. If nobody can name the number that should move, any engagement will end in an argument about whether it worked.

Cashflow is the actual problem. AI will not fix an offer nobody wants or a pipeline that is empty. Automation makes an existing business faster. It does not create demand that was never there.

What kinds of firm will you meet?

Broadly three, and they suit genuinely different situations.

Large consultancies. Accenture, Deloitte, the big four and their peers. AI consulting at that scale is built for a different customer, and they are strong where governance dominates: heavy regulation, thousands of staff, a board that needs a defensible process. They are expensive, the people who sell the work are usually not the people who do it, and a small business is rarely their priority. If you have 15 staff you will likely be a rounding error on their smallest engagement.

Platform and tool vendors. Firms whose consulting exists to get you onto their software. The advice is often good, and it will always end at their product. That is fine if their product fits. It is a problem if the honest answer was a spreadsheet and a scheduling tool.

Independent engineering-led firms. Small outfits where the person advising you is the person building it. Faster, cheaper, and more direct, with the obvious trade that there is less bench behind them. Worth checking they will still be reachable in a year.

We are the third kind, so treat that as a stated bias rather than a neutral survey. The useful takeaway is not which category is best. It is that you should know which one you are talking to, because the sales conversation sounds similar in all three and the engagement does not.

What does AI consulting cost?

It varies too much for a single number to help you, so here is how to make the quotes comparable instead.

Insist on a fixed price against a written scope. Hourly billing puts the risk of a bad estimate on you, and estimates on this kind of work are frequently wrong. A firm that will not quote before starting either does not understand the job yet, in which case more scoping is the next step, or is keeping the meter running.

Ask for the one off and the ongoing separately. Almost every system has a build cost and a running cost. A quote that mentions only the first is incomplete, and the second is the one that compounds.

Check what happens to the running cost as volume grows. Doubling your usage should not double your bill unless somebody explains why.

Ask whether an assessment is credited against the build. Many firms, ours included, put the assessment fee towards implementation if you continue. That makes the first step much easier to justify, because the downside is a ranked list you can act on with anyone.

Compare against the alternative honestly. The real comparison is usually not one firm against another. It is the system against the cost of the person currently doing the task, or the hire you are about to make.

Worth a look before you commit: Singapore and Australia both run government support schemes for small business technology adoption, and the terms change year to year. IMDA covers what is current for Singapore businesses and business.gov.au does the same for Australia. It will not change which project you should do, but it can change the payback.

What does a good AI consulting engagement look like?

The shape is fairly consistent, whoever you use.

Discovery, one to two weeks. Someone maps the recurring work, costs it, and ranks it. You should finish with a document you could hand to a different firm and still act on. If it only makes sense with the author in the room, it is a sales asset rather than a deliverable.

Design, a week or two. What gets built, what it connects to, what a person still approves, and how you will know it worked. Agree the definition of finished here, in writing, before anybody builds. Most engagements that go wrong went wrong at this step.

Build, a few weeks for a first system. Expect the smallest useful version first, running alongside your manual process rather than replacing it on day one. Comparing the two on real work is how you find the exceptions nobody mentioned in discovery, and there are always some.

Handover and training. On your team's own work, not a demo. Plus an agreement about what happens when the system gets something wrong and who fixes it.

Then operations. Someone watches it, fixes drift, and adds the next task. This is the point at which a collection of automations starts becoming one system your team works in. This can be you, if the handover was done properly and you have someone to own it.

Be wary of anything that stretches discovery to two months. On a business of 2 to 50 people there is not that much to discover, and a long discovery phase is often a way to bill while working out what to sell you.

How do you choose between them?

Five questions, and the answers tell you more than any proposal.

Who will actually build this, and will I talk to them? In a lot of firms the person in the room is not the person who does the work. That is not automatically bad, but you should know before you sign.

What happens when it gets something wrong? Every system does. The plan matters more than the accuracy rate. The answer you want is that it stops and hands the case to a person, not that it guesses.

Who fixes it in six months, and is that included? Ask directly whether ongoing support is billed, bundled, or simply not offered.

What do I own at the end? You want the system, the documentation and the data, in your own accounts. If leaving means losing the work, that is a rental, and it should be priced like one.

What would you tell me not to automate? Our favourite question. Anyone who says everything is a candidate is selling. A good answer names something specific and explains why the judgement should stay with a person.

Common questions

Is this only for technical businesses? No, and mostly the opposite. Having nobody technical is the usual reason to bring someone in. It affects who builds the thing, not whether the opportunity is there.

How small is too small? If you have recurring work that someone does by hand every week, there is usually something worth doing, even at two or three people. Below that the honest answer is often to buy a tool and wait.

Do we need to clean up our data first? Usually not for the first project. Pick something that runs off information you already hold in one place, and leave the messy work until you have a win behind you.

Will it replace people? In our experience it moves people off the admin and onto the work you hired them for. If a headcount reduction is the actual plan, say so at the start, because your team will work it out anyway and the project will fail quietly if they think they are building their own replacement.

How do we know it is working? Pick the number before you start, then leave it alone for a month after go live. The first fortnight of any new system is noisy and you will draw the wrong conclusion from it.

Where to start

Most AI consulting engagements start with exactly this, so do the cheap version first. Write down every task your business repeated in the last seven days, mark the ones that happen weekly and follow a pattern, and put a rough yearly cost against them. That list is most of what a discovery engagement produces, and it costs you an afternoon.

Then decide whether you need help building the top one or whether you can handle it yourself. Either answer is fine. Knowing which is the point.

If you want a second opinion on that list, book a free call. Thirty minutes, no obligation, and you will leave knowing which of your tasks are worth automating, which are not, and roughly what each is worth. If the answer is that you do not need us yet, we will say so.