The question to ask before the tool question
Almost every automation project that fails in an SME began with the choice of a tool. It makes sense, it is the visible part, and it is the only part a salesperson can help you with. It is also the least decisive part. The question that decides the outcome sits elsewhere: which process, precisely, and why that one.
A process deserves automation when it meets four simple conditions. It is repetitive, so the gain multiplies. It is describable, so someone can explain its decision rule without saying "it depends". It is measurable, so you will know whether it worked. And it is stable, so the automation will not need redoing in three months because the procedure changed. A process that fails one of these conditions is not a bad candidate forever, it is a bad candidate right now.
Spotting the real deposits in an SME
The most profitable deposits are rarely the ones mentioned in meetings. Here is what we find at most of the SMEs we support, in decreasing order of profitability.
- Re-keying between two tools. Someone reads information in one place and copies it into another. It is the number one deposit, because the gain is immediate, the risk zero and the decision rule non-existent.
- Collecting and sorting incoming information. Emails, forms, documents, alerts. The work is not deciding, it is sorting before deciding. A machine sorts better and never gets tired of it.
- Producing repetitive documents. Minutes, periodic reports, standard quotes. The content varies, the structure does not.
- Internal information search. Finding the right procedure, the right contract, the right version. It is invisible time because it is scattered in slices of a few minutes, and it is often the biggest total on the list.
- Follow-ups and reminders. Everything that consists of remembering that someone needs chasing.
A simple method to quantify: take the task, multiply the unit time by the annual frequency and by the number of people involved. A 10-minute task, 3 times a week, for 4 people, represents about 100 hours a year. It is an order of magnitude, and an order of magnitude is enough to prioritise.
The sequence that works
- Describe before automating. Write the process down as it really is, not as it should be. The difference between the two is usually the real subject.
- Simplify before tooling. One step in three generally disappears at this stage. Removing a step costs zero euros of maintenance; automating it costs money every year.
- Automate a narrow scope. One case, one department, one source. The temptation to fold in the edge cases right away is what turns a three-week project into a six-month one.
- Put the human where they decide. An automation that proposes and a human who validates is a system people adopt. An automation that decides alone on a sensitive subject is a system people unplug at the first incident.
- Measure and expand. The gain observed on the first case funds and legitimises the next ones. Without measurement, every new case starts over from a debate of principle.
What AI changes, and what it does not
Classic automation knows how to execute rules. What it never knew how to do is handle language: understanding a badly written email, summarising minutes, classifying a request phrased in everyday words. Language models remove that lock, and it is a real change of scale for an SME, because most of an SME's information is unstructured text.
On the other hand, AI changes nothing about three things. It does not make a fuzzy process reliable. It does not replace data that does not exist. And it introduces a new uncertainty: a model can be confidently wrong, which a script never is. The practical consequence is that an AI treatment must always be designed with an exit door, that is, a case where the system says "I don't know" and hands over.
The mistakes that come back most often
- Starting with the most complex case to prove it works. It is the best way to prove the opposite.
- Automating without an owner. Without someone who has the mandate to arbitrate, the project stops at the first disagreement between two departments.
- Not planning for failure. What happens when the API is down, when the file arrives empty, when the format changes? A workflow without error handling produces silent damage, which is worse than a visible outage.
- Creating a dependency. If nobody in-house can open and understand the automation, you bought a black box, not an asset.
- Confusing pilot and production. A working pilot demonstrates feasibility. Going to production means robustness, incident recovery, logging and training. That is where most of the work lives.
How long it takes and how much it costs
For an SME starting from a blank page, a realistic first use case fits within the quarter: one to three weeks of scoping and diagnosis, then two to five weeks to build and put into production. We observe an average of 13 days between a validated Proof of Concept and an MVP actually running, on a deliberately narrow scope.
On budget, serious scoping sits between €3,000 and €5,000 excl. VAT, and putting a first use case into production between €8,000 and €15,000 excl. VAT. These amounts only matter relative to the deposit quantified at step 1: if the targeted task represents 100 hours a year and the automation saves 80 of them, the maths do themselves. If you cannot quantify the deposit, that is the sign you should start there.
Frequently asked questions
Do you need an IT department to automate your processes?
No. Most of the SMEs we support have no dedicated IT department. What you need is an internal owner who knows the business and has the mandate to arbitrate. Technical skills can be outsourced; knowledge of the process cannot.
Which process should you start with when everything seems urgent?
The one that combines the best ratio between quantified gain and simplicity of rule. In practice, it is almost always re-keying data between two tools. It is not the most impressive one, it is the one that produces a visible result within weeks and funds what comes next.
How long before you see a real gain?
Count on a quarter for a first use case in production in an SME starting from zero: one to three weeks of diagnosis, then two to five weeks of build. The gain is then measured over a few weeks of real use, not on launch day.
Does automation eliminate jobs?
In the projects we run, it eliminates tasks, not jobs. The profitable deposits are tasks nobody claims: re-keying, sorting, follow-ups. The real issue in an SME is rather the opposite, absorbing a growing workload with a constant headcount.
Have a process in mind?
Twenty minutes are usually enough to say whether it can be automated, what it would cost and what it would save. If the answer is no, we will tell you.
Book a free diagnostic