The work between the systems
Hardly any process in a mid-sized business lives in one system. The enquiry arrives by email, the case belongs in the CRM, the costing sits in the ERP, the document has to reach accounting. Every one of those boundaries is crossed today by a person reading data in one window and typing it into another.
That work appears in no report, because it is nobody’s assigned task. You notice it as a delivery address spelt differently in two systems, a confirmation that went out twice, or the colleague whose “quick copying over” nobody else knows how to do when they are off. It is where the mistakes come from, and it is where your teams lose the most time, which is why we start there.
Rule, model or person
A process is described as one whole: trigger, steps, conditions, approvals, failure path. Then every step gets one of three owners.
What can be decided by a rule is decided by a rule. Match the order number, copy the address, post the document. A rule does the same thing every time and costs nothing to run.
What needs a judgement goes to a model: which kind of request is this, which order does this email refer to, which line belongs on the quote. The model also states how certain it is, and below the certainty you set the case goes to a person.
What is binding stays with a person: anything that leaves the business or moves money.
The line between the three is what makes the case hold up or fail. A model on a job a rule can do is expensive and unpredictable. A rule on a job that needs judgement is a list of exceptions that is never finished.
How we go about it
- Record the process as it runs, not as it is drawn. We sit with the person who does it and follow one real case end to end, including the exceptions.
- Assign every step to rule, model or person, and write down why.
- Connect the systems. Documented interface before export, export before user interface. Your systems stay as they are; see integration into your systems.
- Place the approvals where something leaves the business or moves money.
- Name the failure paths. Every stop has a person and a state.
- Build the overview that shows what ran, what is stuck and how long it takes.
- Run it alongside the manual process and switch over one case type at a time.
At the end you hold the running automation, the process description with the owner of each step, the failure paths with names, the overview, and a note per connected system on what happens when its vendor ships an update.
A worked example: the incoming invoice
A supplier invoice arrives as a PDF in the accounting mailbox of a wholesaler in North Rhine-Westphalia.
The automation extracts supplier, invoice number, amounts and the order reference. It matches them against the purchase order and the goods receipt in the ERP. If all three agree within the tolerance you set, it creates the posting as a proposal for the accountant to release. If they do not, the case lands in a queue with the difference highlighted: the price on the invoice is not the price on the order, or the quantity delivered was short.
A supplier who is not in the master data goes to a person. An amount above the limit you set goes to the head of the department before release. Nothing is paid without a person’s release, and every case shows who released it and when.
What you need to bring, and when it is not worth it
You need a process that runs the same way most of the time. You need systems that can be reached, ideally through a documented interface, at least through an export; automation at the user interface works but costs maintenance for as long as it runs. You need an owner in the department who is told when a case stops. And you need the willingness to tidy up: an automation on a process with three unofficial variants automates the confusion.
It is not worth it when the process is rare. It is not worth it when every case needs a real judgement call, because then you are looking at an agent. It is not worth it when the system you would connect is being replaced next year; then it waits. And it is not worth it when a workflow module in your ERP already does it and nobody has configured it.
How it differs from the neighbouring services
An automation runs a known route between your systems. An AI agent decides the route per case within a boundary, and is the right tool where the cases differ. Integration into your systems is the connection underneath, and automation is the process that runs on it. Where the process needs its own screens and its own data, it becomes custom software.
The next step
Which of your processes crosses the most boundaries and depends most on people who decide nothing in it is what the assessment finds. If you already know, the free introductory call is enough to test it.