What retyping orders costs

Typing an order from a PDF is slow, and it takes a person who knows your customers away from talking to them. It is also where mistakes start. A digit in a quantity gets transposed. An item is picked from a list of similar part numbers. A ship-to address is copied from the customer's last order instead of this one. Each mistake turns into a wrong shipment, a credit and a phone call.

The work also creates a queue nobody can see. When the person who enters orders is out or busy, orders wait in an inbox, and the first sign of the delay is a customer asking where their delivery is.

The pipeline: from inbox to order

Automated order entry follows five steps.

  1. Receive. Orders go to one inbox. Each attached PDF becomes a job, and the email stays with it so anyone can see where the order came from.
  2. Read. A reader for that customer's layout pulls out the details: the customer's PO number, the ship-to address, each line's item number, quantity and price, and the requested date. A reader is a small tool that knows where the information sits on one kind of file.
  3. Map to the model. The values become specific things in your business's data model: this customer, this ship-to address, these products. Customer part numbers are translated to your own item numbers. What an ontology is, explained for business owners explains what that model is.
  4. Check. The order is checked against the rules in the model before anything is created. The next section lists the checks.
  5. Create the order. An order that passes is created through an approved action that applies the same rules and records what it did. One that fails goes to a person.
Illustration titled From emailed PDF to order. An envelope holding a plain document labeled PDF feeds five stations from left to right: Receive, Read, Map to the model, Check, and Create the order, ending at a green check labeled Order created. An amber arrow drops from Check to a person labeled Review. A bar at the bottom reads: Read, map and check before any order is created.
Figure 1. Every emailed order is read, mapped and checked before anything is created.

The mapping step is what makes the checks possible. If a tool copied text from the PDF straight into order fields, the only test would be whether each field accepted the text. Once the values are mapped to known customers and products, the system can ask whether the order makes sense. Don't copy your old database: design the data model first explains why the model comes first.

What to check before an order is created

These are the checks most distributors already do by eye. Automation makes them explicit, and runs them on every order.

  • The customer is known, and the ship-to address belongs to that customer.
  • Every item is in the catalog. A customer part number with no match is a question for a person, not a guess.
  • Prices match the prices agreed with that customer.
  • The quantity fits the unit of sale, for example whole cartons when a product is sold by the carton.
  • The order is not already entered. If a customer resends the same email, the PO number is already on file, so a second order is not created.

An order that passes every check is created. An order that fails goes to a person, with the PDF, the values that were read and the check that failed. These rules belong in the data model, where every order is checked the same way. Put business rules in your data model, not in code or a chatbot covers how.

Illustration titled Checks before an order is created. A plain document labeled PDF feeds a checklist with five rows: Customer is known, Products are in the catalog, Prices match, Quantity fits the unit, and Not already entered. A green path leads to Order created, and an amber path leads to a person labeled Sent to a person with the reason. A bar at the bottom reads: A failed check goes to a person, not into the system.
Figure 2. Orders that pass every check are created; the rest go to a person with the reason. Simplified for illustration.

New layouts: Buffaly writes the reader

Every customer's PDF looks different, and customers change their templates without telling you. Template-based capture tools need someone to set up a template before a new layout can be read, so a new customer or a changed form stops the automation until that work is done.

With Buffaly, our own software engineering system, a new layout does not stop the work. When none of the existing readers matches a file, Buffaly writes a new reader for that layout, uses it on the file in the same session and keeps it for the next file in that layout. This is how Buffaly normally works. In Buffaly Builds Its Own Tools, an analysis of 1.2 million messages and over 380,000 tool calls from a real Buffaly instance found that 70% of newly created tools were used in the same session they were written.

A new reader feeds the same mapping and checks as every other reader. It does not get to skip them.

Review and exceptions

Automation changes what people do with orders. Instead of typing every order, they handle the ones that need a decision.

  • Work the exceptions. Each order that failed a check shows the PDF, the values that were read and the reason it stopped. The person fixes the problem, for example by choosing the right product, and the order continues through the same checks.
  • Teach the model once. When the same fix comes up again, such as a customer's part number that always means one of your items, record it in the model so the next order passes on its own. AI that learns your business while it works covers how the system builds on what it has learned.
  • Review new layouts first. Have a person look at the first orders from a new customer or a new layout before they are released. Once a layout has a track record, orders that pass every check can go straight through.
  • Limit what the agent can do. In Buffaly, an agent cannot edit an order directly. It can change a record only by calling a typed action that checks the rules first. In the published Proof by Construction test, an agent was told to skip review, approve its own document and approve out of order; every attempt was blocked and logged. Can you trust an AI agent with orders, prices and invoices? looks at which actions to keep behind a person.

What still needs a person

Automation removes the typing, not the judgment. Keep these with your staff:

  • New customers and credit decisions. Whether to accept an order from an account that is new, over its limit or on hold.
  • Price exceptions. A price on the PDF that does not match the agreement may be a mistake or a deal someone made by phone.
  • Substitutions. What to offer when an item is out of stock or discontinued.
  • Notes that change the order. A line such as "hold until next week" or "call before delivery" needs someone to act on it.

Example: a parallel run

During a flooring wholesaler's move off a Zoho system customized over 15 years, the business ran Zoho and CommerceServer side by side for one month. Staff kept working in Zoho and emailed the PDFs Zoho produced. Buffaly agents read each file into the business's data model, checked it and entered it in CommerceServer, so nobody entered an order twice. When a file arrived in a layout the agents had not seen, Buffaly wrote a new reader and used it in the same session.

Those PDFs came from the business's own system, not from customers, but the steps were the same ones described here: receive, read, map to the model, check and create. The parallel run: email a PDF from Zoho, and Buffaly agents enter it in CommerceServer explains how that month worked, and How a flooring wholesaler left 15 years of Zoho patches in one month tells the whole story.

How to start

  1. Collect recent order PDFs from your largest customers, and note which ones your staff retype most often.
  2. Write down what staff check by eye before they enter an order. Those are your first rules.
  3. List the part numbers people translate from memory: the customer's number on the PDF and your item number it means.
  4. Decide who handles each kind of exception, such as unknown items, price mismatches and credit holds.
  5. Run the automation alongside manual entry for a while and compare the results before letting orders go straight through.

Stop retyping orders

If your staff spend part of every day typing orders from PDFs into your system, tell us which orders you receive and what system you enter them into. Tell us about your current system, or read how full service works.