The LLMs are good, the APIs are cheap, you've got a sharp engineer on staff and a voicemail inbox full of orders waiting to be keyed in. Why not just build order automation yourself?

Every distributor we talk to has thought about it at some point, and it's a fair question. And for the first few test runs a distributor tries, it probably goes well. You can wire up transcription, pipe the text into Claude or GPT, and watch it turn "give me two cases of romaine and a bag of the usual tomatoes" into something that looks like structured data. It feels like magic - It feels like you're almost there.

Unfortunately, if you’re like most distributors trying to build order automation themselves today, you're not almost there. You're about 10% of the way there, and the remaining 90% is where distributor order automation actually lives. Here's what off-the-shelf tools don't tell you.

Parsing orders is one thing, but matching to what the operator wants is another

Getting AI to transcribe what operators wrote down is the easy part. Getting it to understand what they meant is where the work begins.

Distributors aren't shipping to Amazon, they're shipping to chefs, owners, and back-of-house managers who've been ordering from you for fifteen years and have zero reason to be explicit. They say "tomatoes." You carry eleven tomato SKUs — Roma, grape, cherry, cluster on the vine, hothouse, heirloom, 6x6, 5x6, ripe, mature green, and that one specific 25lb case of Romas from the grower in Immokalee that this customer always orders. Which one did they mean? 

The AI doesn't know. Neither does any tool you buy off the shelf, because the answer isn't in the text. It's in the customer's order history, their pricing agreement, their last six weeks of purchases, and the item groups your buyer set up in the ERP.

"Potatoes" is worse. A 50lb sack of russets is a different product than a 6/5lb case of bakers, which is different from a 30lb case of reds, which is different from peeled, diced, or frozen crinkle-cut. The customer orders "potatoes" because they've always ordered the same potatoes from you. The system that replaces your order desk has to know that.

This is the part that generic tooling can't solve. It's not a prompt engineering problem. It's a distributor data problem that requires your catalog, your order guides, your customer-specific pricing, and your item group logic all working together behind the parser.

Different models are good for different things. Model orchestration gets complicated and expensive

The second shock comes when you realize that AI models don’t all work the same way. If you feed an identical voicemail to three different models, you may get three different orders. One model transcribes the audio perfectly but drops units. Another nails the items but hallucinates quantities. A third is great at images but can't handle the regional accent on the voicemail. 

If you want always-accurate results, you need to build an orchestration layer. You route voicemails to one model, scanned order sheets to another, emails to a third, and you run a validation pass on top of everything. This is the right architecture, but it's also expensive, operationally complex, and a constantly moving target. Every three months one of the foundation model providers ships an update that changes the accuracy profile, and your whole routing logic needs re-tuning. The model that was best at catchweight items in April is second-best in July. You're now running a small ML ops team inside a food distribution business.

We've been orchestrating models for this exact workflow for years. We've watched the landscape shift three or four times. We've rewritten our routing logic more than once. It is not a side project.

Order automation doesn't exist in a vacuum. How does the data get to the ERP?

Now let's assume you've cracked items. You've cracked models. You've got a beautiful internal tool that turns a voicemail into a clean JSON order. What happens next?

Because this is where the "build it yourself" story quietly falls apart. Order Agent saves time because orders land in the ERP without anyone keying them. If your homegrown tool spits out a structured order that still has to be manually entered into AS400, Produce Pro, NetSuite, or whatever you're running, you haven't automated anything. You've just moved the keying step one seat to the left.

The integration is the product. A distributor who saves three minutes of parsing per order but still spends five minutes keying it into the ERP has a science project, not a time-saver. 

And ERP integrations are their own discipline! APIs where they exist, flat file drops where they don't, custom field mappings, pricing logic, credit holds, allocation rules, and a support relationship with your ERP vendor that you will need when something breaks at 5am on a Tuesday.

90% of the way there doesn't save you any time. Being Wrong is expensive.

This is the one that's hardest to internalize until you've lived it: in order automation, 90% isn't a passing grade. It's a failing one.

Let's imagine the AI perfectly transcribes every voicemail and photo into a structured order. Great. Now what? You still need to route that order into the ERP, which means handling the dozens of edge cases that the order desk used to handle by hand.

• An item is out of inventory. Does the system know your sub rules? Can it offer a temp substitute at the customer-specific price?
• The operator ordered by the case but you only have broken-case inventory. Who handles the conversion?
• The customer has a negotiated price on that SKU that differs from list. Does the order go out at the right price, or does AR have to chase it next week?
• Two items in the order are on a promo that only triggers when ordered together. Does the automation know that?
• The order hits a credit hold. What happens? Does it queue? Does it notify the rep? Does the operator find out at 4am when the truck doesn't show?

And once the order is built, you still have to confirm it with the operator. That means SMTP that doesn't end up in spam, SMS that handles opt-outs and carrier rules, a reply-parsing layer that knows "yes, ship it" from "wait, I meant two not three" from "add a case of bacon." Each of these is its own small project. 

None of them are particularly hard in isolation. All of them together, integrated with your ERP, stitched into your pricing, respecting your customer rules, at the accuracy level a distributor actually needs - that's the product. That's the thing that takes a team years to build and years to maintain.

Why Distributors Love Pepper’s Order Agent

Building with off-the-shelf tools is a great way to prove to yourself that AI order automation is possible. That part we agree on. But the distance between "possible" and "a system your order desk can actually rely on tomorrow morning" is a lot longer than it looks from the first demo.

That gap is where Pepper's Order Agent lives. Multi-format ingestion, catalog-aware item matching, pack size resolution, customer order guide awareness, ERP-native delivery, and a confirmation workflow that a human can actually trust - all built for food distribution, all integrated with the ERPs our customers already run. Not because we wanted to reinvent an LLM, but because the LLM is the easy 10%.

If you've been scoping a build, we'd love to compare notes. Even if you don't end up buying anything, you'll leave the conversation with a much clearer picture of what the last 90% actually costs.

‍