All services

Process automation across ERP, CRM and email, without replacing a system

An order in the CRM lands in the ERP by itself and the confirmation goes out by email, with nothing keyed in twice. Behind it sits one system connecting ERP, CRM, email and the applications your teams work in.

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

  1. 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.
  2. Assign every step to rule, model or person, and write down why.
  3. Connect the systems. Documented interface before export, export before user interface. Your systems stay as they are; see integration into your systems.
  4. Place the approvals where something leaves the business or moves money.
  5. Name the failure paths. Every stop has a person and a state.
  6. Build the overview that shows what ran, what is stuck and how long it takes.
  7. 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.

Common questions

Do we need new software for this?
No. The systems you have stay as they are. What gets automated is the route between them, and that route currently runs through people moving data from one window to the next.
What about systems with no interface?
Every business has them. We work through the options in order: documented interface, database or file export, and only then automation at the user interface. The last option is the one that costs the most to maintain, which is why it comes last rather than first.
What happens when a step fails?
The process stops and the case goes to a named person for resolution, in the state it stopped in. Automations that quietly carry on after a failure create work rather than removing it.
How do we know it is running?
From an overview showing what completed, what is stuck and how long something took. Without that, a stalled process is noticed when somebody phones.
Where does AI come into an automation?
Only where a step needs a judgement a rule cannot express: which kind of request this is, which order an email refers to, which line belongs on the quote. There a model decides and states how certain it is. Below the certainty you set, the case goes to a person. Everything else is rules, because rules are cheaper and do the same thing every time.
Does our data stay with us?
Yes. Processing in German data centres under a data processing agreement under Article 28 GDPR, or directly inside your own infrastructure, and contractually and technically separated from model training. For every automation that uses a model we record the EU AI Act risk class before it goes live.