Orders still arrive the way customers like to send them
Most businesses that sell to other businesses have a web shop or a portal. Most of their orders still don't come through it. They arrive as an email with a list in the body, a PDF purchase order, a spreadsheet, a photo of an order sheet, or a voicemail left after the office closed.
Somebody then reads each one, works out what the customer meant, finds the right product codes, checks the price and the account, and types the order into the system. It's careful, repetitive work, and it's the kind of job that gets a job advert of its own.
What the AI does with each order
- Reads the order wherever it arrived. Email text, PDF purchase orders, spreadsheet attachments and transcribed voicemails all go through the same path.
- Works out what the customer meant. "Two cases of the usual chicken" becomes a specific product code, because the build knows that customer's order history and your catalogue.
- Checks the order against your rules. Is the product active? Is the quantity sensible for this customer? Does the price match their price list? Is the account on hold? Is the delivery date one you can meet?
- Creates the order in your system. Through the system's API or its import route, exactly as your team would have entered it.
- Confirms with the customer. A confirmation goes back on the channel the order came in on, and if something is unclear, the question goes back in the same thread.
What stays with your team
Anything the rules can't settle. An unknown product, a quantity ten times the customer's normal order, a price disagreement, a customer who's over their credit limit: these are flagged, not guessed. Your team sees the original message next to what was extracted, fixes or approves it, and moves on.
Over a pilot, the list of reasons something gets flagged is also the most useful report you'll get about your order process. It shows exactly where the time was going.
Why not just push customers onto a portal?
Because most of them won't move, and the ones who order the most are often the least willing. A chef ordering at eleven at night, a site manager on a phone, a buyer whose own system generates PDF purchase orders: none of them wants a new login. Automating the order desk means you stop asking customers to change, and stop paying people to compensate for it.
How a build works
Order processing is a custom build, because it depends on your catalogue, your customers and your system. It runs in three stages:
- Pilot. One order channel, a sample of real orders, two to three weeks. We agree the measures up front: orders processed without a touch, time per order, and errors caught.
- Build. The full set of channels and rules, connected to your system, with your team approving everything during a supervised launch.
- Run and improve. Monitoring, new rules as your catalogue and customers change, and new workflows when you're ready for them.
See how custom builds work for pricing and what you own at the end.