A production planning manager put an AI agent into production at a large group (without writing a single line of code)

The context

I was a production planning and BI manager. Not a developer. And yet, part-time, alongside my job, I built an AI agent that reads our suppliers’ order confirmations, checks them against the ERP and prepares the buyers’ work.

Two sites of a large international industrial group (niche-market leader, 20,000+ people) use it today, and 2 more are planned. Here’s how it went, what worked, and what cost me a few hairs.

The problem: e-mails, e-mails, and more e-mails

When a supplier confirms an order, it happens by e-mail. Always. And everyone has their own idea of what a readable PDF is: different layouts, scans, Excel files, in French, Italian, English or German.

And that’s not all. Part of the important information isn’t even in the PDF. It’s in the body of the e-mail: a “lead time OK”, a “can we bring the delivery forward?”, a small condition slipped in between two greetings. A tool that only reads attachments misses it.

The result: the buyer juggles the mailbox, the PDF, the ERP, sometimes a spreadsheet, then retypes everything by hand. Meanwhile planners work with dates that are no longer true. And gaps are discovered late, sometimes when the part is missing on the line.

The idea: everything in one place

I didn’t want to add yet another tool. I wanted to centralise. For each confirmation, the buyer sees in one place:

• what the supplier wrote, e-mail body included, and the PDF one click away;
• what is open in the ERP for that order;
• the gaps already calculated (requested date vs confirmed date, current price vs confirmed price, part version);
• three buttons: accept, correct, reject.

Every decision lever within a click. The AI prepares the file, the buyer decides. And I’m firm on this: every confirmation goes through a human. Handing orders to an AI without looking doesn’t appeal to me much.

How it works (short version)

1. 1
   The supplier replies

   By e-mail, as usual. No portal, no form to impose on them.

2. 2
   The AI reads

   The e-mail body and the attachment, in any language.

3. 3
   It compares

   With the ERP’s open orders: dates, prices, versions.

4. 4
   The buyer decides

   Approve, correct or reject, with everything in front of them.

5. 5
   The ERP is updated

   After approval, the information goes back into the ERP.

Three choices that mattered

The less glamorous part

A prototype that reads a PDF is quick to build. Going into production is another story:

• Lost e-mails. When several confirmations arrived at once, only one was processed. The others vanished, silently. Now they go through one at a time, and a failing e-mail doesn’t block the next ones.
• “OK” with nothing inside. “Lead time OK / Price OK” in an e-mail body says neither the date nor the price. You have to look them up in the order. I analysed 9 real e-mails before coding to decide which cases to handle first.
• Documents that look like confirmations. Delivery notes, signed orders sent back, blanket orders with several deliveries. Each has its own rule.
• Data that is a day late. The data warehouse refreshes overnight. A daily job updates the references without overwriting what has already been entered.
• Security. Access with the company account, nothing to install on workstations, no door open from the Internet. It took several rounds with IT. And that’s normal.

Without writing a line of code myself

Yes, you read that right. I didn’t write any code. I described what I wanted in plain language, and Claude Code built it. My job was more like a conductor’s:

• knowing the business, to say precisely what a buyer needs;
• choosing and assembling the right tools;
• testing on real e-mails, fixing, deciding what goes into the project and what doesn’t;
• supporting the teams until it’s part of their daily routine.

A management role helps a lot here. When you already handle priorities, teams and relationships with IT, you can move a tool forward alongside your main job. The AI produces, the manager frames and arbitrates.

The results

Before going live, we ran a 15-working-day user acceptance testing (UAT) phase, in three 5-day stages:

1. testing the tool, how it is used and the end-to-end flow;
2. processing all suppliers’ confirmation e-mails, copied into the mailbox set up for the tool;
3. a new round of testing, once all feedback and requested changes had been handled.

On more than 100 real supplier e-mails, across the 2 sites:

So 80% of extractions needed no correction at all. On a sample this size, that’s an order of magnitude, not something carved in stone: production numbers will tell us more. The 20% that were corrected keep the AI’s original value, which lets us improve the rules along the way.

• Processing time: about 0.5 day, versus 2 to 5 days before.
• Time saved: 3 to 4 days per month for the pilot site’s buyer team, i.e. 36 to 48 days a year. Across 4 sites, that would be 144 to 192 days a year, the equivalent of 0.65 to 0.9 full-time position, if volumes are comparable.

What’s next

The 2 pilot sites (one per ERP in the group) took 6 months part-time, roughly 3 months full-time. For the next 2, the hardest part is done: the data is already in Microsoft Fabric, so it’s a matter of opening it to the tool, then training and supporting the teams. I estimate about 2 months part-time, one site after the other. It’s the group’s first AI agent in production, so we might as well take the time to support people properly.

What I would do differently

• Measure the starting point in the first week. I did it after launch, and the comparison is less clear-cut.
• Test on real e-mails much earlier. The 9 real cases taught me more than weeks of theoretical testing.
• Think about the e-mail queue from day one, not after losing a few.

What to remember

• The gain comes from checking against the ERP and centralising everything, not just from reading PDFs.
• Every confirmation goes through a human: the AI prepares, the buyer decides.
• “No code” does not mean “no IT”: security and network are handled with the teams in charge.
• The approach is ERP-agnostic: only the connection changes from one site to the next.

Questions