AI order entry
Turn order e-mails into shipments you can check.
An order arrives as an e-mail with a PDF hanging off it. Orin reads both, fills in a draft shipment, marks what it is unsure about, and shows the words each value was read from. Your dispatcher confirms instead of retypes.
Attachment 1 · transport-order.pdf
From: planning@aalsveld-chemie.nl
Subject: Transport order 330909, Alblasserdam to Boechingen
Afternoon, Please plan the load below for Friday. Collection from our own site, delivery Monday morning at the latest.
- Collection
- Aalsveld Chemie B.V., Edisonweg 12, 2952 AD Alblasserdam (NL), Fri 26 Sep 07:00-12:00
- Delivery
- Sudwerk GmbH, Industriestrasse 4, 76891 Boechingen (DE), Mon 29 Sep before 16:00
- Goods
- 6 pallets general cargo, 3.7 ldm, 1,200 kg
- Price
- EUR 583.00 all-in
- Reference
- 330909
Draft shipment
Click a row
| Field | Extracted value | Conf. |
|---|---|---|
Click a value on the right and the words it was read from light up on the left. Anything under 90% is marked for a look before you confirm.
E-mail and PDF
It reads the message body and the attachments, not one or the other.
Marks its doubt
A score per field, so review goes to the values worth checking.
Shows the source
Click a value and the words it was read from light up in the document.
You confirm
By default nothing reaches your operation until a person accepts it.
It reads the email and the attachments, and marks its own uncertainty
An order e-mail and its attachment go in, and what comes back is a draft with its own uncertainty marked. Instead of a confident-looking form you get to see which fields are worth a second look.
- Around 26 fields per order: addresses, dates and time windows, references, goods lines with weight and loading metres, per-stop contacts and gate instructions, agreed price and currency.
- Goods come out as separate lines with their own quantities, weights, volumes and ADR flags, not one aggregated description you have to unpick.
- Each field carries a confidence score. It says how sure the reading was, not that the value is correct: it is there so a dispatcher checks the three doubtful fields rather than re-reading all twenty-six.
- Inbound addresses are bound to one department or one named planner. Catch-all addresses are refused at receive time, deliberately: an order nobody owns is an order nobody reviews.
Every value points back at where it came from
A number in a form is a claim. Reviewing it means checking it against the document, and if that means opening the PDF separately and hunting for the line, nobody does it twice. So the source travels with the extraction.
- Each field links to its origin: the exact character span in the email, or the page and position in the PDF.
- A side-by-side viewer opens in its own window (drag it to a second screen) with the original on one side and the confidence table on the other. Click a field, the source highlights.
- Edits stay in sync between that viewer and the shipment page; both read the same server state, so two windows never disagree.
- Wrong order entirely? One click sends a templated reply back to the sender, with your signature and their message quoted, and cancels the draft through the normal cancel path.
It learns from your corrections, and they stay yours
The first extraction from an awkward customer format is never the best one. What matters is whether correcting it once is enough, and whether that correction stays inside your business.
- Confirming an extraction stores the accepted field set as an example. The next extraction retrieves the most similar past corrections and uses them: there is no "save as template" step to remember.
- The bank is per tenant. Your corrections sharpen your extractions and never cross into another company's.
- Approving a carrier invoice teaches that carrier's layout the same way, so the second bill from an awkward supplier reads better than the first.
- A pooled bank across customers exists as a separate opt-in. It ships off, and with it off nothing you correct leaves your account.
Where it runs
Order intake is the one everybody demos, and it is a fraction of where the models actually run. Three kinds of work, each surface with its own versioned prompt rather than one general-purpose one.
- Reading documents. Order e-mails and their attachments, carrier and supplier invoices matched to the trip, signed PODs and CMRs, and rate cards into versioned templates.
- Proposing data. An inbound EDI mapping from a pasted sample, a price for a new shipment from your own history, and optimizer settings for a run.
- Answering questions. A planning copilot inside the board, an assistant for your customers in their portal, and support chat in the app.
Control and auditability
Six months later, you can still find out what happened
A customer disputes a shipment that came out of a bad reading. The question is what you can reconstruct: the message it came from, the values that were accepted, and who accepted them.
For the people who will ask
- Every call is stamped with its prompt version, schema version, model and source document, so the exact conditions that produced a result are recoverable.
- Any historical extraction can be re-run against the current prompt and model, side by side with the original and with drift flagged. It is also how a model upgrade is validated against real production inputs before it becomes the default.
- Spend is visible per feature over 30 days with a cache-hit rate, so “we use AI” has a number attached rather than a surprise.
- Every extraction is kept together with the document it was read from, so the original message and the values that were confirmed are both still there.
- The review history shows what the reading proposed, what was changed by hand, and who confirmed it.
- Auto-confirming high-confidence readings is opt-in and ships off. Turn it on and the threshold is yours; auto-applied shipments keep a banner flagging them for review either way.
- Auto-confirming high-confidence extractions is opt-in and ships off. Turn it on and the threshold is yours; a banner keeps flagging auto-applied shipments for review either way.
How it is operated
What decides whether AI is safe to run in production is the machinery around it. Ours is a platform layer we operate, not a console you have to learn.
- Prompts are versioned, and a version is deployed rather than edited in place. Deployment is append-only, so what was live on any given day is recoverable.
- A version can be rolled out to a single customer. A change is proven on one operation before it reaches everyone, which is the opposite of how most AI features ship.
- Any historical call can be re-run, one at a time or in bulk, against a newer prompt or model. A bad result is something to reproduce and fix, not to apologise for.
- Spend and cache-hit rate are tracked per prompt version and per tenant. When cost moves, the version that moved it is visible rather than inferred.
Questions we get asked
Is my data used to train a model?
No. Your corrections are stored as retrieval examples for your own account and threaded into your own future extractions: no model is trained or fine-tuned on your data. A pooled bank across customers exists but is opt-in and off unless you switch it on.
What happens when it gets something wrong?
The dispatcher corrects it before confirming: that is what the review queue is for, and the confidence scores point at the fields worth checking. The correction then becomes an example, so the same customer's next order comes through better. Nothing reaches your operation without a person accepting it, unless you have explicitly turned auto-confirm on.
Can it create a shipment without anyone looking at it?
Not unless you ask for it. The default is that a person confirms every reading before a shipment exists. Auto-confirm is a separate setting, off out of the box; if you switch it on you set the confidence threshold yourself, and auto-applied shipments still carry a review banner. Supplier invoices are stricter again: a reading never posts a bill, whatever the flags say.
What else does it read besides orders?
Carrier and supplier invoices: matched to the trip with differences flagged before you pay. Signed PODs and CMRs, for signature detection, references and damage notes. Incoming EDI, for mapping. Rate cards, into versioned rate templates. And your past optimizer runs, to suggest solver adjustments. Same framework, same audit trail on all of them.
Does the AI change my planning by itself?
No. The routing advisor reads past run results and proposes solver changes as a plain-language goal, trade-off and risk, but it can only touch sixteen allow-listed levers, it always produces a draft, and a planner activates it. It cannot alter a live plan.
See it read an order.
Book a demoThirty minutes on example orders, nothing needed from you beforehand. Want it to read one of your own? Bring the document to the call.