ORDER AUTOMATION
Running order automation alongside your existing process: a 90-day plan
What Weeva is
Weeva is an AI order automation platform for distributors, wholesalers and manufacturers. It reads customer orders and supplier delivery notes in any format and creates the sales order or GRV in your ERP.
The safest way to adopt order automation is to run it in parallel with your current process, on your own orders, before anything is switched over. A practical 90-day plan has three stages: discovery in week one, integration on real orders with strict thresholds, then scaling forward one customer cohort at a time, with continuous tuning.
Why run order automation in parallel first?
Your order desk already works. Orders are captured, trucks leave, customers are invoiced. Any change to that process carries risk, and the people who carry the risk are the ones on the desk.
Running in parallel removes most of it. The new system processes real orders beside the existing process. Nothing depends on it until you have seen it work on your own documents, your own catalogue and your own customers. There is no big-bang cutover.
Parallel running also produces the only evidence that matters: how the system performs on your orders. Vendor accuracy claims are measured on someone else's documents. Yours will be different.
What does a 90-day plan look like?
Timings vary with order volume, the number of customers and the ERP. This is the shape Weeva uses, with the parallel run measured on your own documents.
| Stage | When | What happens | Done when |
|---|---|---|---|
| Discovery | Week 1 | Walk through the process, sample orders, catalogue and customer list | Weeva has what it needs to read your orders |
| Integration | Weeks 1 to 2 | Go live on real orders, connected to the ERP, in parallel with the current process | Real orders flow into Weeva beside your process |
| Scale forward: first cohort | From week 3 | Parallel running continues for one group of customers until the measures say switch | That cohort runs without the old process |
| Scale forward: further cohorts | To day 90 and beyond | More cohorts switch; thresholds and rules are tuned | The cohorts you chose run through Weeva |
A 90-day rollout plan for order automation
Discovery
- When
- Week 1
- What happens
- Walk through the process, sample orders, catalogue and customer list
- Done when
- Weeva has what it needs to read your orders
Integration
- When
- Weeks 1 to 2
- What happens
- Go live on real orders, connected to the ERP, in parallel with the current process
- Done when
- Real orders flow into Weeva beside your process
Scale forward: first cohort
- When
- From week 3
- What happens
- Parallel running continues for one group of customers until the measures say switch
- Done when
- That cohort runs without the old process
Scale forward: further cohorts
- When
- To day 90 and beyond
- What happens
- More cohorts switch; thresholds and rules are tuned
- Done when
- The cohorts you chose run through Weeva
What happens in week one?
Discovery is a working session, not a questionnaire. We walk through your current process with the people who run it, from the moment an order arrives to the moment it is in the ERP.
- A sample of real orders, including the awkward ones: the handwritten notes, the forty-page PDFs, the WhatsApp photos.
- Your product catalogue, with units of measure, pack sizes and price lists.
- Your customer list, including the codes customers use for themselves.
- Your ERP, and who owns it.
- The people who should review orders, and what they need to see.
Ingestion, extraction and catalogue matching then go live on real orders, connected to your ERP. Discovery and integration typically run inside the first week. From here, Weeva sees every order your desk sees.
How should parallel running work day to day?
During parallel running, your desk keeps capturing orders the way it does today. Weeva processes the same orders into its inbox. Someone on the desk compares the two, order by order, and corrects Weeva where it is wrong.
Those corrections are the point. Every confirmed product match, every unit calibration and every customer code is remembered. The same customer, format or description is handled automatically next time. This is why the first weeks carry more review than later ones.
Pick one person to own the comparison. Usually it is the order desk lead, because they already know every customer's habits. Give them a short daily slot for it, rather than asking them to fit it around everything else.
How should confidence thresholds be set?
Every field Weeva extracts carries a confidence score. The threshold decides which fields a person must confirm. You set it, and you can change it.
- Start strict. During parallel running, a high threshold sends more to human review, which is what you want while trust is being built.
- Choose required fields. Decide which fields must be present before an order can be marked ready: customer, PO number, delivery date, or whatever your business needs.
- Watch the review reasons, not only the count. If most reviews say 'SKU not in catalogue', the fix is in the catalogue, not in the threshold.
- Relax the threshold as evidence builds, not before. Weeks of correct orders are a better guide than a default setting.
How do you measure results on your own orders?
Decide what you will measure before parallel running starts, so nobody argues about it afterwards. Keep it simple and count it weekly.
| Measure | How to count it | What it tells you |
|---|---|---|
| Orders ready without review | Orders that reached ready with no field corrected | How much of the flow needs no one |
| Fields corrected per order | Corrections recorded in the audit log | Where extraction is still learning |
| Lines matched without review | Lines resolved to a SKU with no confirmation | How well matching knows your catalogue |
| Review reasons by type | The reason on each order sent to review | Whether the fix is in the model or the data |
| Time per order | Desk time before and after, for the same customers | The effect on your team's day |
What to measure during parallel running
Orders ready without review
- How to count it
- Orders that reached ready with no field corrected
- What it tells you
- How much of the flow needs no one
Fields corrected per order
- How to count it
- Corrections recorded in the audit log
- What it tells you
- Where extraction is still learning
Lines matched without review
- How to count it
- Lines resolved to a SKU with no confirmation
- What it tells you
- How well matching knows your catalogue
Review reasons by type
- How to count it
- The reason on each order sent to review
- What it tells you
- Whether the fix is in the model or the data
Time per order
- How to count it
- Desk time before and after, for the same customers
- What it tells you
- The effect on your team's day
The audit trail records every edit with the value before and after, the user and the time, so most of these can be read from Weeva rather than tallied by hand. The dashboard shows review and correction rates by field.
What happens if something goes wrong during the rollout?
Things will go wrong, and the rollout is designed so that they fail safely. If the ERP is unavailable, the order waits, the error is shown to the operator, and nothing is retried silently. Pushes to the ERP are idempotent, so a retry never creates a duplicate sales order.
If a document cannot be read, it goes to review with a plain reason. If a customer is not in your list, a person picks the right one or asks for it to be created; Weeva never creates customers on its own. Nothing is pushed to your ERP without a record.
When should you switch over?
Switch when the measures say so, not on a date. A sensible test: for a given group of customers, the desk has stopped finding errors that Weeva's review step did not already flag.
Switch by cohort, not all at once. Good first cohorts are customers who order often, in consistent formats, with stable catalogues. They build evidence fastest. Leave the most irregular customers for later, when the model has learned more.
On switch-over, the desk stops keying orders for that cohort. Weeva's inbox becomes the process: ready orders go to the ERP, orders needing review get a person's attention, and everything is recorded.
How do you scale across more customers?
Each further cohort follows the same pattern, but faster, because the catalogue matches, unit calibrations and price lists already learned apply across customers. Continuous tuning carries on after day 90: thresholds are adjusted, new customers are added, and new channels such as WhatsApp or watched folders are switched on.
Scaling is also the moment to look at adjacent work. Goods Receiving Automation applies the same approach to delivery notes. Stock Data Audit cleans the item master that both depend on.
What does this mean for the order desk?
The order desk does not go away. It stops re-typing and starts reviewing. The judgement the team already applies, knowing which customer means what, becomes the training signal that makes the system better.
That shift is worth planning for. Involve the desk lead from discovery. Let the team see their corrections take effect. Measure time saved, and decide together what the desk does with it: faster turnaround, earlier cut-offs, more attention to key customers.
The first step is a 30-minute demo. Bring a few of your own sample orders, and we will show you the extraction and catalogue matching live. See Sales Order Automation for how each order is handled.