Modernise Order Processing Without Forcing Customers to Change

Modernising order processing should remove work from your business. It should not move that work to your customers. Most projects get this backwards.

The distributor wants cleaner orders, so customers are asked to use a portal, download an app, follow a spreadsheet template or connect through EDI. The order desk gets structured data — but only after the customer has logged in, searched the catalogue, selected the right pack size and entered the order themselves.

That can work for a large retailer with an integration team. It is a harder argument to make to a café ordering twelve cases before opening, a restaurant manager sending a voice note from the kitchen, or an independent shop emailing the same spreadsheet it has used for six years.

So the better question is not “how do we make customers order differently?” It is “how do we process the orders they already send without retyping them?”

The ordering channel is not the process

An email is a channel. WhatsApp is a channel. EDI is a channel. A portal is a channel. None of them is the complete order-processing system. The actual process begins after the order arrives:

• Identify the customer, company and delivery location.
• Read the requested products, quantities and units.
• Match each line to the distributor's item master.
• Apply the correct price list, minimum order value and delivery rules.
• Check stock, warehouse and cutoff requirements.
• Resolve anything ambiguous.
• Create the sales order in the ERP.
• Confirm what was accepted, changed or rejected.

Distributors often run a different version of this for every channel. Email orders go to a shared inbox. WhatsApp orders stay on a salesperson's phone. Portal orders enter one system, EDI orders another. Phone orders are written on paper and typed later.

This is not multichannel order processing. It is several separate order desks that happen to work for the same company. So the first modernisation step is not removing channels — it is making every channel converge into the same internal process.

Your customers are already multichannel

B2B buying has not moved neatly from offline to online. It has spread across more channels. McKinsey's 2024 B2B Pulse research surveyed nearly 4,000 decision-makers across 13 countries and found they now use an average of ten interaction channels in a single buying journey — and increasingly expect to move between those channels rather than being confined to one.

That does not mean every distributor needs ten ways to receive an order. It means customers pick the channel that suits the moment. A procurement team may use EDI for scheduled replenishment; the same company's branch manager may email an urgent top-up; a chef may send a WhatsApp message after checking the cold room; a rep may take an order on a visit.

Forcing all four into one customer-facing interface solves the distributor's internal problem by creating a new customer problem. A modern system should allow different entrances while keeping one route behind them.

Keep the front door. Rebuild what happens behind it

The customer should still be able to send whatever suits them:

• An email with the order written in the body
• A PDF purchase order
• A spreadsheet using their own columns and product descriptions
• A WhatsApp message
• A photograph of a handwritten list
• A voice note
• A structured EDI order
• An order through an existing portal

The reading stage differs for each source. Everything after it should be shared. Once an incoming order is structured data, the same customer matching, item matching, pricing, minimum-order, delivery and ERP rules apply — one order pipeline rather than one workflow per channel.

What that looks like in practice

A customer emails: “For Thursday, please send 12 ctn still water 500, 8 ctn cola 330 and the usual green tea.” The system should not simply copy those words into three text fields. It has to establish that:

• “Still water 500” means a particular 500 ml SKU and pack size.
• “Ctn” means the carton unit configured for that item.
• “Cola 330” could refer to more than one pack, and may need review.
• “The usual green tea” refers to a product this account has bought before.
• Thursday is a valid delivery date for the customer's route.
• The order meets the account's minimum value.
• The correct company, warehouse and price list have been selected.

The message is easy to read. The work lies in connecting it to the distributor's own data and rules — which is why plain OCR is not enough. Document-reading tools can extract text, tables and line items from PDFs and images: Microsoft's Document Intelligence lists purchase orders and sales orders among the document types its model extracts. But extraction only tells you what the document appears to say. Order processing still has to work out what those words mean inside your business.

Modernise around the ERP, not instead of it

A distributor does not normally need another system to become the source of truth for customers, products, prices and sales orders. That is already the ERP's job. The modernisation layer should sit in front of the ERP — customer order, then capture and interpretation, then validation, then an ERP sales order — reading from the ERP or master-data source to obtain:

• Customers and delivery locations
• Product codes and descriptions
• Units and pack sizes
• Price lists
• Warehouses and legal entities
• Inventory availability
• Credit or hold status
• Delivery rules

It then writes the approved order back into the ERP. This is not an unusual integration model — Microsoft Business Central exposes APIs for creating sales orders and lines. The difficult part is rarely the final API call. It is making sure the order reaching that API carries the correct customer, item, unit, quantity, price, warehouse and requested date. Connect to the ERP without resolving those details and you have only automated the creation of bad orders.

Keep EDI where it belongs

None of this is an argument against EDI. EDI is the right answer when a customer sends high volumes, can maintain a trading-partner connection and wants machine-to-machine ordering. It is the long-standing standard for exchanging business documents like purchase orders and invoices between systems; where both partners support it, the data arrives structured and needs little interpretation. Keep those customers on EDI.

The mistake is expecting EDI to reach every smaller account. A supermarket group sending thousands of lines can justify a mapping and testing project; a café sending fourteen lines twice a week cannot. Those two customers do not need the same ordering channel — they need their orders to reach the same internal controls. Modernisation can include all three at once:

• EDI for accounts with the capability and volume to justify it
• Portals for customers who genuinely prefer self-service
• Automated processing of messages and documents for everyone still using email, WhatsApp and files

The objective is not to pick one winner. It is to stop manually retyping the orders that remain outside the structured channels. If you are weighing EDI against AI processing head-to-head, we compared the two here.

Do not automate uncertainty

AI-based extraction and matching are probabilistic. A system can be highly confident without being infallible, and that distinction matters the moment the result becomes a sales order. Good software does not pick a product just because it is the closest text match — it stops when something is genuinely unclear:

• Two pack sizes match the customer's description
• The quantity looks unusual
• The requested unit is not sold for that product
• The customer uses an unknown product code
• The delivery address could refer to two branches
• The price differs from the customer's agreed list
• The order is below the minimum
• The requested date violates a cutoff rule
• The ERP rejects the order

Confidence scores should decide whether a result proceeds automatically or gets human scrutiny — the established practice is to pass high-confidence results straight through and route anything below the threshold to a person, with tighter thresholds for the fields that matter most. For order processing, that means the person sees the decision, not redoes the order. If nine lines are clear and one says “six of the large one”, process the nine and put the one in front of the desk with the original message attached. The team answers one question instead of retyping ten lines.

Preserve the original order

Every processed order should keep its source — the original email, the PDF or spreadsheet, the WhatsApp thread, the image, the voice recording or transcript, the EDI message. This is not only for auditing. It is what lets the desk understand why a line was flagged, lets customer service check whether six cartons or sixteen were requested, and gives IT the evidence when a mapping fails. A structured sales order without its source loses context; an original message without a structured order leaves the work manual. You need both.

Start with one contained workflow

Modernisation does not need to begin as a company-wide replacement. Start with something large enough to matter and contained enough to observe — email orders received by one team, PDF POs from a selected group of customers, one company or warehouse, one product category, orders entering one ERP environment.

Run the system in parallel first: let it extract, match and validate without automatically creating anything, and compare its output with what the desk entered. The differences are the real implementation work, and they are almost always in your data, not the model:

• Duplicate customer records
• Unmaintained aliases
• Missing pack information
• Customer-specific product codes
• Informal pricing arrangements
• Delivery rules known only by one employee
• Warehouse logic that was never written down
• Items that should have been marked inactive

Automation does not create these problems. It exposes them. Once the common cases are stable, let clean orders proceed automatically and keep exceptions in review — then add more customers, sources and rules. This is safer than a big-bang rollout and far more useful than testing on a folder of clean sample PDFs.

Measure the process, not the demo

Extraction accuracy on a hand-picked document tells you almost nothing about whether the operation improved. Measure what happens from the moment an order arrives until the ERP accepts it:

• Time from receipt to ERP — including the time an order waits in a queue, not just the minutes someone spends typing.
• First-pass item match rate — lines mapped to the right SKU and unit without correction, split by customer and format so one number can't hide where it struggles.
• Exception rate by reason — not just “12% needed review”, but why: unknown product, ambiguous pack, missing quantity, below minimum, invalid date, pricing, ERP rejection.
• Orders requiring retyping — a reviewed order is not a failed one; 24 lines right and one query still removes almost all the manual work.
• Corrections after order creation — amendments, warehouse fixes, returns and credit notes tied to order-entry mistakes.
• Channel coverage — what share of total orders enters the common workflow, so you don't automate one neat channel and leave the desk unchanged.

What not to do

Several projects look modern while quietly preserving the original problem:

• Don't rebuild the portal inside WhatsApp. A chatbot that makes the customer pick a category, search, choose a pack and confirm every line is just a portal in a messaging window. Let them write what they need; do the structuring on your side.
• Don't create a separate process for every channel. Email, WhatsApp, voice and files need different capture — they should not have different item matching, pricing, minimum-order and ERP logic.
• Don't automate every decision on day one. Go visibility, then assisted processing, then automatic processing for proven cases. An order held for review beats the wrong item dispatched confidently.
• Don't replace the ERP to solve the inbox. The ERP may be old, customised or on-premise; that rarely makes it the thing blocking automation. The gap is between the unstructured order and the structured fields the ERP expects. Fix that first.

The customer should notice better service, not a new procedure

The best modernisation is almost invisible to the customer. They send the same email to the same address, message the same number, attach the same spreadsheet. What changes is everything after:

• The order is captured immediately.
• Products are matched consistently.
• Account rules are checked on every order.
• Exceptions reach the right person.
• The sales order enters the ERP sooner.
• The original request stays attached.
• The customer gets a faster confirmation.
• Fewer errors reach the warehouse.

The customer is not trained on a new system; your side becomes capable of handling their existing behaviour. That is the difference between digitising an order form and modernising order processing. One changes how the customer works. The other changes how much manual work your own team has to do.

See it on an order your customer actually sends

Every order-automation product performs well when the demo uses a clean, one-page purchase order. The useful test is a real order from your own operation: the spreadsheet with the customer's product codes, the forwarded email with three attachments, the WhatsApp that says “same as last week”, the photo taken under bad lighting. That is where you find out whether a system merely reads documents or can actually process orders.

That is the test ManualOut is built to pass. Send us a real order — your messiest one — and we will run it against your setup: matched, priced and checked, so you can see the pipeline behind the front door before you change anything for a single customer.