There is no universal answer to this question, and any consultant who tells you that you definitely need them before hearing a single detail about your business is not being straight with you. Some businesses can get a lot of value from AI without any outside help at all. Others will waste months and real money without it. The difference comes down to what you are trying to do, not how complex or capable your business is.
This article is an honest attempt to help you work out which category you are in.
What you can genuinely do yourself
A large portion of what people call "using AI in your business" is simply picking up off-the-shelf tools and using them for personal productivity. That does not require a consultant. It requires a bit of time and a willingness to experiment.
If you want to use ChatGPT to draft emails, summarise documents, or think through a business problem, you can start today at no cost. If you want Microsoft Copilot to help your team work faster in Word and Excel, that is a subscription decision, not a consulting engagement. Notion AI, Grammarly, Otter.ai for meeting notes: all of these are tools you can evaluate, trial, and adopt without any external input.
Automation platforms like Zapier and Make fall into the same category for straightforward workflows. If you want to automatically copy a new row from a Google Sheet into your CRM, or send a Slack notification when a form is submitted, these platforms are built for non-technical users and their documentation is good. A technically-minded person in your team can usually pick this up without help.
The DIY route works when:
- The tools you need already exist and are designed for your use case.
- The workflow is simple: one trigger, one or two actions, standard data formats.
- You have someone in the business with the time and inclination to learn and maintain the setup.
- The cost of getting it wrong is low. A broken Zapier workflow that stops running is annoying. It does not cause data loss, client problems, or hours of rework.
Where it usually goes wrong without help
The failure pattern I see most often is not a technology failure. It is a scoping failure. Someone picks a tool before they have properly understood the process they want to fix, and then discovers that the tool does not quite fit, the data is not in the right format, or the workflow has an edge case the tool cannot handle. The fix becomes a workaround. The workaround creates its own problems. Six months later the tool is barely used and everyone has gone back to doing it manually.
The most common failure mode in SME automation projects is almost never a technology problem. It is a scoping problem. Someone jumped to a solution before they understood the process well enough.
The cost of a failed implementation is typically two to three times the original cost. Not just the money spent on the tool. The time your team spent learning it, configuring it, and working around its limitations. The time you spent making the decision. The disengagement that follows when a project does not deliver what it promised. People in your business become sceptical of the next attempt, which makes the next attempt harder to land even if it is a better idea.
That multiplier is not theoretical. It shows up in almost every business that has tried to introduce technology without first making sure the process underneath it is properly understood.
The signs you probably need external input
None of the following are signs of a poorly-run business. They are just honest indicators that the DIY route is likely to cost more than the alternative.
- Your process involves multiple systems. If making one thing work requires connecting your CRM, your accounting software, your job management system, and a spreadsheet that someone updates manually, you are in integration territory. Zapier can handle some of that, but once you have more than three or four systems and data needs to flow in multiple directions, the complexity scales quickly and errors become hard to trace.
- Off-the-shelf tools do not fit your specific process. Generic tools are built around common workflows. If your workflow has been shaped by your industry, your clients, or your own way of running the business over years, there may not be a tool that fits it without compromise. Forcing your process into a generic tool's structure usually means accepting limitations that cost you time elsewhere.
- You have tried tools before and they have not stuck. This is the clearest signal. If your team has trialled something, decided it was not quite right, moved on, and the cycle has repeated a couple of times, the problem is usually not the tools. It is that no one has clearly defined what a good outcome looks like, what the process should actually be, and what success would need to look like for the tool to justify keeping.
- You do not have time to evaluate options properly. Choosing the right tool for a specific process takes longer than most people expect. You need to understand your own process first, then find the candidates, then trial them with real data, then assess the results honestly. If you are running a business and that evaluation gets squeezed into an hour here and there, you will almost certainly end up with the most-marketed option rather than the right one.
- You want an honest view before committing budget. Sometimes the most valuable input is someone telling you that what you are planning is not worth the money, or that there is a cheaper way to get 80% of the result. That is harder to get from a vendor, who has an obvious interest in you proceeding.
Advisory vs build: two different things
It is worth separating these, because a lot of people assume that calling in a consultant means handing over a project and getting a bill. That is one model. It is not the only one.
Advisory-only means getting a clear picture of what is worth doing before you commit to doing it. That might be a single conversation. It might be a structured process audit that maps your manual tasks, scores them by automation potential, and produces a ranked list with cost and time estimates for each. The output is clarity: which problems are worth solving, in what order, and roughly what each option would cost. You then decide what to do with that, including doing it yourself.
Advisory plus build is the fuller engagement, where the consultant stays involved through scoping, tool selection, configuration, testing, and handover. This makes sense when the implementation is technically complex, when integrations are involved, or when you want the risk of the implementation sitting with someone other than you.
Most businesses I speak to benefit from advisory-only first. Getting the scoping right is where the value is. The build itself is often more straightforward once you know exactly what you are building and why.
The cost of getting it wrong
People often frame the question as: is it worth paying a consultant, or can I save that money by doing it myself? The more useful question is: what is the likely cost of the alternative?
A failed tool implementation in a business with ten to fifty people typically costs somewhere between five and fifteen thousand pounds when you account for the time of everyone involved, the sunk cost of the tool, and the opportunity cost of the work that did not happen while the project absorbed attention. That estimate is conservative if a developer was brought in to configure something that turned out to be wrong from the start.
A scoping conversation costs nothing. A proper process audit, done externally, costs a fraction of a failed build. The question is not whether the consulting fee is justified in isolation. It is whether the fee is justified against the risk it removes.
If you want to work out which category you are in, book a free 30-minute call. No obligation. No pitch. Just a straight conversation about your situation.
Sources
- British Chambers of Commerce, "The Turning Point for SMEs", September 2025
- DocuSign Digital Maturity Report, 2024
- Sage, "13 months of work, 12 months of pay", May 2025