What goes wrong when you start immediately?
The first instinct is understandable: you have a pile of incoming orders, a colleague retyping them into the ERP, and a tool that takes over the retyping. Done. But orders do not always arrive as a neat PDF with a recognizable structure. They come as forwarded emails, screenshots, Word files saved as PDFs, or emails where the order details are simply in the body text. And all those variations behave differently. If you do not map this out in advance, you will discover it the moment the system fails to process an order, or worse, processes it with an incorrect item number. The colleague you wanted to relieve is then back at their desk, this time also to fix the mistake.
What is the core lesson when automating order intake?
The lesson is this: automation exposes the quality of your source data. If customers send an item code that does not match your internal code, that problem already existed. The colleague who was retyping resolved it mentally, based on experience. That implicit knowledge is not documented anywhere. Automating means making that knowledge explicit: which item codes does customer A use, how do they map to your ERP, and what do you do when there is no match? Only once you have written down those rules can you build them in. This is not a technical problem, it is an organizational one. The tool helps you work through it, but it does not solve it on its own.
When does automating order intake pay off?
When volume is high enough, the process is reasonably stable, and source data is consistent for most customers, automation delivers results immediately. At Cabooter Group, dottle now processes more than 70,000 documents per year, with 85% handled fully automatically. These are orders, CMRs, and invoices that arrived by email and were previously retyped. The result: approximately 110,000 euros saved per year. That situation did not exist on day one. Those results came because the document flows were mapped out first, exceptions were identified, and the approval process was structured properly. People approve, the system does the reading and typing. That model works, but only if you know what the system will encounter.
What do you do when the source data is too poor to automate?
Then honesty is in order: not everything can be automated. If a customer consistently delivers poor data, uses unreadable formats, or changes their order process every month, then automation for that flow is premature. You are better off starting with the customers where things do work. Automate the 80% that looks as expected, and leave the 20% that always deviates as a manual process for now. That quickly saves time without overloading the system with exceptions. Later, you can address the remaining flow once you have a better understanding of what it contains. Automation does not have to be all or nothing.
How do you set up order intake automation properly?
Start by logging for a week: which orders come in, from which customers, in which format, with which deviations? That overview takes an afternoon and prevents weeks of corrections later. Then define three things: what the system needs to read, what it matches on in your ERP, and who approves what. Make sure the approval function actually works well for the person doing it. If deviations are clearly flagged and quick to assess, the barrier is low. If the system quietly passes unclear situations through, or blocks them without explanation, the user loses confidence. And without user confidence, automation does not hold, no matter how good the system is.