The process often exists only in someone's head
Ask a team how an incoming order is processed and you get three different answers. Not because people are doing it wrong, but because the process has never been written down explicitly. Everyone has developed their own way of working, with their own exceptions. That is not a problem as long as people are doing the work: the experience sits in their heads. But an automation layer has no head. It executes what you tell it. If you document the process incorrectly, it executes it incorrectly, consistently and at scale. That is exactly why, before touching the technology, you need to spend a week writing down what actually happens when a document arrives: who picks it up, what does that person check, what do they do when a field is missing, when does someone call the supplier.
Why exceptions are the biggest piece of work
Eighty percent of documents are clean and uniform. Processing those is straightforward. The twenty percent that deviates determines whether a system works or not. A supplier who emails their packing slip as a screenshot. A CMR waybill with an extra signature in the wrong place. An invoice with an order number formatted slightly differently than in your system. Those are exactly the situations that cost people the most time right now, and exactly the situations you need to think through before you automate. What can the system handle on its own? What should it flag for human review? And who is that person? If that is not settled, every exception still ends up on someone's desk without it being clear what is expected of them.
What the Cabooter implementation shows
At Cabooter Group, a logistics company that processes more than 70,000 documents per year, CMRs, invoices and orders arrived by email and were retyped into the system. dottle now processes 85% of those documents fully automatically, representing a saving of approximately 110,000 euros per year. But that 85% is not a coincidence. It is the result of a clear decision: which documents are good enough to handle automatically, and which ones warrant a closer look? Drawing that line deliberately, and having the discipline to maintain it, is what makes the difference between a project that succeeds and one that stalls after three months.
When automating a document flow is actually not the right move
Not every document flow is suitable for automation. Three situations where you are better off waiting. First: when volume is low. Processing twenty invoices per month manually costs less than the attention an implementation demands. Second: when the source data is structurally poor. Suppliers who format every document differently, with no recognisable pattern, generate a high volume of exceptions that still need to be handled manually. You end up solving a problem that actually has a different root cause. Third: when the process is not yet defined. Automation forces you to make a decision about how something works. If that decision has not been made internally, the system becomes the battleground for a discussion that should have taken place much earlier.
The human remains essential, even after automation
At HDG, dottle processes 200,000 packing lists per year, with 90% less manual work and an FTE now spent on inspection work rather than retyping. But there too, a person approves the flagged exceptions. That is not a limitation of the system, it is the design. A system that flags deviations and puts the decision with a person is more reliable than one that silently posts everything through. Errors discovered later in an ERP or TMS cost far more time than an approval screen that someone looks at for two seconds and marks green. The lesson: build the human check in as a design decision, not as a fallback.