How to Use AI to Automate Process

A distributor we worked with wanted AI to read their inbound order emails.

Six people in customer service, roughly 1,200 orders a week, every one of them typed by hand into the ERP. The proposal wrote itself. Point a model at the inbox, extract the order, push it through, then redeploy the team to something more interesting.

It was a reasonable idea. It was also aimed at the wrong part of the problem. This surfaced because the upfront time was spent mapping the process.  

Inbox Content

When we started mapping the emails, the first thing we learned was that 38% of the emails were not orders. They were delivery questions, price queries, and amendments to orders placed the day before. This told us that we needed to make sure that the model was trained to differentiate between orders and a complaint about a late pallet. Also, the volume was closer to 750, which changes the business case.

The next thing we learned about was Denise. About 70% of orders arrived using the customer's own part numbers rather than the distributor's, and Denise translated them using a spreadsheet she had maintained for eleven years. It was a functional point of failure for most of the company's revenue, and nobody had noticed because Denise is very good at her job.

The third thing learned was any order carrying a discount above five percent needed sales manager approval. That rule was introduced during a margin squeeze in 2016. It applied to about 40% of orders. This added a day to the cycle time, and it was approved 99% of the time. The margin squeeze ended, but the rule did not.

The numbers that came out of two weeks:

Before the mapping, the team could tell you they were busy. After it, they could tell you:

• The average order took just under nine minutes of hands-on time.
• The cycle time from email to confirmation averaged six hours and stretched past two days on Mondays.
• That roughly 4% of orders went out wrong.
• The average cost of the credits and return freight.

Understanding the landscape makes the business case. Afterwards you are guessing.

The 2016 approval rule was eliminated first. Removing it took one meeting and cost nothing, and it took most of a day out of the cycle time for 40% of orders. Denise's spreadsheet became a proper mapping table. Neither situation was an AI project, but they delivered savings before the AI project was implemented.

The AI Project

What remained was a good automation candidate. Repeat orders from known customers in a consistent format were now backed by a clean part number mapping. That was about 55% of the volume. The model had 94% accuracy on extraction with somebody reviewing the flagged cases.  

The project paid back inside a year, and it paid back for reasons the board could see in the operating numbers rather than in a slide.

Process Work is Hard

This is a fair objection. Process work has a reputation for becoming six months of workshops that produce a diagram nobody opens.

It does not have to be that. What we have shared here took two weeks, three people, and a lot of sitting next to the team while they worked. Not interviewing the process owner, who will describe the process as designed. Sitting with the people who do it, who will show you the process as survived. Two weeks against a multi-year commitment makes sense.

It is also worth saying that not every AI use case is a process. Exploratory and generative work does not map neatly, and trying to force it into a flowchart will just annoy everyone. The argument here applies to operational work, with volume and repetition.

How can you do this?

Pick the process your team complains about most. Spend time measuring four things, volume, hands on time per case, end-to-end cycle time, and the exception rate.  

You may still buy the AI, you will just buy the right amount of it, pointed at the right thing, with numbers you can defend afterwards.

If you need help mapping your process, set up a meeting with one of our IT experts.