1. What we actually solve
These are the five problems we are asked about most, phrased the way the people suffering them phrase it:
- “My team spends half the morning keying supplier invoices into the ERP.” Every supplier sends a PDF in its own format, somebody opens it, types the fields and files the document. It is the process that eats the most hours and the easiest one to measure.
- “Email comes in unsorted and things slip through.” Orders, incidents, quotes and marketing in the same inbox, distributed by hand every morning, with the answer depending on who is in that day.
- “Closing the monthly report takes us three days.” Data exported from three places, pasted into a spreadsheet and formatted by hand, the same every month, with the error risk that carries.
- “Everybody fills in the job sheet their own way.” Information arriving on paper, as a photo or in a message, which somebody has to interpret and enter before anything can be invoiced.
- “The same data lives in four applications and nobody knows which one is right.” Copying and pasting between the ERP, the CRM and the team’s spreadsheets, with the discrepancies surfacing exactly when a decision has to be made.
They all have the same shape: information arriving with no structure, a person interpreting it, and a system waiting for the data already clean.
2. How it works
There is no magic platform that does this. There is a flow built to measure on four pieces, and it is worth knowing what each one does before signing anything:
- Capture. The system picks the input up where it already is: a mailbox, a shared folder, a form, an ERP directory. Nobody is asked to change how things reach them.
- Interpretation. A language model reads the unstructured input and returns specific fields: invoice number, net amount, supplier, incident type, urgency. When the document is an image or a scan, it goes through optical character recognition first.
- Rules and execution. With the data structured, the consequence is carried out by deterministic rules: create the entry, open the ticket, notify the owner, move the file. AI deliberately stays out of this part — rules are cheaper, faster and perfectly predictable.
- Integration and logging. The connection to your ERP or CRM goes through an API, a database or file exchange, whichever the system allows. Everything the flow decides is logged: what came in, what it interpreted, with what confidence and what it did next.
What we build it with
When the process starts from a trigger — an email arrives, a file is uploaded, somebody submits a form — the orchestration can be built using platforms such as Power Automate, n8n, Make or Trigger.dev, depending on where the process lives and which licences you already hold. If your company is on Microsoft 365, Power Automate usually turns out to be free in practice.
When there is no trigger and what is needed is for something to happen at a given time — consolidate yesterday, sweep a mailbox every fifteen minutes, close the month — we solve it with scheduled jobs that wake up a function of our own. It is cheaper to maintain than a visual tool, it does not depend on anybody’s licence, and it leaves the execution log on your side. It is the route by which we are replacing part of what we used to build on flow tools.
Whatever fits neither of those we develop in C#, JavaScript or Python. The choice is not ideological: what decides is which one your system gets along with best and who is going to maintain it afterwards.
On ERPs, a clarification worth making early: we are not specialists in any particular ERP and we do not claim to be. We have integrated with the usual ones in the industrial world, but what we know how to do is talk to the one you already have — read, write and synchronise — not configure or parameterise it from the inside. That is what your implementation partner is for, and we work alongside them without any friction. If somebody promises you both, ask them about the second one.
The piece most often forgotten is the fifth: the review queue. Every case carries a confidence level, and the ones below the threshold do not execute on their own, they wait for a person. That queue is what allows the threshold to be raised over time and what stops you discovering an error three months later.
Put side by side, the change is easier to see. Notice that the input and the destination are the same: what moves is who does the work in the middle.
- InputA PDF, an email or a photo, in a different format every time
- Someone reads it and types it inThis is where the hours go and where the errors appear
- ERP or CRMThe data lands at the end of the day, or of the week
The whole process depends on somebody being available. If it piles up, the invoicing lead time piles up with it.
- InputThe same one, arriving the same way: nobody changes their habits
- The model interprets itIt returns specific fields and a confidence level
- Rules executeDeterministic: same case, same outcome
- ERP or CRMThe data lands within minutes, with a record of what was decided
↳ Cases below the threshold are not executed on their own: they go to a human review queue. They start out numerous and drop as the system is tuned.
The person stops typing and starts deciding on the exceptions, which is where their judgement is worth something.
Both paths run at the same time and on the same time scale: the top one is still on its second step when the bottom one has already finished and is waiting. The proportions are illustrative — what we claim is that one takes considerably longer than the other, not exactly how much longer in your case.
3. Typical cases by sector
Our clients are currently in manufacturing, discrete and process: automotive, food and drink. That is where our track record is and where the examples come from real projects.
The other four are patterns, not published cases. Administrative processes look far more alike across sectors than they do from inside any one of them — a supplier invoice reads the same in a factory as in a law firm — and that is why we include them: we are not limited to a single sector and we do not want to pretend that we are.
Manufacturing: automotive, food and drink
Job sheets and delivery notes arriving on paper or as photos from the shop floor. Nothing can be invoiced until somebody transcribes them, and the transcribing piles up towards the end of the week.
The sheet is digitised on arrival and the lead time between doing the work and invoicing it drops from days to hours.
Distribution and logistics
Customer orders arriving by email, each one in its own format. The order is typed into the ERP by hand and the mistakes are found in the warehouse.
Lines and part numbers extracted automatically, with human review only of what the model flags as doubtful.
Professional services
Receiving and classifying client documentation in accountancy firms, engineering practices and law firms. Hours of qualified staff spent sorting and renaming files.
Automatic classification and filing, and search by content instead of by file name.
Retail and after-sales
Incoming customer email with enquiries, incidents and returns. Manual distribution delays the first response and repeat enquiries tie up the team.
Automatic routing by type and urgency, with a draft reply proposed for the frequent cases.
Administration and back office
Recurring reports assembled by pasting exports from several systems. Two or three days a month of mechanical work, with the copy-and-paste error risk that carries.
The report builds itself from data already reconciled, and the team moves from assembling it to reading it.
4. What you need before we start
Honest requirements. If one is missing, we say so in the assessment and not in the invoice:
- Volume. The process has to repeat many times a month. Below a certain number of cases the project does not pay for itself even if it works perfectly.
- Somebody who knows how it is really done. Not how the procedure says it is done. We need a few hours of that person at the start, and it is the highest-return investment in the whole project.
- Access to the systems or to their data. Credentials, an API, exports or database access. If a system is closed, that has to be known before anything is promised.
- A verifiable definition of correct. There has to be a way of knowing whether the output is right. If there is not, there is no way of detecting when the system starts to fail either.
- Tolerance for error with human review. No system is right one hundred per cent of the time. The process has to accept that a share of cases goes past a person.
- Measurement of the starting point. Current hours per month, number of cases, error rate and lead time. If you do not have them, we measure them before touching anything: without that number there is no way afterwards to show the project was worth it.
5. When this is NOT the answer
Saying no in time saves more money than most projects make. Cases where we advise against automating:
- The process is broken. If nobody knows who owns each step, or everybody does it differently, it has to be redesigned first. Automating a broken process only makes it get things wrong faster and at greater scale.
- The rules are clear and stable. Then classic automation is enough: cheaper, faster and more predictable. Putting a language model in there only adds cost and uncertainty.
- What hurts is the occasional peak, not the routine. A workload spike twice a year is solved with temporary help, not with a project.
- The error is not tolerable. Where getting it wrong has serious and irreversible consequences, the system can propose, but a person decides.
- The process is about to change. If an ERP migration or a regulatory change is on the table, better to wait: automating something that will disappear in three months is throwing money away.
6. How the return is measured
An automation project is justified with four metrics, all of them compared against the starting point:
- Hours freed per month and their equivalent cost. It is the direct saving and the easiest one to defend to the board.
- Error rate before and after, and the cost of each error: rework, credit notes, penalties, lost customers.
- Process lead time end to end. It is often worth more than the hours saved, because it unblocks invoicing.
- Capacity: how many more cases can be absorbed without hiring anybody.
As a reference from our own projects: around 20 hours a month per employee on the tasks we automate, the first automation in production in two to four weeks, and payback under six months on the first project. This is not a promise: the result depends on the scope and the starting point of each company, and the number that matters is the one that comes out of measuring your own process. The full method, phase by phase, is in how the return is measured in the guide.
7. If the process handles personal data
Almost all of them do: a customer email, an invoice with a name and a tax number, or a job sheet with an operator’s name are already personal data. That does not stop you automating, but it changes the design.
We classify every use case by risk level under Regulation (EU) 2024/1689 before development starts, and apply the obligations that follow along with those of the GDPR. Most internal administrative processes sit at the transparency level rather than the high-risk one; the usual exceptions are recruitment and worker evaluation, which do fall under high risk and require considerably more. Data is not used to train third-party models and, where necessary, the solution is deployed on your own infrastructure.
The application timetable and the specific obligations are on the AI compliance page, which we keep up to date every time the regulation changes.
Note: this page is for information only; it is not legal advice nor a guarantee of results. The figures quoted are usual ranges in real projects, not contractual commitments, and they depend on the scope and the starting point of each company.
8. Frequently asked questions
Which business processes can be automated?
The ones that repeat many times a month, eat qualified time on mechanical tasks and allow a verifiable definition of correct. The most common are entering invoices and delivery notes, classifying and answering incoming email, preparing recurring reports, document management and moving data between applications. The input does not have to be identical every time: that is precisely where AI adds what classic automation cannot.
How much does it cost to automate a business process?
It depends on the scope, on how many systems have to be connected and on how orderly the starting process is. We always begin with a free 30-minute assessment and a fixed price before starting, never open-ended hours. As a reference from our own projects, the first automation usually pays for itself in under six months, because the saving is direct: qualified hours that stop going into mechanical tasks.
How long until the first automation is running?
Two to four weeks for a well-scoped process, counting from the map of the current process to going live with supervision. The projects that take longer are usually the ones that start with the company’s most complex process instead of its most repetitive one.
Do we have to change our ERP or CRM to automate?
No. The automation is built around the systems you already use and connects through an API, a database or file exchange, whichever the system allows. Changing ERP in order to automate a process multiplies the cost and the risk of the project tenfold. And the usual clarification: we are not specialists in any particular ERP. We know how to talk to the one you have — read, write and synchronise — not to parameterise it from the inside; that is your implementation partner’s job and we work alongside them without friction. If a system exposes no way in, we say so before starting rather than halfway through.
What is the difference between automation, RPA and artificial intelligence?
Classic automation and RPA run deterministic rules: if a condition is met, an action fires. They work very well as long as the input always has the same format, and they break as soon as a variation appears. AI adds the missing layer: interpreting unstructured input — a supplier PDF, an email, a photo — and using judgement in ambiguous cases. In practice almost every project combines both: AI interprets, rules execute.
What happens if the automated system gets it wrong?
It is designed on the assumption that it will. Every case carries a confidence level: the ones below the threshold do not run on their own, they go to a human review queue. Everything the system decides is logged, so what happened can be audited and quality degradation can be spotted. An automated process with no supervision and no log is not a saving, it is deferred risk.
What technologies do you automate with?
It depends on how the process starts. If an event triggers it — an email arrives, a file is uploaded, somebody submits a form — the orchestration can be built using platforms such as Power Automate, n8n, Make or Trigger.dev, depending on where the process lives and which licences the company already holds: if you are on Microsoft 365, Power Automate usually turns out to be free in practice. If there is no trigger and what is needed is for something to happen at a given time — consolidate yesterday, sweep a mailbox every fifteen minutes, close the month — we use scheduled jobs that wake up a function of our own: cheaper to maintain than a visual tool and not dependent on anybody’s licence. Whatever fits neither of those we develop in C#, JavaScript or Python, according to what your system gets along with best and who is going to maintain it afterwards.
Can processes that handle personal data be automated?
Yes, while complying with the GDPR and Regulation (EU) 2024/1689 on artificial intelligence. We classify the use case by risk level before development: most internal administrative processes sit at the transparency level rather than the high-risk one, with clear exceptions such as recruitment or worker evaluation. Your data is not used to train third-party models and, if you need it, the solution is deployed on your own infrastructure.
Services that usually go with this one: systems integration · AI agents.