A sales operations manager reviewing the Sales Order Agent's activity notices that purchase orders emailed by a long-standing wholesale customer are being converted with the wrong unit of measure roughly one in five times, even though the product SKUs match correctly. Investigation shows the customer's PO documents list quantities in 'cases' while the Dynamics 365 product records default to 'each' as the base unit. What should the consultant do to reduce this error rate?

The correct answer is adding a unit-of-measure mapping so the agent recognizes this customer's 'cases' terminology and converts it to the correct schedule quantity before creating the order. The root cause is a unit-of-measure mismatch between how this customer phrases quantities and how the product catalog is structured, not a general reliability problem with the agent. Adding a mapping that teaches the agent to translate this customer's 'cases' language into the correct unit-of-measure schedule quantity directly fixes the misinterpretation at its source. Disabling automatic order conversion for this customer entirely and requiring manual entry going forward is incorrect because it removes the efficiency benefit entirely to work around a fixable data-mapping gap, which is a disproportionate response. Asking the customer to change their purchase order template to always specify 'each' instead of 'cases' is incorrect because it shifts the burden onto a long-standing customer to change their own documentation practices rather than adapting the system to handle a legitimate and common real-world quantity format. Increasing the confidence threshold required before the agent will auto-convert any purchase order from any customer is incorrect because raising the confidence threshold across all customers would suppress correct conversions for other customers whose documents do not have this specific ambiguity, without addressing the actual mismatch causing this customer's errors.