You run a company and see the same bill every month: three employees who together spend around 60 hours a week copying between Excel, the ERP and email. Two of those positions exist because a department grew. One exists because the system never properly connected two sites. That isn't an AI problem. It's a process problem, and with the right automation it goes away in weeks. The only question is where the lever is.
This article explains how we find it: the process first, then the costs, then the question of whether rules are enough or whether it takes AI.
1. A business process is a chain of handovers
A business process covers every step needed until a customer gets what they ordered. You distinguish the end-to-end process from its sub-processes. Take purchasing:
- Demand planning
- Purchase request
- Supplier selection
- Order
- Sub-processGoods receipt
- Invoice check
- Payment
Every arrow in this chain is a handover: from one person to the next, from one system to another. That's where the time goes, not inside the boxes.
2. Where process costs come from
Process costs are everything one run costs: staff time, material, and the indirect costs of waiting, errors and rework. In our audits we keep seeing the same four spots where most of it sits:
- Purchase requestForm by email, re-keyed
- Supplier selectionPrices in Excel next to the ERP
- Order
- Goods receiptDelivery note matched by hand
- Invoice checkWaiting for approval
- Payment
What these four spots share: a piece of information already exists but gets entered, compared or passed on once more. How much that costs depends on the process, and it can be measured. Before we automate anything, we count: how often the process runs, how long each handover takes, how often something goes wrong. Without those numbers there is no "after" later.
3. Process optimization means: understand first, build second
Four things happen before any technology decision:
- Mapping: We walk through the process with the people who do it every day. Not with the org chart, but with the clerk who knows why the Excel next to the ERP exists.
- Measuring: Cycle time, frequency, error rate per step. From samples, not estimates.
- Cutting: What is entered twice gets entered once. What nobody reads is no longer produced. Often that's half the optimization, without a line of code.
- Only then automating: And specifically the step where little effort achieves a lot.
That's why we start with an audit when it's unclear where the lever is: two weeks, one document, sorted by effort and impact.
4. Automation: when rules are enough
Most handovers don't need AI. They need a connection between two systems and a rule: when a delivery note arrives, match it against the order. When an invoice is approved, post it and archive the document.
There are tools built for exactly that: APIs, webhooks, workflow systems like Zapier, Make or self-hosted n8n. Rule-based automation is cheap, traceable and easy to check. It has one limit: it needs structured data. A field with an amount, a date, an order number. As soon as the information sits in a PDF, an email or free text, the rule stops working.
Beyond a certain number of workflows it's also worth looking at the bill: Zapier and Make charge per run. When switching to a system of your own pays off is something we've worked through elsewhere.
And there is a second limit that has nothing to do with data: click-built workflows are quick to make but hard to check once they grow. No comparison between two states, no tests, debugging in the browser. You notice it at 40 workflows; at 200 you pay for it. So as soon as a step reads free text, makes decisions or works with agents, we build in code, on eve: every change is documented and comparable, every run has tests and a log, an error can be traced to the line, and a rollback is switching back to the previous state.
5. Where AI does more than rules
AI comes in where the rule fails: with unstructured data and with classification. A language model can pull the amount, date and order number out of a supplier email. It can read a tender and say whether it matches a firm's profile. It can carry a product text into seven languages while sticking to a glossary.
| Task | Rule is enough | Needs AI |
|---|---|---|
| Match delivery note against order | Yes, if both exist as records | If the delivery note comes as a scan |
| Approve and post an invoice | Yes, after approval | No |
| Route incoming emails to the right process | Only with fixed subject lines | Yes, with free text |
| Sort tenders by fit | Only by keyword, with many false hits | Yes, with the company's profile as the yardstick |
| Translate and check copy | No | Yes, with a glossary and a check afterwards |
Two examples from our projects:
Tenders at an engineering firm. Several employees reviewed notices on TED and the German procurement portal every day, classified them and wrote application documents. A keyword filter wouldn't have helped, because it doesn't know what the firm actually builds. The prototype we built works with the firm's profile: references, staff skills, partners, target contract sizes. A language model classifies new notices against it.
- Before, per the firm's owner
- 10 hours
- With the prototype
- 30 minutes
Projection: the owner's stated figure against the review time for filtered hits measured in the prototype. The firm did not commission the full build. Details and assumptions in the use case study.
The full calculation with every assumption is in the use case study on tender acquisition.
Translations in a Shopify store. At LOULEX a bot of our own translates whatever is missing or outdated in the shop every hour, into seven languages. The language model translates; the rules before and after make the difference: a glossary that protects brand terms, a check that catches broken placeholders, a log that lets any run be rolled back. The external translation service at €299 a month has been cancelled.
Neither is an "AI project". They are processes in which one step needs AI and the rest needs rules.
6. What goes wrong, and what we do about it
- The data is worse than expected. A model reading bad scans produces bad numbers. So we start with a sample of real documents, not test data.
- Nobody checks. Wherever a number goes into the books or a text goes into the shop, a person signs off, or the system limits itself. The LOULEX bot processes at most 5,000 words an hour and stops when findings pile up.
- The team isn't brought along. The clerk who maintained the Excel knows best which edge cases the system has to handle. She sits in our kickoff, not in the training at the end.
- No before, so no after. Without a measurement before the start, nobody knows whether it paid off. We measure first.
- Built once, never touched again. Processes change. Whoever automates needs monitoring and someone who stays on it. That's part of the handover, not an afterthought.