A pilot measured on your real customer orders

Preventing duplicate entry requires agreed checks around customer identity, order references, repeated messages and delivery into the ERP. Similar-looking orders are not always duplicates: a customer may intentionally reorder the same items. Ask which duplicate controls are available in the proposed implementation and test both repeated submissions and genuine repeat purchases. Do not assume that AI extraction alone provides duplicate protection.

A change must be associated with the correct original order and handled according to its current status. A request received before ERP delivery differs from a change received after picking has started. Define the modification workflow with your team and implementation partner. Do not assume that follow-up messages automatically update a confirmed ERP order; verify the supported behavior during the pilot.

A useful workflow distinguishes processing status from approval status. An order can be interpreted successfully yet wait for commercial approval, or be incomplete and need clarification. It can also be ready for delivery to the ERP or already delivered. Confirm which statuses and notifications your implementation provides and who handles each exception. These responsibilities should be tested before live use.

Combining requests across channels requires identifying the customer and determining whether messages belong to one order or to separate orders. The same customer may use WhatsApp for a request and email for a document, but that does not make every message part of the same transaction. Include these cases in the pilot and confirm the supported workflow; automatic cross-channel merging should not be assumed.

Start with representative customer orders and enough reference data to identify customers and products. This may include your customer list, catalogue, units of measure and relevant historical documents. Agree the minimum dataset for your pilot and share only what is needed. A useful test includes both routine orders and difficult cases, rather than only examples that are easy to interpret.

No. Approval depends on your company's policy. A customer may require approval for every order, for selected orders, or allow clear and validated orders to continue automatically under agreed rules. Incomplete or uncertain orders still need exception handling. Commercial approval and resolving an interpretation problem are different tasks, so define both during onboarding.

Define the metric before testing. Correctly identifying a customer, matching each product and quantity, and completing an entire order are different measures. Evaluate both the interpretation result and the data delivered through your ERP workflow. Report exceptions and required corrections as well as successful cases. A headline accuracy percentage is meaningful only when its definition, sample and review policy are clear.

Yes. An initial evaluation can focus on interpreting your actual customer orders and inspecting the structured results before a live ERP connection is introduced. Use the current pilot offer and agree the sample, reference data, output format and success criteria. Include difficult orders and corrections, then validate the integration and approval rules before moving to a production workflow.

Confirm which data is needed, where it is processed, who can access it, how long it is retained and which third parties are involved. Ask for the applicable privacy and contractual information, including responsibilities for customer and employee data. Share the minimum relevant information for the test. Do not infer certifications, hosting locations or model-training policies from the use of AI.