The sales desk retypes orders every day that already exist digitally.
In wholesale and manufacturing, orders arrive through several channels at once: as free text in the email body, as a PDF attachment in whatever layout the customer happens to use, and as a fax scan from the customers who never stopped faxing. The sales desk opens every order one by one and types the line items into the ERP.
The typing is not the slow part. The looking up is. Long-standing customers order under their own part numbers or under numbers from a catalog three years old. So the clerk searches the article master for what is actually meant. Then a second window is used to check which price applies: price list, framework agreement, quantity tier.
And typing errors do not stop at the order. A wrong part number becomes wrong picking, a wrong delivery, a credit note, and a phone call with the customer. At the same time the order confirmations wait until the pile is done.
We measured the match rate first, then built the software.
Order entry is one of the few cases where you can see whether it works before you build it. The proof already sits in the mailbox. And the team’s conditions became the specification: the order is never posted directly, unclear line items are stopped, and the sales desk maintains the mapping itself. The most common objection in the first conversation is: our customers order chaotically, no machine understands that. That chaos is exactly the use case, because the clean orders already run through EDI.
- Sample of real orders: A batch of orders from the last quarter, from email, PDF, and fax scan, run through reading and mapping. The result is a measured match rate per channel, not an estimate.
- Build the customer part number mapping: The knowledge in the heads of two long-serving clerks, which customer part number means which article, gets written down. From the order history, from delivery notes, and from every correction the team makes during the pilot.
- Connect the ERP as a draft target only: The AI employee gets write access exclusively for unreleased sales orders. No direct posting. That is the decision that makes everything else defensible.
- Go-live only after the team’s okay: The sales desk reviewed the open-case pile for a week and wrote down what was missing. That list became the acceptance criteria. The system went live once the clerks said: this is faster than by hand.
85 percent is done by the AI employee. The human decides at two points.
The AI employee first recognizes whether an incoming message is an order at all, or a question, a reminder, or the reply to an order confirmation. Then it reads the header data, meaning customer, customer order number, requested date, and delivery address, and every single line item. Whether from the email body, from a PDF in any layout, or from a fax scan.
Mapping runs across three levels: the customer part number mapping, the article master, and this customer’s order history. After that, prices and terms are checked against the ERP. Whatever fits cleanly is filled in. Every deviation and every open line item is flagged with a reason. The result is a draft order in the ERP and a draft order confirmation, never a finished posting.
Email from an existing customer, order written in the message body: 12 line items with the customer’s own part numbers, one of them with an outdated part number.
One of twelve line items is flagged: the customer ordered under a number that was replaced two catalogs ago. Substituting an article is a sales decision and stays with the sales desk.
That was before, this is today.
This is how order entry ran before, and this is how it runs today with the AI employee. Conservatively calculated, that saves about 85 percent of the time per order.
| Before | Today | |
|---|---|---|
| Effort per order | 10 to 20 minutes of retyping and checking | 1 to 2 minutes to release the draft |
| Article mapping | Searched by hand in the article master | Mapping and order history, maintained by the team |
| Price check | By hand in a second window | Automatic against framework agreement and price list |
| Errors | Typos travel all the way into the delivery | Unclear line items are stopped, not posted |
| Order confirmation | Goes out when the pile is done | Draft is ready together with the order |
* Baseline generalized from process mappings in sales desk teams. Savings conservatively calculated: a free-text order with a double-digit number of line items costs 10 to 20 minutes of retyping, looking up, and price checking before, and 1 to 2 minutes today to review and release the draft. That is 80 to 95 percent, conservatively stated as about 85 percent. At dozens of orders per day this adds up to several hours daily.
How do you build an AI employee like this, technically?
The knowledge from this scenario to take away, whether you build with us or on your own:
Reading: vision models instead of form recognition
Classic form recognition expects a fixed layout and breaks on the first new order template. Vision models like Mistral OCR, GPT from OpenAI, or Claude from Anthropic read a PDF and a fax scan the way a person reads them: table, free text, handwritten note in the margin. That is exactly what you need when every customer sends its own format.
Mapping articles: an explicit mapping beats probability
Mapping runs across three levels. First the customer part number mapping, meaning customer number plus customer part number resolves to your article. A hit there is deterministic and beats any guess. Then the article master for your own numbers and descriptions. Last the order history: what did this customer receive the last time they wrote it this way.
EDI or AI employee: both, not either or
EDI is the right answer for connected key accounts and stays that way. Its limit is the effort per connection, because every partner is its own project. That is why EDI usually covers a handful of large accounts. The AI employee handles everyone else: the customers who order by email, PDF, and fax and will not be connected for years.
ERP creation: draft instead of direct posting
A posted order sets things in motion: stock gets reserved, the warehouse picks, sometimes a confirmation goes out automatically. A draft is reversible, a posting is not. That is why the AI employee gets write access in SAP or Microsoft Dynamics only for unreleased sales orders. It costs one click per order and takes the whole risk of a wrong posting out of the project.
UX: the interface decides adoption
A review screen shows the order on the left and the recognized line items on the right, side by side, row by row. Every line item shows what it was matched against. Follow-up questions to the customer are ready as an editable draft, nothing goes out unseen. And the mapping has its own view where the sales desk changes it itself.
What does it cost in comparison?
Superkind charges per use case. The price grows with order volume, not with headcount. Here is the honest comparison:
| Manual retyping | EDI connection | Superkind AI employee | |
|---|---|---|---|
| Cost | 55,000 to 75,000 € per year per sales desk position | 1,000 to 5,000 € setup per partner, plus running fees | Price per use case, a fraction of a full-time position |
| What is included | The whole process, by hand | Only structured messages from connected partners | Reading, article mapping, price checks, ERP draft, and order confirmation |
| Scales with | More staff | Every new partner is a new project | Volume, without new positions |
| Exceptions | Human does everything | Fall out of the standard and land in the ERP by hand again | Flagged and sent to a human |
| Rollout | Recruiting and onboarding | Months per partner | 2 to 3 weeks to the first productive version |
The honest comparison is the full cost of manual entry: the retyping itself, the lookups in the article master, the credit notes from wrong deliveries, and the confirmations that go out a day late.
What we learned from these projects.
The objection is always the same: our customers order chaotically, no AI can handle that. The sentence is loud, but weak. Disorder is not a wall, it is a measurable quantity. You can take a hundred real orders, run them through the mapping, and know the match rate per channel before a single line of integration code is written. We have not yet met a team that regretted the day spent on it.
The second thing: the bottleneck is almost never the reading. The bottleneck is the master data and the knowledge that was never written down. Which customer part number means which article. Which price applies to whom. Which customer always means the plant address and not the billing address. Automating order entry forces that knowledge out of two heads and into an editable table. That alone changes what happens when those two people are on vacation.
What it is not suited for: If nearly all customers already order through EDI or a web shop, order entry is not your bottleneck. In engineered-to-order work, where every order is a technical conversation about dimensions and tolerances, there is no routine to automate. And without a maintained article master the AI employee inherits your ambiguity and flags more than it resolves.
