Tech innovation in SMEs that shows up in real work

Technological innovation in SMEs starts with the work that does not change

Technological innovation in SMEs becomes visible when a task that someone currently redoes by hand becomes a step in the software, following the same company rules, with a person checking the result. It does not coincide with purchasing a new tool, nor with a feature presentation. It starts from the process that steals hours, is limited to a useful slice, goes into production, and is judged in the field. Only afterwards, if that piece holds up, does it extend to the rest of the work.

In many businesses the management system exists, the inbox is full of attachments, and spreadsheets hold the exceptions. A new colleague finds prices and statuses scattered around, steps with no trace, fields filled in different ways. What matters is not how many programs are installed. What matters is whether an order or a quote is created already complete, without a second transcription.

New tools in the company, workday still the same

The workday stays the same when the new software does not carry out the step that a person used to perform, and that person continues to copy data from one system to another.

The symptom appears after a few weeks. The management system is running, a module has been activated, and the team goes back to its old habits. It is not a rejection of technology. It is the real work, with exceptions the tool does not know about: a discount tied to a job site, a variant outside the price list, a document to recheck before it goes out.

Technological innovation in SMEs stalls silently right here. The licences are paid for and time is still spent on transcription. Digitalising a business process in an SME means rewriting that step so the software can carry it out. An extra screen, alongside the manual work, does not shift the workday.

Those who have bought software and still work by hand

Those who already have a management system and still prepare quotes, confirmations, or summaries on a spreadsheet live this situation. The program covers the standard case. The everyday case, with an unwritten internal rule, is left out. Time does not shift: it doubles, because now both the spreadsheet and the management system need to be updated.

Those who keep exceptions in emails and messages

In other businesses the right decision sits in a message, not in the data. The sales rep writes, the manager responds verbally, the operator reconstructs the step the next day. A new dashboard does not resolve this bottleneck, as long as the confirmation has no place in the flow and no trace that can be read back.

Finding the bottleneck in the task that repeats

The bottleneck is the task that the team redoes with the same sources, the same checks, and the same risk of error, and that no one has yet counted in hours over a typical week.

A map of the entire company is not needed. What is needed is one week observed closely: who opens which screen, where they copy from, where they wait for a colleague, which step gets redone because a piece of data was missing. Often the problem is not where it seemed. It looks like invoicing, and it turns out to be the collection of job-site data. It looks like the catalogue, and it turns out to be the incomplete record that someone fixes by hand before publishing.

During the observation week, note four things without turning it into an endless project: which piece of data is most often missing; who knows it; how many times the step gets redone; and which error, if it surfaces, costs a phone call to the client or only an internal inconvenience. With these notes the scope fits on one page.

An illustrative example: a company that prepares job-site quotes. The line items repeat, but discounts, notes, and variants stay on a spreadsheet because the management system does not calculate them. This is not a measured result and it is not a showcase name. It is the kind of friction that makes sense to start from, before talking about technology.

• Quotes that always start from the same sections and change only quantities, discounts, and notes.
• Orders that pass through email, spreadsheet, and management system before becoming a single document.
• Records in which price, availability, and description do not match one another.
• Requests answered by searching for the same information in three places.
• Summaries reassembled every month-end because the systems do not communicate.

Those who redo the same document every week

Those who prepare quotes, bills of materials, or confirmations with a fixed structure and few variables have the clearest candidate. The document is not a creative text: it is a sequence. If the sequence is stable, it can be described and the repetitive part can be handed to the software. The person retains control over the choices that are costly when they go wrong.

Why generic software does not follow the rules of the process

Generic software does not show up in the work because it applies an average process, while the company runs on exceptions that exist only in the minds of those who carry it out every day.

Real processes have their own rules. A ceramics workshop does not calculate a quote the way a construction firm does, and an online shop does not update its records the way someone who sells by project does. The off-the-shelf program covers the manual's case. As soon as the rule falls outside that case, someone compensates by hand and the change never reaches the office.

There is no need to discard what already works. The point is to understand where the management system is sufficient and where internal rules call for software built around that process. The topic is related to when it makes sense to change or integrate the management software, and to when off-the-shelf programs hold back a manufacturing SME.

A process is digitalised when its rules, including those that today exist only in the mind of the person who carries it out, become steps in the software and remain verifiable by a person.

Those who have internal rules that no catalogue anticipates

Those who apply discounts by product family, timelines tied to the job site, or a check before sending will not find those rules in a standard module. Forcing them into generic fields produces incomplete data and a second register. Custom software for an SME is built from those rules, not from a feature list that is the same for everyone.

An illustrative example: a craftsperson who sells ceramics and manages around forty references. Glaze and size variants are, in the workshop, the same form with a note. In the management system they become different products, and someone realigns text and availability by hand before publishing. Here too there is no outcome to measure: there is a misalignment to write down, before choosing a tool.

Starting from a single process, in pure code and verified

The starting point is choosing a single repetitive process, writing down its real steps, and putting a small slice into production, with a person who verifies the result before widening the scope.

The order matters. Process first, then technology. The first conversation serves to understand what is done today, who does it, how much time it takes, and where it breaks down. If a piece is not worth automating, that should be said upfront, not afterwards. Automating everything at once produces a long project, visible only at the end, when corrections cost more.

Pure code, written for the application and its environment, holds these rules together. It is not a prototype to show and then abandon. It is software designed for production: data, interface, infrastructure, repeatable deployment, backups and recovery, and ongoing observation. The automation of repetitive processes lives in that system, not in a connection the company does not control.

If an agent that acts on data is introduced, supervision is not optional. The agent works, a person observes and corrects, and autonomy grows only where the behaviour has proven reliable. For sensitive actions, such as sending a document or modifying data that cannot be recovered, human confirmation remains in place. Those without an IT manager can follow the same method: we also discuss this in the guide on process automation without an IT manager.

1. Write the process as it is today, step by step, including the exceptions.
2. Choose the slice that steals hours and that can be judged in production.
3. Decide what stays in people's hands and which actions require confirmation.
4. Put that piece online, with a trace, backups, and recovery.
5. Extend only after seeing the edge cases, not before.

Those who have little time for routine and no technical contact

Those who manage the office as well as the operational work do not have half-days to compare dozens of products. The first step is to isolate the task that repeats, bring together those who carry it out, and ask for a clear scope: what is automated, what is not, which systems need to communicate. From there it becomes clear whether the digitalisation of business processes, in that SME, has a useful starting point or only a wish list.

Leomat builds software around the process, not around the presentation

Leomat designs custom web applications and the environment in which they run, with agents under human supervision, and starts from the process you want to remove from manual work.

The studio, based in Naples, delivers the software and everything that makes it work in production: application, infrastructure, deployment, security, and monitoring. It starts with the discovery of the process, before writing any code. Then come architecture, application and environment, security designed from the outset, human oversight, deployment, and ongoing observation. Artificial intelligence enters as a multiplier. Architecture, quality, and security remain choices verified by a person.

Security is not added at the end. It is designed against public frameworks, including OWASP for the web and MITRE ATLAS for artificial intelligence systems. In practice, one client's data does not end up in another client's context, actions that cannot be undone require confirmation, and what the system does remains traceable. There is no lock-in to a single model provider: the model suited to the task is chosen, the result is evaluated, and a fallback plan is kept in place.

The timelines for a new project are not declared before the process has been seen, because they would be invented numbers. It starts from a small, useful slice that goes into production quickly and is judged in the field.

The first conversation and the scope proposal are not charged for. If you want an approach, an architecture, and a real estimate, without inflated promises, you can speak with Leomat and describe the process that is currently taking up time.

Frequently asked questions

Where to start with digitalisation if a management system is already in place?

Start from the task that the management system does not carry out and that someone completes by hand. Write down the real sequence, including the exceptions, and choose a slice that can be put into production and judged in the field. Adding another tool alongside the management system, without aligning the data and without a person who verifies, usually leaves the workday unchanged. The criterion is not how many features are missing. It is which step steals hours and can be scoped without stopping the rest of the work.

Does automating repetitive processes require an IT manager?

No. What is needed is a person who knows the process and a technical counterpart who translates it into software, with a written scope. Those without an internal IT manager can still get started, provided it remains clear what the system does, what a person confirms, and where the data ends up. Actions that cannot be undone do not run autonomously on day one. Autonomy grows only where the behaviour has been observed and corrected on edge cases, not on an isolated trial.

When does custom software make sense for an SME?

It makes sense when the process rules do not fit into an off-the-shelf product and the team compensates every day with spreadsheets, emails, and manual recopying. It does not make sense if the need is already covered by the management system and only training is missing, or if the task changes every time and has no stable sequence. An honest conversation says so upfront: sometimes a piece is not worth automating. An early refusal is better than a long project, visible only at the end, that does not free up even one hour in the office.

How can you tell whether the change is actually noticeable?

Look at the task chosen at the start, not the number of tools running. The change is noticeable if that step no longer requires a second transcription, if exceptions have a place in the flow, and if a person can verify the result without reconstructing the history from scattered messages. A presentation is not enough. What is needed is the piece in production, used by those who used to do the work by hand, for long enough to encounter the edge cases. If those people go back to the spreadsheet, the process has not yet been rewritten.

This post was created with AI