Case study
AI implementation case study: taking an order entry pilot into production for a manufacturer
ResultAn order entry pilot became a production workflow with its own ERP identity, tested exception handling and an operational handover to IT.
- Client
- A US industrial manufacturer (anonymised)
- Industry
- Industrial manufacturing
- Service
- AI implementation: done defined, access, build and evaluation, rollout and handover
- Type
- A proven order-entry pilot prepared for production
- Status
- Delivered
We took an industrial manufacturer's order entry pilot into production. The pilot could read emailed purchase orders, but lacked the access controls, exception handling and operating procedures needed for live use. We built those controls around the existing reading capability and handed the workflow to the manufacturer's IT team.
The starting point
Distributors sent orders as PDFs, spreadsheets and email text, which the order desk entered into the ERP. The pilot had demonstrated extraction on clean orders using a team member's login. Changes, cancellations, unfamiliar delivery addresses and contract-price differences still needed defined handling, and operational ownership had not yet been assigned.
What we delivered
We agreed an acceptance test with the sponsor and order desk before implementation. The system received a dedicated ERP identity limited to creating sales orders and attaching source emails. Tested code validates contract prices, credit limits, stock and required fields before writing an order. Conditions requiring judgement route the order to a review queue.
Rollout and handover
The integration was exercised in the ERP sandbox and then run alongside the order desk. Clerks reviewed proposed orders, with disagreements added to the evaluation set. We enabled order types in stages and retained a tested manual fallback. Handover included the runbook, decision log, monitoring and exercises in releasing and undoing a change.
Where people remain in control
| Decision | Agreed decision | Who signs |
|---|---|---|
| What done means | Every order in the test set entered as the order desk would have entered it, or handed to a person for a reason on the list | The sponsor, the VP of operations |
| Where the system of record stays | The ERP, as now: the system reads the email and writes one sales order | The ERP's owner |
| What it may write | New sales orders with the source email attached; never prices, customer records or credit limits | The ERP administrator |
| Whose credentials it acts under | An identity of its own in the ERP, never a clerk's, so the audit trail can tell software from people | Security |
| When it asks the order desk to review | A change or cancellation of an earlier order, a ship-to address not on file, a price off the contract, an unknown part number, an account over its credit limit, or a field read with low confidence | The order desk manager |
| Hosted or self-hosted models | Hosted, since nothing in a purchase order rules it out | Security and the CFO |
| How it is evaluated | The test set from the first phase, rerun and recorded for every release | The order desk manager |
| What is monitored | Orders entered with no correction afterwards first, then cost per order, then time from email to order | The IT team that runs it |
| Who operates it | The IT applications team, named before the build, with the handover test written for them | The IT director |
| What happens at rollback | The order desk can continue entering orders through the tested manual process for an agreed period after launch | The order desk manager |
| What the company keeps | Everything: code, infrastructure definitions, prompts, the test set and the decision log, in its own repositories and accounts | Set in the delivery agreement from the start |
Project outcome
The delivery turned a demonstration into an owned operational workflow. The manufacturer retained the code, prompts, evaluation set and infrastructure definitions in its repositories and accounts. IT received the procedures needed to monitor the system, extend its tests and stop processing when required.
How performance is evaluated
| Measure | How it is measured | Comparison point |
|---|---|---|
| Orders entered with no correction afterwards | Orders that needed no correction after entry, over all emailed orders | The order desk's own rate, from a month of corrections before the work |
| Cost per order | Order desk hours plus the monthly run cost, over orders entered | The same month |
| Time from email to sales order | Time stamps at arrival and at entry | The same month |
| Orders handed to a person, by condition | Each hand-off logged with the condition that fired | The parallel run |
| The definition of done | The written test, rerun and recorded for every release | The pilot's own result on the same test |
| Time from a proven pilot to production | From the signed definition of done to the passed handover test | The proven pilot before production implementation |
Technologies and tools
- A hosted language model, reading each emailed order
- Checks and writes in tested code
- The ERP's API, under the system's own identity
- A review queue for the order desk
- Monitoring of corrections, cost per order and time to entry
- The company's own repositories and cloud account
More case studies
All case studies- Case studyAn AI inventory, approval process and evidence pack for a software companyProduct features and internal AI tools were brought into one register, with named owners, change approvals and evidence for customer security reviews.
- Case studyMigrating SQL Server reporting to SnowflakeA SQL Server reporting warehouse was migrated to Snowflake through parallel running, reconciliation and report-owner sign-off.
Bring us the pilot that's ready for a path to production
Tell us what the pilot proved, which data it used and what it still needs for live operation. An engineer replies within two business days with a practical definition of done and the decisions that need an owner.