Which orders suit automated entry?
Repeat orders from established customers suit it best: the customer, the products and the prices are already known, so most checks have a clear answer. Typed PDF, spreadsheet and email-body orders can all be read. Orders described in free text, such as a builder asking for whatever is needed for a job, still need a person. Before building anything, check how your largest customers send orders. A customer that already sends structured orders through EDI or a supplier portal needs an integration with that channel, which is a different job from reading email.
- Most orders come from customers who order regularly.
- Customers quote a product code, even if it is their own.
- Your price lists are maintained in the order or accounting system.
- Order volume is high enough that retyping takes noticeable staff time.
How does the workflow read a purchase order?
The workflow watches the orders inbox. For each email it separates the purchase order from other attachments, such as terms and conditions or drawings, and identifies the customer from the sender's address and any account number printed on the order. It then extracts the header: purchase order number, delivery address, required date and contact. Each line gives a customer product code, description, quantity, unit and price. The email body is read as well, because customers often add instructions there, such as a delivery window or a request to hold back-ordered items.
How are customer product codes matched to yours?
Large customers usually order with their own product codes. Keep a cross-reference table for each customer that maps their code and unit to your item and unit. Units cause many errors: a customer ordering 10 cartons may mean 10 or 240 of your selling unit. When a line has no entry in the table, the workflow can suggest matches by description and recent order history, but a person confirms the match and the confirmed answer is added to the table. Over time the table covers almost every line a customer sends, and the review queue shrinks.
What checks run before the order is created?
Each check either passes or holds the order with a reason. Run all of them, then show every failure together, so a reviewer fixes the order once instead of several times. Keep the rules in a table the business can change without a developer, because prices, pack sizes and credit limits change often. Read prices and credit status from the live system at the moment of the check, not from a copy taken that morning, so a price change or credit hold made during the day applies to the next order.
- Duplicate: the same purchase order number from the same customer has not been processed before.
- Price: each line price matches the customer's price list or contract price.
- Quantity: quantities respect pack multiples and minimum order rules.
- Stock: stock is available in the right warehouse, or the customer accepts back orders.
- Address: the delivery address matches one already on the customer record.
- Credit: the account is not on hold or over its limit.
How is the order created in your system?
Through the order system's API where one exists. Unleashed publishes a SalesOrders resource that can create orders and order lines, update them and mark them complete. The MYOB Business API has sale order endpoints for item and service orders. Create the order with the customer's purchase order number in the customer reference field, because invoices and remittances will quote it later. Attach the original purchase order file to the order. Decide whether orders that pass every check are created as drafts for a quick glance or released directly; many businesses start with drafts and change the rule once the error rate is known.
How do confirmations go back to the customer?
Send the order confirmation once the order exists in your system, quoting the customer's purchase order number in the subject line so their buyer can match it. List each line with your item description, quantity, price and expected dispatch. When the order differs from what the customer sent, such as a back-ordered line or a price that does not match their purchase order, the confirmation should state the difference plainly. Those confirmations go to a person for approval before sending, because the wording can affect the customer relationship and, in some cases, the terms of the sale.
What should you measure after go-live?
Track the share of orders created without any edit, the number of corrections per order and which checks fail most often. Review corrections weekly: most will be missing cross-reference entries or out-of-date prices, and fixing the source data reduces future reviews. Track the time from email arrival to order creation as well, so you can see whether held orders are waiting too long. Keep a log of amended purchase orders, because customers who resend an order with changes need a defined process that compares the new version with the order already in your system.