Orders are keyed in by hand
They arrive by email, as PDFs, in an attached spreadsheet or dictated over the phone, and someone enters them into the ERP line by line. And when volume grows, what grows is the admin headcount.
Logistics
and supply chain.
Logistics and supply chain
In distribution the problem is the volume of manual work, not a lack of information. Every day orders come in by email, by phone and as PDFs, and someone keys them into the ERP one by one.
A wholesaler receives the same order from the same customer every week, in an email with the same format, and types it in by hand every time. When volume rises the process doesn't change: another person is hired. It is the clearest case of repetitive work that needs judgement in companies like yours: product codes, quantities and terms have to be interpreted, and it can be automated.
The second half is stock. A minimum is set per product code, reviewed when someone remembers, and the business lives with both consequences. Stock-outs that cost sales, and dead stock that costs money. And the data to calculate it properly is all in the ERP: sales history, each supplier's real lead times and seasonality.
All the material is already in the ERP and the orders inbox. None of the three means changing systems.
An agent that reads the email and interprets product codes and quantities, even when the customer uses its own naming. It prepares the order in the ERP and leaves confirmation to a person: the work moves from typing to checking.
Minimum and ideal levels calculated from consumption history, each supplier's real lead time and seasonality. They update themselves, not once a year.
Real margin per product and per customer, with freight and discounts already taken off, available during the month and not at the close. It is the information you need to revise a price list in time.
Four steps, and none of them starts with the ERP. The first is choosing which orders, because "the orders" is not a scope.
Not "automate orders", but the orders of one customer who buys every week in the same format. A scope where you know how many come in each month and how long they take to key in today.
Whether the code the customer writes is yours or theirs, whether quantities come in cases or in units, and whether the price is in the email or comes from the ERP. This step decides the rest of the project.
Here a misread order doesn't stay on the screen: it leaves the warehouse and reaches the customer. You write down beforehand what it confirms on its own, what it holds and what goes to a person.
With orders coming in clean, calculated minimum stock and margin per product have something to feed on. Before that, they are calculated on a history typed in by hand.
Everything we build, in the order it comes into distribution. The first is the one that pays for itself in counted hours, which is why it comes before any dashboard.
Orders arriving by email, as PDFs or in the customer's own naming, interpreted and left in the ERP for a person to confirm instead of type.
See the productMinimum and ideal levels recalculated every night with the lead time the supplier really delivers, the seasonality and the real consumption of each product.
See the productMargin per product and per customer with freight and discounts already deducted, available during the month rather than at the close.
See the productThe supply chain from the customer's email to the supplier order with nobody typing along the way, business rules agreed and exceptions going up to a person.
See the productDelivery notes, transport documents and the terms agreed with each supplier, searchable on the spot. At a logistics provider it is often the first project.
See the productERP, warehouse and transport in one place, which is what you need when the real lead time and the incident live in different systems.
See the productThe session where today's manual work gets a number (orders a day, minutes per order, cost per hour) before there is any proposal.
See the productIt is the normal case, and it is why a macro doesn't solve this. Working out that the customer's code is your code, with its variants and abbreviations, is the judgement an agent brings. It is built on your order history, which already holds those equivalences.
At first it confirms nothing: it prepares the order and a person checks it, which is faster than typing it. Supervision is relaxed by order type as the hit rate justifies it, starting with repeat orders from regular customers. Unusual ones keep going through a person long after.
Almost always, and it is something we check in the first phase, not something we assume. When there is no API we work against the database, with exchange files or with the same mechanism you already use to load orders in bulk. We never propose changing the ERP to make the project possible.
Because miscalculated stock costs money every day in both directions at once: stock-outs that lose sales, dead stock that ties up cash. A dashboard shows you both and fixes neither. And the calculation needs the supplier's real lead time, which is a figure you need to start measuring as soon as possible.
The second half does. Orders and documents keyed in by hand are the same, and usually worse because of the volume of delivery notes and transport paperwork. The stock calculation doesn't apply in the same way; instead, the useful project is in lead times, incidents and shipment traceability.
It is the sector where that question has the cleanest answer, because today's cost can be counted: orders a day, minutes per order, cost per hour. That number is calculated in the first meeting with your data, before there is a proposal. If it doesn't add up, we say so.
Not the orders project, which is the entry point and runs through the customer's email. It does affect goods-in and reconciliation, which comes next. Paper is solved by scanning at the loading dock, and the real question isn't whether it can be read: it is how many suppliers and how many delivery notes a day there are. That number decides whether it pays off, or whether it is cheaper to ask the ten suppliers that account for most of the volume for digital documents.