Forward-Deployed Engineering · Distribution · Order to cash
Case study: customer purchase orders, from the inbox to a sales order in the ERP
Illustrative engagement — not a client record. The company, people, volumes and results below are a representative composite, written to show how a forward-deployed engagement runs end to end. The workflow, the architecture, the controls and the method are real and technically valid.
Offering usedReadiness & Scoping SprintTwo weeks inside your systems; one workflow scoped in writing.
Illustrative results, first 90 days after cut-over, in-scope orders only:
54%
Email orders becoming a sales order with no re-keying
Before 0%
1.2 working hours
Median time from order received to order confirmed
Before 6.4 working hours
99.6%
Line-level accuracy of released orders, weekly audit sample
Before not measured
83%
Ordered lines matched to a SKU by a stored cross-reference
Before 41%
A1:C9Explainer
The whole story in about a minute
Nine short scenes, from orders typed by hand to the results. Press play, or pick a scene.
Row 01 · Before
Read chapter 1Every email order was typed in by hand.
About 9,400 orders a month, and most came by email as PDFs, spreadsheets, scans or plain text. Sixteen representatives typed them into the ERP, with a median of 6.4 working hours to confirm one.
Ordered lines
About 9,400 orders a month
- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
Unit unclear
Order to confirmation
6.4 working hours
the median, longer near month end
16 representatives typing
4 in 10
ordered lines matched by the cross-reference table
- About 9,400 orders a month
- 16 representatives typing
- About 4 in 10 lines matched
At a glance
- Client
- A distributor of industrial consumables and lubricants: four warehouses, around 2,200 active trade customers, one central customer service desk
- Workflow
- Customer purchase orders arriving by email as PDF, spreadsheet, scan or free text, turned into a sales order in the ERP, with exceptions sent to customer service with reasons
- Engagement
- Readiness & Scoping Sprint (2 weeks), then Production Sprint (6 weeks)
- Team
- One named senior forward-deployed engineer, full time. Client side: the Customer Service Manager (owner), a senior customer service representative, the pricing analyst, the credit controller, an ERP analyst, a platform engineer
- Where it runs
- The client's own cloud account and region. No data retained outside it
- Handover
- Runbook executed by the client's team in week six of the build; our access revoked the same day
| Measure | Before | After |
|---|---|---|
| Email orders becoming a sales order with no re-keying | 0% | 54% |
| Median time from order received to order confirmed | 6.4 working hours | 1.2 working hours |
| Line-level accuracy of released orders, weekly audit sample | not measured | 99.6% |
| Ordered lines matched to a SKU by a stored cross-reference | 41% | 83% |
| Price-mismatch or credit-hold orders released automatically | not applicable | 0, by design |
FDE / 01Case study
01 / 12
In shortMost orders came by email and were typed into the ERP by hand, slowly and with mistakes.
The desk received about 9,400 customer purchase orders a month, averaging seven lines each. Roughly a third arrived through the customer portal or an electronic feed and needed no typing. The rest came by email, and sixteen customer service representatives typed them into the ERP:
PDF purchase orders, about half of the email volume, mostly generated by the customer's own ERP, in perhaps 150 different layouts.
Spreadsheets, a fifth, ranging from a proper template to a column of descriptions.
Scans and photographs of signed order forms, a tenth, from customers who still work on paper.
Free-text emails, the rest: "please send 20 cartons of the 68 grade hydraulic oil to the Hosur plant, PO attached to follow".
Typing was the visible cost. The invisible ones were larger:
Matching parts. Customers order in their own part numbers, in manufacturer part numbers, or in words. The ERP held a customer cross-reference table, but it covered about four in ten ordered lines and nobody owned it. Representatives kept their own spreadsheets. When one of them was on leave, her customers' orders slowed down.
Units. A customer ordering "10 boxes" of a fastener that the client sells in packs of 100 is the most expensive kind of ambiguity, because nothing about the order looks wrong until the delivery arrives.
Prices. Contract price lists expired quietly. The order said one price, the ERP said another, and the representative had to decide whose figure to use while the customer waited.
Cycle time. A median of 6.4 working hours from arrival to confirmation, and considerably longer near month end, when the same people were chasing dispatches.
Errors. Wrong item, wrong pack size and wrong ship-to between them caused a steady trickle of returns and credit notes, absorbing warehouse and accounting time well beyond the value of the line.
FDE / 02Case study
02 / 12
In shortMoving everyone to the portal and building a template per layout were both discussed and dropped.
There had been no pilot. Two attempts had been discussed and dropped:
Push everyone onto the portal. It worked for the largest customers. The long tail — small workshops, plant purchasing clerks, buyers who forward the order their own system produced — did not move, and the sales team would not push them.
Template-based capture. A proposal to build a template per customer layout foundered on the arithmetic: 150 layouts, changing whenever a customer upgraded their ERP, for a team that could not maintain the cross-reference table it already had.
There was also a belief inside the business that the hard part was reading the document. It is not. Reading a purchase order is the easy half. Deciding which of your 41,000 SKUs the customer meant, at which price, out of which warehouse, to which address, on what credit terms, is the work.
FDE / 03Case study
03 / 12
In shortTwo weeks of scoping showed the hard part is matching parts, units and prices, not reading.
Ten working days: four with the customer service desk, one each with pricing, credit and the warehouse, and the rest reading the ERP and a year of order history. Access to a read replica was requested on day one and arrived on day four; that delay was recorded in the access register and shaped the build plan.
What was found:
FIG. 3.1- The price problem was not the customers' fault. The sales director believed most price mismatches were customers quoting old prices. In the sample, most were the client's own expired contract price lists, still attached to customers whose renewal had not been keyed. That is a data problem the automation must not paper over.
- Cross-reference coverage was worse than reported. 41% of ordered lines matched a stored customer part number. Representatives were carrying the rest in their heads and in private spreadsheets.
- Unit-of-measure differences affected about one line in nine, and were the largest single cause of credit notes in the returns log.
- The ERP had an approved interface for creating sales orders in a draft, unreleased state, already used by the portal feed. Write-back could use the same path and the same permissions a representative has.
- Around 700 customers accounted for most email order volume, and 30 of them accounted for a quarter of it.
- Nobody had written down what "confirmable without asking" meant. The credit controller, the pricing analyst and the desk had three different answers.
The one-page scope, signed by the Customer Service Manager:
- WorkflowEmail purchase orders from the top 700 trade customers — PDF, spreadsheet, scan and free text — to a sales order in the ERP, or to an exception with a reason
- Out of scopePortal and electronic-feed orders, phone orders, quotations, returns and credit notes, project and made-to-order lines, new customer onboarding
- MetricShare of in-scope orders becoming a released sales order with no re-keying, at or above 99.5% line-level accuracy on the golden set
- OwnerCustomer Service Manager
- GuardrailsA price different from the agreed price is never released automatically. A customer on credit hold or over limit is never released automatically. A ship-to address not already on the customer's record is never released automatically. A line whose SKU is not certain is never guessed
- Exit gateOne week of shadow-run parity, one week live with rollback armed, runbook executed by the client's own engineer
The pricing analyst also produced, for the first time, a list of customers whose contract prices had expired. Clearing it removed more exceptions than any later change to the matcher.
A1:C9Timeline
The engagement, stage by stage
Nine stages on one clock, from the typed-in orders to ninety days after cut-over. Press play, or pick a stage.
Task 01 · Before
Read chapter 1Every email order was typed in by hand.
About 9,400 orders a month, and most came by email as PDFs, spreadsheets, scans or plain text. Sixteen representatives typed them into the ERP, with a median of 6.4 working hours to confirm one.
6.4 h
median from order received to order confirmed
- About 9,400 orders a month
- 16 representatives typing
- About 4 in 10 lines matched
FDE / 04Case study
04 / 12
In shortSix weeks: connect it, build the rules, shadow the desk, switch it on, hand it over.
The three days were the paused clock in week four
W0Scope
What happened
Scope page signed; access requested for the order mailbox, the ERP read replica, the sandbox and the sales order interface
What existed at the end
The signed scope and an access checklist
What happened
Scope page signed; access requested for the order mailbox, the ERP read replica, the sandbox and the sales order interface
What existed at the end
The signed scope and an access checklist
What happened
Repository created in the client's source control; engineer joined the desk's morning huddle
What existed at the end
First pull request merged on day seven: mailbox intake landing orders and attachments in the client's storage, hashed and threaded
What happened
Reading and SKU matching running behind a feature flag on real orders. Golden set agreed with the desk
What existed at the end
A working prototype and a golden set of 1,000 historical orders with known answers
What happened
Price and stock checks, credit and ship-to rules, exception queue with reasons, draft acknowledgements, ERP write-back, audit log, dashboards. The ERP sandbox was unavailable for three working days during a vendor patch; the clock paused, as agreed at scoping. Shadow run began at the end of week four
What existed at the end
A system deciding every in-scope order in parallel with the desk, without releasing anything
What happened
Live for 30 customers, then 200, then all in scope, each step gated on the shadow comparison
What existed at the end
Real orders released, rollback one switch away
What happened
Client's ERP analyst added a customer layout, approved a new cross-reference and ran a release and a rollback without us at the keyboard
What existed at the end
Signed runbook, decision record, revoked access
The three days were the paused clock in week four
Calendar time was six weeks and three days. The three days were the paused clock in week four, written down on the day it happened.
FDE / 05Case study
05 / 12
In shortA system that reads every order, lets rules decide, and gives people a filled draft when it cannot.
A1:D9Try an order
Pick what the customer sends. Watch where it goes.
The same pipeline reads every email order. The rules decide whether it is released or lands with a representative as a filled draft and a reason.
What the customer sends05
Order log08
- 01Order emailArrives in the order mailbox
- 02IntakeStored in the client's storage with a content hash and the mail thread
- 03ClassifyA purchase order, not an enquiry or a statement
- 04ExtractPO number, ship-to and every line read; each field keeps its evidence
- 05Resolve SKUsEvery line matches a stored cross-reference: certain
- 06CheckAgreed price, stock for the date, inside credit, ship-to known
- 07DecideEvery condition holds: release
- 08Order releasedReleased in the ERP; acknowledgement from the ERP's own template
Order status08 / 08
Order released
- SKUs guessed
- 0
- Runs in
- The client's region
Intake. Messages and attachments land in the client's storage with a content hash and the mail thread, so a re-sent order is recognised as the same order and an amendment is attached to the original.
Classify. A classifier separates purchase orders from enquiries, statements, dispatch chasers and everything else customers send to the order mailbox. Anything else goes to the desk's normal queue, untouched.
Extract. A layout-aware document model reads PDFs and scans; spreadsheets are parsed as data; free-text emails go to the same schema. A language model in a private endpoint in the client's region, retaining nothing, fills a strict schema: customer reference, PO number and date, requested date, ship-to, bill-to, and per line the customer's part number, description, quantity, unit of measure and price. Every field carries the region of the page it came from, so a representative sees the evidence.
Resolve SKUs. This is the part the client had underestimated, and it is built in layers, most certain first:
Stored cross-reference. An exact match on this customer's part number for this SKU, previously confirmed. Certain.
Manufacturer part number held in the catalogue, exact, including supersession chains. Certain.
Candidate ranking. For anything else, a retrieval step over the catalogue proposes up to three candidates with their attributes, and the model explains the differences. This never decides. It hands the representative a choice with the evidence beside it.
Unit-of-measure normalisation. The line's unit is converted into the selling unit by a deterministic table. If the order says "boxes" and the catalogue has no box definition for that SKU, the line is an exception. It is never assumed to be one each.
A mapping becomes a stored cross-reference only after a representative confirms it, and the confirmation is recorded with their name. Coverage grows from the desk's real decisions, not from the model's guesses.
Check. Deterministic rules, not a model: the price against the customer's current agreement or price list; stock and allocation for the requested date against the serving warehouse; the customer's credit status, limit and overdue balance; the ship-to against the addresses already on the customer record; the customer's tax registration for the bill-to, and the state of the ship-to, which decides how the eventual invoice is taxed; and a near-duplicate check on customer, PO number, date and lines.
Decide. Three outcomes only:
Release, when every line resolves to a SKU with certainty, every price equals the agreed price, the ship-to is known, stock covers the requested date and the customer is inside credit. The order is created in the ERP and released as a representative would release it; the acknowledgement goes out from the ERP's own template, populated from the released order.
Draft and exception, for everything else. The sales order is still created in draft, so the representative starts from a filled screen rather than an empty one, and the exception carries a named reason: price difference, credit hold, unknown part, ambiguous unit, new ship-to, short stock. For these, a drafted acknowledgement is prepared for the representative to edit and send, never sent automatically.
Reject, for duplicates and for documents that are not orders.
Safety by design. A model reads the document and proposes candidates. Deterministic rules and named people decide. No model decides a price, a credit release, a ship-to address or whether a line is the right SKU when it is not certain. Price mismatches, credit holds and new ship-to addresses cannot be released automatically; they are not configurable exceptions, they are rules in code, and the new ship-to path includes a call-back to the customer on a number already on the record.
Post. Write-back uses the ERP's approved interface under a service account with the same permissions as a representative. Every order is amendable and cancellable in the ERP in the usual way, and carries the source document.
Audit and monitoring. Every decision, with inputs, rule results, candidate scores and model versions, goes to the client's log store. Dashboards show volume by channel, released share, exception reasons, cross-reference coverage and accuracy from the weekly sample. Thresholds page the platform engineer.
19 objectsSystem map
How the pieces connect
Every part of the system and of the story, lit one scene at a time. Press play, or pick an event.
Object · 01 / 09
Read chapter 1Every email order was typed in by hand.
About 9,400 orders a month, and most came by email as PDFs, spreadsheets, scans or plain text. Sixteen representatives typed them into the ERP, with a median of 6.4 working hours to confirm one.
Linked objects · 03
- Trade customersCustomerIn this scene
- Order mailboxInboxIn this scene
- Cross-referenceDatasetIn this scene
- Portal pushIdeaNot in this scene
- ExtractServiceNot in this scene
- Resolve SKUsServiceNot in this scene
- Check rulesRulesNot in this scene
- DecideGateNot in this scene
- ERPSystemNot in this scene
- Exception queueQueueNot in this scene
- Price agreementsDatasetNot in this scene
- CatalogueDatasetNot in this scene
- Golden setDatasetNot in this scene
- CI gateCheckNot in this scene
- Client teamTeamNot in this scene
- RunbookDocumentNot in this scene
- Rollback flagControlNot in this scene
- One-page scopeDocumentNot in this scene
FDE / 06Case study
06 / 12
In shortA set of 1,000 real orders, scored line by line, that every change must pass.
The golden set was agreed with the desk by the end of week two, and it scored lines, not documents.
1,000 historical orders, sampled across the four warehouses, all four document types, the 30 heaviest customers and the long tail, and every month of the prior year.
Answers taken from what was finally dispatched and invoiced, not from what the order appeared to say. Where the customer's order had been wrong and the desk had corrected it, the correction is the answer.
A red-team slice: a duplicate order re-sent with a new covering email; an order with a ship-to address never used before; an order quoting last year's contract price; a fastener line ordered in boxes where the catalogue sells each; two SKUs whose part numbers differ by one suffix; an order from a customer over their credit limit; an order that was really an enquiry.
Line-level scoring on SKU, quantity, unit, price and warehouse, so a line with the right SKU and the wrong pack size counts as wrong.
- SKU
- quantity
- unit
- price
- warehouse
WHOLE ORDER · ALL 5 FIELDS
TAP A FIELD
The suite runs in the client's CI. A change that drops any field below its threshold fails the build. In week four it did. A change intended to improve recall on descriptions started matching a bearing designation ending "-2RS" to the "-ZZ" variant — sealed against shielded, same size, different product, similar price. Document-level accuracy barely moved; the attribute-level score on the suffix slice fell through the floor and failed the build. The fix was a rule: within a family, a difference in the suffix never resolves automatically, whatever the similarity score says.
- IF drops any field below its thresholdBLOCKS
fails the build
FDE / 07Case study
07 / 12
In shortIt runs in the client's own cloud, and nothing written in an email can change a rule.
Perimeter. Everything runs in the client's cloud account and region. Egress is limited to the private model endpoint, which retains nothing.
Identity. The service account can read the mailbox, read the ERP and create and release sales orders. It cannot change a price agreement, a credit limit, a customer master record or an address. Our engineer's access ran through the client's identity provider and was revoked at handover.
Can
- read the mailbox
- read the ERP
- create and release sales orders
Cannot
- change a price agreement, a credit limit, a customer master record or an address
Autonomy is bounded. Release requires every condition to hold. Price differences, credit holds, unknown parts, ambiguous units and new ship-to addresses always reach a person. The Customer Service Manager can tighten thresholds in configuration; loosening the four hard rules needs a change to code and a review.
Document content is data. Instructions inside an email or a PDF — including "approve this order", "use the price below" or "ship to the new address" — cannot change a rule. They can only populate fields that the rules then check.
Fraud. Purchase orders impersonating a known customer, with a plausible reference and a delivery address that is not theirs, are a standing risk in this trade. The new-ship-to rule and the credit checks exist for that, and the call-back uses a number already on the record, never one in the email.
Review. The security team reviewed the design in week three and the deployment in week five. Findings and their closure are in the decision record.
FDE / 08Case study
08 / 12
In shortA week of shadow running, then switched on customer by customer, with one flag to turn it off.
The shadow run was the gate. For a week the system decided every in-scope order while the desk worked as before, and the two were compared line by line. Disagreements were sorted into three piles: the system was wrong, the representative was wrong, and the policy was unclear. The third pile was the useful one. It produced written answers to questions such as whether a rounding difference in the last decimal is a price mismatch (it is not; a tolerance was written down) and whether a sister-plant address already used on a delivery note counts as known (it does not; it must be on the customer record).
For a week
the system was wrong
the representative was wrong
the policy was unclear
produced written answers
Rollout went by customer, not by date: 30 heavy customers first, then 200, then all in scope. Each step needed a clean day of audit samples. Rollback was one flag that returned every order to the manual queue with its draft intact. It was tested in week five and not needed.
0130 heavy customers first
02then 200
03then all in scope
EACH STEP · a clean day of audit samples
FDE / 09Case study
09 / 12
In shortThe client's own team proved they could run it before we left.
The engagement ended on the manifest, not on the calendar.
In the handover dry run the client's ERP analyst added a new customer layout, scored it against the golden set, released it and rolled it back, with our engineer in the room but not at the keyboard. The runbook was signed after that.
A1:C9Key numbers
The story in nine numbers
One number for each scene, from 6.4 working hours to confirm an order to 54% released with no re-keying. Press play, or pick a number.
Line 01Before
Every email order was typed in by hand.
About 9,400 orders a month, and most came by email as PDFs, spreadsheets, scans or plain text. Sixteen representatives typed them into the ERP, with a median of 6.4 working hours to confirm one.
6.4 hmedian from order received to order confirmed
- About 9,400 orders a month
- 16 representatives typing
- About 4 in 10 lines matched
Median 6.4 h
- 01
- 02
- 03
- 04
- 05
- 06
- 07
07 / 07
FDE / 10Case study
10 / 12
In short54% of orders released with no re-keying, confirmed far sooner, and cross-reference coverage from 41% to 83%.
Figures are illustrative, measured on in-scope email orders over the first 90 days after cut-over.
54% of in-scope orders became a released sales order with no re-keying. The rest arrived as a filled draft with a named reason, not a blank screen.
BEFORE0%AFTER54%Median time from receipt to confirmation fell from 6.4 working hours to 1.2. Orders arriving overnight were confirmed before the desk opened.
99.6% line-level accuracy on the weekly audit sample, against a 99.5% threshold. Wrong-pack-size credit notes fell by more than half.
AFTER99.6%Cross-reference coverage of ordered lines rose from 41% to 83%, because every confirmation the desk made was captured instead of being retyped tomorrow.
BEFORE41%AFTER83%No order with a price mismatch, a credit hold or a new ship-to was ever released automatically, because the design does not allow it.
Nobody left the desk. Two representatives moved onto customer onboarding and the cross-reference backlog, which had never had an owner.
What did not improve, and was never promised:
FIG. 10.2Free-text emails that do not name a product — "the usual monthly order", "same as last time" — are still read by a person. They were 4% of volume and the system refuses to guess them.
Phone orders were out of scope and are unchanged.
Back orders did not fall. Short stock is a buying and forecasting problem; faster order entry only surfaced it sooner, which the buying team, on balance, preferred.
FDE / 11Case study
11 / 12
In shortSix rules for anyone automating order entry.
- Reading the order is the easy half.
Budget your effort for part matching, units and prices, because that is where the exceptions live.
- Let coverage grow from confirmations.
Every mapping a representative confirms should be stored the moment it is made. Do not ask anyone to clean the table first.
- Never resolve on similarity alone.
In catalogues built from families and suffixes, the nearest match is often the wrong product.
- Write the tolerances and the hard rules down separately.
Tolerances are configuration. Price, credit, ship-to and uncertain SKUs are code.
- Fix the price data while you build.
Half of the price mismatches were the client's own expired agreements.
- Score lines, not documents.
A document-level number hides exactly the errors that cost money in the warehouse.
FDE / 12Case study
12 / 12
In shortThe client kept it in-house, extended it to a second mailbox, and came back for more.
The client kept the system in-house. In the following quarter their own team extended intake to orders arriving through a second mailbox used by the export desk, using the same harness and runbook. They came back for a second Production Sprint on order acknowledgements and delivery-date commitments, which had been deliberately left out of the first scope.