How to automate order entry: EDI, a customer portal, OCR or an agent connected to your ERP
There are four ways to stop keying customer orders into the ERP: EDI with the customers who can send it, a portal where customers key their own orders, OCR or template capture for a few stable layouts, and an agent connected to the ERP that reads whatever arrives and holds what it cannot confirm. Most manufacturers and distributors end up with two or three of them, split by customer. This guide shows what your ERP may already cover, how to choose with a decision matrix, which details sink a project (customer references, units, revised orders), how to measure the real time per order before you start, and what a pilot and the full cost should include.
- Published
- Sources checked
- Reading time
- 16 min
- Written by
- Mirage Metrics team
Scope: B2B sales orders at manufacturers and distributors, received by EDI, portal, email, PDF, spreadsheet or scan, entered into any ERP. Phone orders and EDI mapping in detail are out of scope. The exception rules themselves have their own guide, linked below.
Decision snapshot
- Best suited to
- Order desk and customer service managers, operations directors, distributor owners, and ERP owners choosing how to take keying out of order intake.
- Inputs needed
- A month of orders counted by channel and customer, the customer and item masters with cross-references, price lists and contracts, units and pack sizes, and each customer's rules (split deliveries, substitutions, calendars).
- What can be automated
- Reading orders, recognising what is not an order, matching customers and items, converting units by defined rules, checking prices, dates and duplicates, and writing clean orders through the ERP's interface.
- What requires human approval
- Choosing between candidate items, accepting a price outside tolerance, new customers and delivery addresses, changes to orders already picked, cancellations, and the rules themselves.
- When this approach is insufficient
- When master data is unreliable, when most orders are negotiated case by case rather than placed against agreed terms, or when nobody can state the rules the order desk applies today.
The four approaches, and what each automates
The four approaches are often sold as rivals. They are not: each removes keying for a different kind of customer, and each leaves a different part of the job to someone. What matters is what the order looks like when it reaches you, and who has to change how they work for it to arrive differently.
| Approach | How it works | What it removes | Main constraint |
|---|---|---|---|
| EDI | The customer's system sends a structured order (ANSI X12 850, EDIFACT or EANCOM ORDERS) through a VAN, AS2 or a provider; a map turns it into your sales order. | Reading and keying, for that partner, completely | One onboarding project per partner, on both sides |
| Customer portal or B2B web shop | The customer keys the order into your site, choosing from your catalog at their own prices. | Your keying; the customer does it instead | Adoption: the customer has to want to log in |
| OCR or template capture | Text is read from the PDF or scan, and a template per layout says where each field sits. Newer document AI finds fields without fixed positions. | Reading the document, for the layouts you have set up | Matching, checks and ERP entry still need building, and a new layout breaks the template |
| Agent connected to the ERP | Software reads the order in whatever form it arrives, matches it against your master data, applies your rules and writes the order, holding what it cannot confirm. | Reading, matching, checking and writing, for every format | Depends on master data quality and on rules someone has written down |
Two distinctions save time when reading vendor pages. First, reading is not entering: a capture tool that extracts fields still needs matching against your masters, checks and a write into the ERP, and that second half is where most of the effort sits. Second, OCR and document AI differ in how they find fields, by position or by meaning, which is a question of how many layouts you can cover; the comparison of OCR and LLM extraction covers it. Neither answers which of your items a customer meant.
The word "agent" covers products built on rules, on robotic process automation that drives the ERP screens, and on language models. The test is not the label but what it does with a line it cannot confirm: holds it with a reason, or guesses. The differences between agents and screen automation are set out in AI agents vs RPA.
What your ERP may already cover
Before buying anything, check what the ERP vendor already ships. The table lists what each vendor documents, read on the date at the top of this page; editions and releases change, so confirm with your partner for your version.
| ERP | What the vendor documents | What to do |
|---|---|---|
| Dynamics 365 Business Central | Microsoft's Sales Order Agent monitors a mailbox, reads the email and PDF or image attachments, and always creates a sales quote first, which can be converted to an order; designated users approve every outgoing message. Customer item numbers live in item references. | Evaluate it first. Test it on your real orders, including your awkward formats, and note that it consumes Copilot Credits. |
| Dynamics 365 Supply Chain Management | Per-customer external item identifiers that can be searched on sales order lines, from version 10.0.45. | The cross-reference exists; reading the order is a separate tool. Interfaces and review gates: Dynamics 365 order entry automation. |
| SAP S/4HANA Cloud Public Edition | The Create Sales Orders from Unstructured Data scope item turns uploaded PDF or image purchase orders into a sales order request, a draft a user can simulate before creating the order. SAP's course states that only English and German files are supported. | Worth testing if your orders are in those languages and arrive as attachments. Check how it handles your customers' layouts. |
| SAP Business One | Customers' item numbers are kept as business partner catalog numbers. Orders can be created from outside through the Service Layer, the interface the Biodéal deployment writes through. | Ask your partner what your release offers for reading orders. Interfaces, drafts and catalog numbers in detail: SAP sales order automation. |
| Odoo | The eCommerce app supports B2B shops with customer accounts and a portal, per-customer pricelists and an Order Again button. Odoo documents AI digitization for vendor bills; turning a customer's PDF into a quotation is offered by third-party modules. | The portal route is native. Reading customer PDFs is an add-on: test it like any other tool. |
| Sage and other ERPs | Editions differ too much to summarise (Sage 100, 200, X3 and Intacct are different products). | Ask your partner three things: which order import format the ERP accepts, which EDI connector it supports, and whether an order can be created as a draft or on hold. |
Two things follow. Business Central, Supply Chain Management and Business One each document a place for customers' own item numbers, and most ERPs have one: if that table is empty in yours, filling it is the first project, whatever approach you pick. And where the vendor's own reading feature exists, its limits are stated plainly (quote first, two languages, attachments only); test them against your real mix before looking elsewhere.
Decision matrix: volume, customers, formats, change
Five factors decide most cases: how many customers order, how concentrated the volume is, how many formats arrive, how complex a line is, and how often orders change after they are sent. The matrix reads across each factor; the recommendation comes from the combination, per customer group.
| Factor | EDI | Portal or B2B shop | OCR or template capture | Agent connected to the ERP |
|---|---|---|---|---|
| Who has to change how they work | The customer and you: a map, tests, a connection | The customer, who keys the order | Nobody, once you have built a template per layout | Nobody |
| Customers it suits | Few, large, recurring, with an EDI provider or IT team | Repeat buyers ordering from a stable catalog | A handful of customers whose layout never changes | The long tail: many customers, many formats, mostly email |
| Formats handled | One agreed standard per partner | One: yours | One template per layout | Any layout, free text included, with doubtful lines held |
| Volume that justifies the setup | High, per partner | Medium, if customers adopt it | Medium to high, per layout | Low per customer, meaningful in total |
| Line complexity | Handled if the map covers it | Limited to what the portal offers | Stable tables; wrapped lines and notes break it | Customer references, missing units, notes, with flags |
| Changes and cancellations | Defined messages (X12 860, EDIFACT ORDCHG) | Customer edits until your cut-off | A revised PDF is a new document with no link | Must detect resends and revisions by rule |
| What usually breaks it | Partners who will not onboard; map upkeep | Customers who keep emailing anyway | A new layout or a moved column | Unreliable master data; rules nobody wrote down |
| Master data it needs | Cross-references or GTINs in the map | Your catalog and customer prices | Field positions plus cross-references | Cross-references, units, prices, addresses, customer rules |
Situations and the approach that usually fits
| Situation | Usually fits |
|---|---|
| Three customers send half your orders and already run EDI | EDI with those three. Decide the rest separately. |
| Over a hundred customers send PDFs and spreadsheets in their own formats | An agent connected to the ERP, or capture without templates plus your own matching and checks |
| Ten customers, the same layout for years, simple lines | Template capture, or the ERP's own spreadsheet import if they will send a fixed file |
| Customers reorder the same items every week | A portal or B2B shop with reorder, if they adopt it; keep a path for those who do not |
| Orders are revised several times before delivery | Write the versioning rules first: any approach fails without them |
| Your ERP vendor ships an agent that fits your formats | Test it first on a week of your real orders |
| Customer and item master data are unreliable | Clean them first. Automation will otherwise measure your data quality, not save time |
Fact and practice
The message names in the matrix are facts from the standards bodies. The rest of the matrix is recommended practice from order intake projects, not a measured benchmark: use it to frame the question, then test on your own orders.
Most order desks need a mix
Sort customers by order volume over the last three months and look at the curve. The typical shape is a few customers sending a large share of orders and a long tail sending the rest, but your own numbers decide. Then treat each group on its own terms:
- The head: customers large enough to have an EDI provider or an IT team. Ask for EDI; if they already send structured files, use them.
- The regulars: customers who reorder the same items. Offer the portal, measure adoption after a quarter, and keep a path for those who keep emailing.
- The tail: everyone else, in their own formats. Template capture if the layouts are few and stable; an agent connected to the ERP if they are many or change.
Whatever the mix, every channel should land in the same place: the same customer and item masters, the same checks, the same exception queue and the same count of orders received. Three tools each with their own rules recreate the errors you are trying to remove.
Customer item references and your SKUs
The most common reason an automated order stops is not reading: it is not knowing which of your items a customer meant. Customers order with their own item numbers, your numbers, barcodes, descriptions or a reference to a past order, often several on the same PO.
| What the customer writes | Example | Matched through | When it fails |
|---|---|---|---|
| Customer's own item number | "88-120-B" | Cross-reference table for that customer | No entry: hold the line, propose candidates, add the reference once confirmed |
| Your SKU, typed by the customer | "30412" | Exact match on your item number | Check it is still sold and the description agrees |
| Barcode | GTIN | GTIN on the item or unit of measure | A GTIN for a case and for a unit are different numbers: check which |
| Description only | "Hex bolt M12x40 zinc" | Search on description, then the customer's history | Several candidates: hold, never pick |
| Reference to a past order | "Same as last month" | The customer's previous orders | Hold: quantities and items must be confirmed |
Build the cross-reference from history before any pilot: for each customer, the last months of orders as they sent them, matched to what your team entered. That table is the single most useful asset of the project and it belongs in the ERP, not in the automation tool, so it survives a change of tool. After go-live, every line a person resolves should add a reference, so the same question is not asked twice.
Units, pack sizes, prices, discounts and dates
A line can be read perfectly and still be wrong in the ERP because a number meant something else. The rule throughout is that your masters decide what a value means, never the customer's document.
| Issue | Example | Rule |
|---|---|---|
| Unit missing | "66" with no unit | Infer only when the price on the order matches exactly one unit on your price list, and flag it |
| Customer's unit spelling | "CS", "carton", "x6", "PACK (X6P)" | Map each customer's spelling to a defined conversion, per customer |
| Not a pack multiple | 25 units of an item sold by 12 | Hold or round by a rule agreed with that customer, never silently |
| Price differs from your list | Customer's old price on the PO | Your price list or contract applies; outside a tolerance, a person decides |
| Discounts | Cascading or customer-specific discounts | Applied by the ERP's pricing, not copied from the PDF |
| Requested date | "03/04", "ASAP", "week 14" | Parse unambiguous formats; hold ambiguous ones; apply your shipping calendar |
Unit inference from price is the one shortcut worth knowing, because it is checkable. At Biodéal, when a form gives a quantity with no unit, the system compares the unit price on the document with SAP's rate for each possible unit; the case study's example is a litre of milk at €1.17, which can only be a carton and not a case of six at about €7. Lines inferred that way are entered and flagged for the team to confirm.
Duplicates, amendments and cancellations
EDI has messages for changes. The X12 standard pairs the 850 purchase order with an 860 change request from the buyer and an 865 answer from the seller. GS1's EANCOM ORDCHG lets a buyer change or cancel items, and states that the order number, the parties or a line number cannot be changed that way: those require cancelling and reordering.
Email has no such contract. A resent PDF, a revised PO and a polite "please cancel line 3" all arrive as new emails, and an automated process that treats each email as a new order will enter duplicates. Write the rules before the pilot:
| Event | How it shows up | Rule | Mistake to avoid |
|---|---|---|---|
| Resent PDF | Same PO number, same lines, a later email | Link to the first order; enter nothing | Entering it twice because the email is new |
| Revised PO | Same PO number, a revision mark or changed lines | Compare with the order in the ERP; apply the difference as a change, held if the order is already picked | Creating a second order, or overwriting a shipped line |
| Cancelled line | A line missing from the revision, or "cancel line 3" in the email | Hold for a person if anything has been allocated or shipped; otherwise apply and log | Treating a missing line as an extraction error |
| Whole order cancelled | An email or a PO marked cancelled | Always a person: the order may be picked, invoiced or partly shipped | Cancelling automatically |
| New PO number for the same goods | Different number, same lines and dates | Flag as a possible duplicate and ask; do not merge by guess | Entering both without a question |
The key is customer plus PO number, checked against orders already received, with the lines compared when the number matches. The Biodéal case study describes the same requirement in its own terms: the agent follows an order across several emails as it is created, merged or replaced.
Ambiguous lines and human review
Every approach produces lines a person must decide: an item with two candidates, a quantity ten times the usual, a price outside tolerance, an address not on file. Three decisions shape the review, and they belong to you, not to the tool:
- Where the gate sits: orders written as drafts, quotes or on hold until released, or written directly with only the held lines waiting. Business Central's agent always starts with a quote; starting with drafts and loosening customer by customer is the cautious path.
- Line or order: whether clean lines go in while one is held. Never split when the doubt is about the customer, the address or a duplicate, which affect every line.
- What the reviewer sees: the source document at the right place, the value read, the candidates from your masters, and the rule that raised the hold.
The full exception taxonomy, the review screen, confidence thresholds and the audit log are set out in the guide to sales order exception handling before ERP entry, and where entry errors come from in the first place in the five root causes of ERP order entry errors.
Measure the full time per order first
Most business cases count keying time only. The time an order really costs also includes the follow-ups to clarify it and the corrections when it went in wrong, and those are exactly what changes, for better or worse, when the intake changes. Measure them per channel before choosing anything:
| Component | What it covers | How to get it |
|---|---|---|
| Receipt to start | Time the order waits in the inbox before anyone opens it | Delay, not effort: report it apart |
| Keying | Opening the document, finding the customer, keying lines, looking up items and prices | The only part most estimates count |
| Follow-ups | Emails and calls to the customer to clarify an item, unit, date or price | Count them per order and time a sample |
| Corrections after entry | Amendments, credit notes, re-deliveries traced to an entry error | From the ERP's change log and credit notes |
| Acknowledgment | Preparing and sending the order confirmation | Often automatic already: check |
- Count a full month of orders by channel and by customer, from the ERP and the inbox
- Time a sample of orders per channel over two weeks, start to finish, including lookups
- Count follow-ups per order from the sent folder and time a sample
- Count corrections from the ERP change log and credit notes traced to entry
- Write the baseline per channel in minutes per order, with the sample size beside it
To turn the baseline into hours and cost, the order entry error cost calculator takes volume, minutes per order, error rate and cost per error, and the automation ROI calculator turns the hours a project frees into a payback. Background on what manual entry costs is in the true cost of manual order entry.
Worked example: a mixed order intake
Illustrative example, invented figures: an industrial distributor with EDI, PDF, spreadsheet and plain email orders
Assumptions, all invented. 100 customers send 2,500 orders a month. The team timed a sample per channel; follow-ups take 8 minutes each and a correction after entry 30 minutes. The follow-up and correction columns give the number of events a month times the minutes each.
| Channel | Customers | Orders a month | Keying min per order | Follow-ups | Corrections | Total min | Hours |
|---|---|---|---|---|---|---|---|
| EDI | 5 | 1,000 | 1 | 25 x 8 | 4 x 30 | 1,320 | 22 |
| Email PDF | 60 | 1,000 | 6 | 120 x 8 | 30 x 30 | 7,860 | 131 |
| Spreadsheet | 10 | 300 | 10 | 30 x 8 | 12 x 30 | 3,600 | 60 |
| Email body text | 25 | 200 | 4.5 | 30 x 8 | 10 x 30 | 1,440 | 24 |
| Total | 100 | 2,500 | 14,220 | 237 |
Keying alone is 10,900 minutes, about 182 hours. The full baseline is 14,220 minutes, 237 hours: follow-ups and corrections add 3,320 minutes, about 23 percent of the total, that a keying-only estimate leaves out. Per order, 5.7 minutes in full against 4.4 for keying. Spreadsheets are only 12 percent of orders but a quarter of the hours, because each one carries many lines.
Three options are costed below. Follow-ups and corrections are held at their baseline in all three: whether they fall is what the pilot measures, not something to assume.
| Option | Monthly effect | Monthly upkeep | Net saving a month | One-off effort |
|---|---|---|---|---|
| A. Template capture for 8 stable PDF layouts | 450 orders: 6 min keying becomes a 2 min check, 1,800 min saved | 2 layout changes a month x 3 h = 6 h | 24 h | Template setup |
| B. Agent connected to the ERP for all non-EDI orders | 1,500 orders, 9,900 min of keying removed; review: 225 held orders x 6 min + 75 spot checks x 2 min = 1,500 min | Rules and cross-references: 8 h | 132 h | Master data cleanup, 80 h |
| C. EDI onboarding of the largest PDF customer | 180 orders: 6 min becomes 1 min, 900 min saved | Map upkeep with the provider | 15 h | Onboarding, 40 h internal, plus provider fees |
Option B takes the monthly total from 237 to 105 hours (14,220 minutes, less 9,900 of keying, plus 1,500 of review and 480 of upkeep: 6,300 minutes). Its 80 hours of cleanup are about three weeks of its net saving. Option C is small on its own but cheap in internal time, recovered in under three months, and it combines with B: the largest customer moves to EDI, the agent handles the other 1,320 non-EDI orders. Option A stays limited because it covers only the eight layouts that never change: the other 52 PDF customers, the spreadsheets and the plain emails are still keyed by hand.
Decision for this distributor: pilot B on twenty customers that include the spreadsheet senders, ask the largest PDF customer about EDI in parallel, and keep the five EDI customers as they are.
Total cost: what goes in the budget
Licence prices are the visible part. The full cost has six lines, and the ones that decide the outcome are usually master data, review time and maintenance, which no quote includes.
| Cost line | EDI | Portal | Template capture | Agent connected to the ERP |
|---|---|---|---|---|
| Licences and fees | Provider subscription, VAN or per-document charges | Module or platform licence | Capture licence, often per page or document | Subscription, often by volume |
| Integration | One map per partner and message type | Catalog, prices and order write-back | Writing captured data into the ERP | Reading master data and writing orders |
| Customer onboarding | Per partner, on both sides | Training and chasing adoption | None | None |
| Master data cleanup | Cross-references for each partner | Catalog and prices fit to show customers | Cross-references for each customer | Cross-references, units, addresses, customer rules |
| Review time | EDI error queue | Checking orders customers keyed | Checking every captured field | Held lines and spot checks |
| Maintenance | Map changes when a partner changes | Catalog and portal upkeep | A template per changed layout | Rules and cross-references as customers change |
Two lines deserve a number of their own in any proposal. Review time: the share of orders held, times the minutes to resolve one, measured in the pilot rather than promised. Format change: what happens, and who pays, when a customer changes ERP and its PDF layout changes overnight. For EDI that is a map change with the partner; for templates, a new template; for an agent, nothing if it reads without templates, but its cross-references still need upkeep.
Pilot criteria
A pilot answers one question: on our own orders, with our own masters, does this approach remove more time than it adds, without losing or corrupting an order? Define the measures before it starts, and publish the definitions with the results.
| Item | What to set |
|---|---|
| Scope | Customers chosen to include the awkward formats, not only the clean ones; a fixed period of at least two full weeks |
| Mode | Parallel: the team enters orders as usual, the system processes the same orders without writing, or writes drafts nobody releases |
| Orders with no human action | Count orders, not lines; exclude items classified as not an order |
| Errors after validation | Lines that differ from the correct order, split between lines the system entered alone and lines a person validated |
| Time per order | Full time including review, follow-ups and corrections, compared with the baseline on the same customers |
| Nothing lost | Every inbound email and attachment reaches a status; the daily count balances |
| Exit rule | Written before the pilot: the thresholds that move a customer to live entry, and what stops the project |
The general method for running a document automation pilot, from sample selection to the go or stop decision, is in the document automation pilot guide. For order intake specifically, include at least one customer who revises orders often: that is where duplicates and silent overwrites show up.
What one deployment documents: Biodéal
Mirage built the email-to-ERP order pipeline at Biodéal, an organic dairy distributor supplying retail chains, bakeries and wholesalers, with orders created in SAP Business One. It is one deployment, on the tail of the matrix above: customers who order by email in their own formats. Its case study documents the difficulties this guide describes:
- Formats: PDFs generated by customers' own ERPs, Word or ODT tables, scanned order forms and plain text, each with its own quantity conventions ("12 / 5 Kg", "PACK (X6P)", columns with no unit).
- Units inferred from price, with the inferred lines flagged; the case study says this turned a 12-line order that used to be rejected outright into one entered automatically.
- Rejecting what is not an order: delivery confirmations, stock-out notices, and Biodéal's own orders to its suppliers.
- Alerts instead of failures: a line whose quantity cannot be extracted never fails the whole order and never disappears; it goes out as an alert with a diagnosis.
- Tagging: every processed email is tagged in Outlook, so the team sees what has been handled.
Its published figures, which describe that deployment only and are not a rate to expect elsewhere: 2,943 orders processed automatically since launch on July 22, 2025, 12,993 order lines entered automatically, a median of 48 seconds from email received to order ready, 113 distinct customers, about 7 percent of orders flagged for a human check, and zero lines lost silently, by design. Mirage's offer for this kind of intake is described on the sales order automation page, and for customers too small to put on EDI on the EDI alternative page.
Questions readers ask
Usually not. EDI, portals, capture tools and agents all write into the ERP you have, through its API, an import format or an EDI connection. An order management system solves a different problem: routing orders across many sales channels and warehouses. If orders arrive by email and PDF, the work to remove is reading and keying, and that sits in front of the ERP.
OCR turns the page into text; it does not decide which of your items a customer's reference means, which unit applies or whether the price is right. Template capture works for a few stable layouts. For many customers in many layouts you also need matching against your master data, checks and a way to write the order, whether you build that around the capture tool or buy it with an agent.
For your largest recurring customers, yes if they are willing: a structured order is the most reliable input there is. For the long tail, asking is free but adoption is the customer's decision, and the ones who decline keep sending email. Plan for both from the start.
For clean orders from known customers, entry can run without a person; held lines, new customers, new delivery addresses, price disputes and cancellations of picked orders still need one. Microsoft's own agent for Business Central has designated users approve every outgoing message. Decide where your review gate sits before you choose a tool.
Sources and scope
Checked on . Scope: vendor and standards facts are cited at the claim; the decision matrix, cost lines and pilot criteria are recommended practice; the worked example is invented; Biodéal facts are quoted from its case study and describe that deployment only.
- Microsoft Learn, Sales Order Agent overview (Business Central): mailbox monitoring, PDF and image attachments, quote first, approval of outgoing messages, item matching order, Copilot Credits
- Microsoft Learn, Use item references (Business Central): customer item numbers mapped to your items
- Microsoft Learn, Use external item identifiers to add products to orders (Supply Chain Management): per-customer external item identifiers on sales orders, version 10.0.45
- SAP Learning, Creating Sales Orders from Unstructured Data (4X9): PDF and image purchase orders into sales order requests, simulation before creation, English and German only
- SAP Help, Managing Business Partner Catalog Numbers (SAP Business One): customers' item numbers kept against your item codes
- Odoo 18 documentation, eCommerce customer accounts: B2B shop access, customer portal, Order Again
- Odoo 19 documentation, Vendor bills: AI digitization documented for vendor bills, with IAP credits
- Odoo Apps, a third-party sale order digitization module: customer PDF to quotation offered by third parties, not by Odoo itself
- ASC X12, Supply chain transaction flow: 850 purchase order, 855 acknowledgment, 860 buyer change request, 865 seller change acknowledgment
- GS1, EANCOM 2002 S4 ORDCHG, purchase order change request: line changes and cancellations by message; a PO number or party change needs cancelling and reordering
- Mirage Metrics, Biodéal case study: every Biodéal fact and figure on this page
Related on this site
- Sales order exception handling before ERP entry: the exception types, review screen and audit log
- Automate email orders to ERP: the email channel on its own
- EDI alternative for small and mid-size customers: the long tail EDI does not reach
- SAP sales order automation: Business One, S/4HANA and ECC interfaces
- Dynamics 365 order entry automation: Supply Chain Management and Business Central
- OCR vs LLM for document extraction: how many layouts each can read
- Order entry error cost calculator: your baseline in hours and cost
- AI order processing software compared: vendors in the agent category
See which of your orders an agent could enter
Send us a week of real orders from your email channel, PDFs, spreadsheets and plain text included. We return each one as it would be written to your ERP, with the lines we would hold and the reason for each, so you can compare it with your baseline.
Prefer to talk it through? Book a call