AI System for Classifying Return Shipments for Acceptance Review

The problem

The reason for a return and the item's physical condition may be conflated in day-to-day operations. When return request, product identity, delivery record, reason, photograph and packaging-condition data are scattered across sensor, document, site or team records, the issue may not be identified in time.

This fragmented data delays preparation of the return review file and forces teams to search for supporting evidence again by hand. Before making a decision, the returns operations specialist must complete missing records and verify each inconsistency individually.

A common exception is that transport damage may be visually indistinguishable from customer-caused damage. Incomplete or incorrect automation that does not check this context could create an incorrect acceptance, rejection or liability record, so no physical or operational action can be taken directly.

What we set out to improve

• Proportion of review categories changed by the returns specialist
• Proportion of outputs corrected or rejected by the returns operations specialist
• Time between the source event and the review output

How the system works

1. 01 Define the review scope and the role of the authorised returns operations specialist
2. 02 Retrieve the inputs: return request, product identity, delivery record, reason, photograph and packaging condition
3. 03 Check the source identifier, date, calibration or version, and data recency
4. 04 Match the request with the product identity
5. 05 Group the image, delivery and reason information
6. 06 Check the exception: transport damage may be visually indistinguishable from customer-caused damage
7. 07 Place low-confidence or inconsistent records in a separate specialist queue
8. 08 Write the source identifier, rule, output and time to the audit trail
9. 09 Have the returns operations specialist approve, correct, defer or reject the output

Methods we used

• Administrative return classification and evidence checks
• Source, format, time and required-field checks for return request, product identity, delivery record, reason, photograph and packaging-condition data
• A missing-data warning instead of an estimate when inputs are incomplete or inconsistent
• A separate exception check outside the main rule
• Joint retention of the source, rule result, return review file and human decision

Where people stay involved

Data and security

Return request, product identity, delivery record, reason, photograph and packaging-condition data are accessed with the narrowest permissions required for the task. Commercial, location and employee information is masked where possible, and only the necessary portion of the data is sent to the model rather than the complete raw dataset. Access, outputs and the returns operations specialist's decision are recorded; production does not begin until the organisation approves the retention period and data location.

Who this suits

Frequently asked questions