Fifty orders a day. Each one as a PDF via email. Each one manually typed in. That was daily life for one of our clients — a mid-sized wholesaler who came to us with exactly this problem. Not because he had read about AI and wanted to try it out. But because his clerk had threatened to quit.
That sounds exaggerated, but it's pretty close to reality. The process was so mind-numbing, so repetitive, and so error-prone that nobody lasted more than a few months without either mentally checking out or looking for another job. Three to four hours daily just typing in order data. Item numbers, quantities, delivery addresses — from a PDF document into a warehouse management system. Copy-paste in the best case, manual typing in the worst.
What happened over the next few weeks is this case study. It shows how we analyzed, automated, and stabilized the process — and what we learned along the way that we'd do differently next time.
When we first analyzed the process, something stood out that we now see with almost every client: nobody knew exactly how much time the process actually cost. The managing director's estimate was an hour and a half. The clerk said three hours. The truth was three and a half — on days with many special orders, sometimes four.
We tracked it for a week. Not because we didn't believe the client, but because reliable numbers are the foundation for every automation decision. Without numbers, you automate based on gut feeling, and gut feeling is systematically wrong when it comes to time estimates.
The workflow looked like this:
What looks like six simple steps at first glance was a minefield in practice. The PDFs came in eight different formats — because eight different customers created their orders in eight different systems. Some had item numbers in the top left, others in the bottom right, still others buried in body text. Some delivered structured tables, others free-text emails with an attached PDF that was actually just a scan of a handwritten order slip.
The error rate was estimated at 5-8%. Sounds low, but with fifty orders per day that means: two to four incorrect orders daily. Wrong quantity, wrong item, wrong address. Each incorrect order cost an average of twenty minutes to fix — cancellation, callback, reorder. Plus the reputational damage with the customer that nobody could quantify but that was definitely there.
The managing director had previously evaluated two options. First: hire a full-time employee dedicated solely to orders. Cost: around EUR 45,000 per year including overhead. Second: a major ERP upgrade with an integrated EDI module. Cost: six figures, implementation time six to twelve months, and his customers would have had to change their systems too — which none of them planned to do.
We proposed a third path that was significantly more pragmatic: the PDFs stay as they are. The customers change nothing. But between email receipt and WMS entry, we place an automation that makes manual typing obsolete.
No massive IT project. No change management with suppliers. No six-figure budget. Instead, a Python script that can read PDFs, an n8n workflow for orchestration, and a dedicated Windows server where the whole thing runs automatically every day.
We explained it to the client exactly like that — without buzzwords, without AI promises, without a slide showing a robot arm. The honest pitch was: we're building a script that reads PDFs and transfers the data to the WMS. That's not rocket science. But it has to work reliably, every day, without human intervention. And that's the hard part.
The architecture is deliberately kept simple. Not because we can't build more complex systems, but because simplicity is reliability's best friend. Every additional component is an additional point of failure.
Step 1: Monitor email inbox. An n8n workflow checks the order mailbox at regular intervals. When a new email with a PDF attachment arrives, the attachment is extracted and saved on the server. Sounds trivial, but it wasn't — because some customers don't send their orders as attachments but as embedded images in the email body. For these cases, we had to build a separate extraction path.
Step 2: Parse the PDF. This is where the real work happens. A Python script (Python 3.12) reads each PDF and extracts the relevant data: item numbers, quantities, delivery addresses. We use a combination of rule-based parsing and pattern recognition. For the eight main customers, we created a dedicated template that knows where in the PDF each piece of information is located.
This was the most labor-intensive part of the project. Not the programming itself, but understanding the PDF structures. One customer, for example, had orders where the item number was sometimes six digits and sometimes eight digits — because they used two different catalogs, a current one and one from 2019. Another customer occasionally sent bulk orders where multiple delivery addresses were in a single PDF, separated by a horizontal line that wasn't always in the same position.
For each of these problems, we needed a solution. Some were elegant (regex patterns that recognize both item number formats), some were pragmatic (if the horizontal line is missing, search for the word "delivery address"). None of these problems were unsolvable, but each one took time — and that's something you need to communicate honestly in automation projects.
Step 3: Feed data into the WMS. The extracted data is validated (does the item number exist? Is the quantity plausible? Is the address known?) and then transferred to the warehouse management system via API. If validation errors occur, no entry is created — instead, a notification is sent to the clerk, who handles the case manually.
Step 4: Status report. After each processing run, the clerk receives a summary: how many orders were processed automatically, how many require manual follow-up, and why. This sounds like a detail but was crucial for acceptance — the employee didn't want to feel like she was losing control.
The full stack: Python 3.12 for parsing, n8n for workflow orchestration, a dedicated Windows server (we call it the UXUIX VM internally) with a scheduled task that triggers the process automatically every day.
Here's an honest insight we took away from this project: building the automation was one third of the work. Stabilization was another third. And monitoring was the last third — and probably the most important one.
Because an automation that fails silently is worse than no automation at all. When the clerk does the process manually, she immediately notices when something's off. When a script does the process and fails silently, unprocessed orders pile up while everyone thinks everything is running.
That's why we set up monitoring based on a Supabase Edge Function. It works on the heartbeat principle: the automation reports to the Edge Function after each successful run. If the report doesn't come, an alert is triggered. Additionally, there's a dashboard where the client can see at any time how many orders were processed, how many errors occurred, and whether the system is healthy.
The monitoring has already paid for itself. In the third week of operation, a customer changed their PDF format — without prior notice, as these things go. The parser no longer recognized the item numbers, orders went into the manual queue, and monitoring immediately sent a warning. We were able to adapt the template within two hours. Without monitoring, it probably would have taken two days for someone to notice.
After two weeks of setup and one week of fine-tuning, the system was in production. Here are the numbers after several weeks of stable operation:
Time spent before: 3-4 hours daily for manual processing of all orders.
Time spent after: About 45 minutes daily. These are the special cases that the parser can't process automatically — handwritten order slips, unknown item numbers, orders from new customers without a stored template.
Time savings: 70%.
In absolute numbers: around 2.5 hours per day that the clerk can use for other tasks. Per month, that's over 50 hours. Per year, over 600 hours.
Error rate before: 5-8% (two to four incorrect orders per day).
Error rate after: Under 1%. The remaining errors are almost exclusively source errors — cases where the order PDF itself contained incorrect information. No human can prevent those either.
Costs: A one-time setup fee plus an ongoing monthly license, which together cost a fraction of what an additional part-time employee or an ERP upgrade would have cost. Break-even was reached in less than three months.
Invisible gains: What the numbers don't show is the relief for the team. The clerk now only handles the interesting cases — the special orders, the follow-up questions, the new customer onboarding. The monotonous part is gone. This has a direct impact on employee satisfaction and turnover, even if it's hard to put a euro figure on it.
What went well:
The decision not to change customer formats was absolutely right. Any attempt to get customers to use a standardized order format would have failed or taken months. Instead, we adapted to reality — and reality is: PDFs come in all shapes and sizes.
Close collaboration with the clerk was crucial. She knew every edge case, every exception rule, every customer with their quirks. Without her knowledge, we would have missed at least half the edge cases. Automation projects often fail because developers talk to managers instead of the people who actually execute the process.
Setting up monitoring from day one — not retroactively after the first outage — saved us from several problems that would otherwise have gone unnoticed for days.
What was difficult:
The variety of PDF formats was more demanding than expected. We had anticipated four to five different structures and ended up needing eight templates, plus three special treatments for customers who changed their formats during the project.
The client's initial expectation was "100% automatic, zero manual." We had to explain that there will always be cases that need manual handling — and that's perfectly fine. The goal was never 100% automation, but 100% reliability for the 85-90% of cases that are automatable. The remaining 10-15% stay with humans, and that's a good thing.
A scheduled task on a Windows server sounds old-fashioned — and it is. But it works. Reliably, every day, without container orchestration or cloud architecture. Sometimes the most boring technology is the best.
This case study isn't an outlier. Practically every company that regularly needs to transfer data from one format to another — whether orders, invoices, delivery notes, or customer data — has a process that looks exactly like this: repetitive, error-prone, and frustrating for the employees involved.
The question isn't whether automation is worth it. The question is whether the process is stable enough to be automated, and whether the source data is structured enough to be machine-processed. In our case, the answer was: yes, with limitations. And we didn't ignore those limitations — we addressed them deliberately, through per-customer templates, validation rules, and a clear fallback to manual processing when things are unclear.
If you have a similar process in your company and want to know whether automation is worth it, I recommend our article on business process automation as a starting point. There we describe our scoring matrix that lets you evaluate which process has the highest leverage.
If you're interested in the technical details — how we set up Python scripts for PDF parsing, how n8n workflows work, or how our monitoring for warehouse and logistics processes is structured — reach out to us directly.
More about how we work as an AI automation agency and which projects we implement can be found on our website.
And if you'd rather talk than read: here's the contact form. No sales pitch. We listen, look at your process, and tell you honestly whether automation makes sense — or whether your time and money would be better invested elsewhere. Because sometimes the best automation is the one you don't build.
