AI for SMEs: where to start when you have no technical team

Implementing AI in SMEs looks nothing like the version told at conferences. There is no data science team waiting for instructions, no data lake, and the person who knows most about systems is also the one running invoicing. None of that rules out doing serious work with AI: it only changes the order things have to happen in, and the size of the first bet.

This guide is written for a company of 10 to 150 people that bills well, has processes that grind, and has heard one too many times that "AI would fix this". It is about deciding: what can be attempted without a technical team, what it really costs, what has to be ready beforehand, and at what point it makes sense to stop.

What does implementing AI in an SME actually mean?

It means putting one or two specific tasks into production with model support, integrated into the tools you already use, with someone accountable when they fail. Nothing more. It does not mean "transforming the company", building a platform, or putting a chatbot on the website because everyone else has one.

The difference between an SME and a large company here is not talent: it is margin for error. A multinational can afford three pilots that go nowhere because an innovation budget absorbs them. An SME that burns €25,000 and six months on a project that never leaves demo stage will not try again for two years. That is why the selection criteria matter more than the technology.

Three traits make a case fit an SME well:

• Repetitive, boring volume. Something a person does 50 times a week in exactly the same way: sorting emails, pulling data off delivery notes, answering the same eight questions.
• Data that already exists somewhere. In the ERP, the document manager, the info@ inbox. If the answer is "we'd have to start recording it", the case slips by six months.
• A tolerable error. If the model gets it wrong, someone catches it before it reaches a customer or the tax office.

An SME's first AI project does not have to be the most profitable one. It has to be the one that finishes.

Where do you start without a technical team?

With a friction inventory, not a tool catalogue. Sit down with the three or four people closest to the operation and ask one question: what do you do every week that feels absurd to have to do? In two hours you will get fifteen to thirty tasks. That is your real starting point, and it costs nothing.

Then filter with four columns: frequency, hours per month, who does it, and what happens if it goes wrong. Anything under four hours a month gets dropped however annoying it is — no return justifies the maintenance. Anything that creates a legal or contractual problem when it fails goes to the second round.

From what is left, pick one. Just one. This is the hardest part, because there is always the temptation to open three fronts at once and "make the most of the momentum". What actually happens is that none of them gets enough attention and all three die in testing — exactly the pattern described in why AI pilots fail.

With no internal technical team you have three routes, and it pays to be honest about what each one implies:

| Route | Good fit for | Typical cost | Main risk | |---|---|---|---| | SaaS tool with built-in AI | Standard cases: email, support, simple documents | Monthly per-user subscription | Falls short as soon as your process has its own exceptions | | Connector-based automation (low-code) | Flows between the apps you already run | Low licence cost + configuration hours | Nobody documents the flow and it breaks when an API changes | | Custom integrated development | When the process is your differentiator or touches sensitive data | Fixed project + maintenance | Overbuilding the first version |

The sensible move in an SME is to start with the first two and save the third for when you already know the case works and it is the tool, not the idea, that is failing.

What does AI for SMEs really cost?

The licence cost is the visible one; it is also the one that matters least. A small AI project in an SME has four cost lines, and the first usually comes as a surprise:

• Your own people's time. Someone inside has to explain the process, grant access to systems, review results and decide. Between 15 and 40 hours in the first weeks. If nobody has those hours, the project is not ready to start.
• Data preparation and access. Cleaning, exporting, connecting. Almost always more than planned.
• Licences and usage. Subscriptions and, where models are billed per use, a variable cost worth capping from day one.
• Maintenance. Nobody budgets it and everybody pays it. Count on 15 % to 25 % a year of the amount invested just to keep it working when formats, vendors or people change.

A well-scoped first case in a European SME sits in the low thousands of euros, not the tens of thousands. If the first proposal you receive runs to five figures before anything has been validated, you are not buying a project: you are buying a platform. And it is still too early for that.

A practical rule: the budget for the first case should not exceed what the current process costs over six months. If automating something that costs €300 a month in labour quotes at €12,000, the maths does not work however good the demo looks.

Which processes should an SME automate first?

The ones involving paper and inboxes. In almost any mid-sized company, the same handful of cases comes up again and again:

Document reading and classification. Supplier invoices, delivery notes, orders arriving as PDFs. The model extracts the fields, checks them against the order and only flags discrepancies. It is one of the best effort-to-return cases and it has a natural safety net: if extraction fails, the document falls into the usual manual queue.

Answering repeat questions. Lead times, order status, terms, opening hours. Before building anything, look at the inbox history: if 60 % of emails are eight questions, you have a case. If they are a hundred different questions, you do not. We cover this in chatbots for business.

Preparing quotes and proposals. Finding precedents, filling templates, checking rate cards. The person still sets the price; they just stop losing 40 minutes hunting for last year's similar quote.

Operational summaries and notes. Sales calls, service incidents, production meetings. Cheap to build, easy to abandon if nobody reads them: check first that someone actually will.

Prioritising a list. Which overdue invoices to chase first, which customer looks likely to churn, which order to review. It does not replace judgement: it orders the queue so judgement gets applied where it counts. There are more examples by sector in AI use cases by industry and the general framework in AI process automation.

What do you need in place before you start?

Less than you will be told, but not nothing. Four things cannot be skipped:

• A named owner. Someone inside who decides, tests and is willing to say "this isn't good enough". They do not need to be technical; they need authority over the process.
• Access to the data you already hold. Knowing who can export from the ERP and with what permissions. This is usually the real bottleneck, not the model.
• A success criterion written down before you start. "80 % of invoices go through untouched", not "improve efficiency". With no number, impressions always win and the project always loses.
• A quick personal data review. If the process touches customer or employee data, you need to know where it is processed and on what legal basis before connecting anything. That is half an hour well spent, not a formality; we go into detail in GDPR and AI.

What you do not need: perfect data, a completed data strategy, or unified systems. That comes later, when the first case proves the plumbing is worth investing in. The order matters, and we explain it in data before AI.

What does a realistic 90-day plan look like?

You need no longer than that to know whether this works in your company. Any less and there is no time to measure; any more and the interest fades.

| Weeks | What happens | Tangible output | |---|---|---| | 1–2 | Friction inventory and case selection | One task chosen, with hours/month and an owner | | 3–4 | Access, sample data and success criteria | Written agreement on what counts as "it works" | | 5–8 | Build and testing alongside the current process | Results comparable against business as usual | | 9–12 | Go live with supervision and measurement | Decision: keep, adjust or stop |

Week 12 has to end in an explicit decision, including the decision to stop. A case dropped in time with the learning documented is a good outcome; the expensive one is the zombie project nobody uses and nobody cancels.

The mistakes that cost SMEs most

Starting with the tool. Buying licences before knowing which task you are attacking guarantees you end up bending the process to fit the tool.

Picking the flashiest case. The one that looks good in a meeting is usually the one that depends most on data you do not have.

Not counting internal hours. The project looks cheap until someone adds up what the operations lead has spent on it.

Measuring by feel. Without a baseline — what it costs to do by hand today — any result can be defended and none can be proven.

Leaving it ownerless at go-live. When the vendor leaves, someone has to review the errors every week. If that is unassigned, the system degrades quietly.

Frequently asked questions

Can an SME implement AI without hiring technical staff?

Yes, for the first case. You need an internal owner with judgement about the process and a vendor who integrates with your tools. Hiring a technical profile makes sense once three or four automations are in production and someone has to maintain them.

How long before you see a return?

If the case is well chosen, two to four months from kick-off. Document cases tend to be fastest because the saving is measured in direct hours. If a vendor promises a return in three weeks, ask what baseline they are calculating against.

Is it safe to use AI with customer data in an SME?

It depends on where the data is processed and what contract sits behind it. You need to review the processing agreement, where data is stored and whether it is used to train models. It is a few hours of prior review, not an insurmountable obstacle.

What if the project does not work?

You stop it in week 12 and walk away with the process map, the access questions resolved and evidence of what is missing. That is why the first case should be small: the cost of being wrong has to be affordable by design.

---

If you are at the point of having fifteen ideas and no certainty about which one holds up as a project, that is exactly the conversation the audit is for: looking at your real processes and data and coming out with one or two prioritised cases, with their cost and their success criteria. And if you would rather test the thinking in half an hour first, let's talk — no strings attached.