# Mis-pick recovery: a worked hard case | SourceX

Canonical: https://refer.sourcex.si/guides/mis-pick-recovery-exception-examples
Last updated: 2026-10-19

The mis-pick recovery records that explain an exception are the ones that connect a customer-visible problem to an authorized remedy and a checked fix: the pick and pack scans, the complaint ticket with its photo, the agent's reason tag, the replacement-order approval, the corrected component list and a later review showing the problem stopped. The Illustrative case below follows one wrong-insert recovery in order, with the decision and record at each step.

This worked case is part of the [mis-pick recovery guide](/guides/workflow-mis-pick-recovery). It is written for 3PL account advisors who want to recognize a well-documented recovery before suggesting an introduction.

## What went wrong: a correct scan, a wrong box

A fictional 260-person direct-to-consumer brand sells a starter bundle through an outside 3PL. The set has two versions that differ only in a printed card. The picker scans the right item barcode; the warehouse system records a correct pick. The card, which nobody scans, belongs to the other version.

Product identification rules explain how a passing scan can still be wrong. Under the GS1 standard for managing trade item numbers, changing what goes inside a set calls for a new number. If the two versions share one number, or the card is not listed as a component at all, the scanner has nothing to distinguish them. Whether that happened here is for the company to establish, not the advisor.

## The recovery, decision by decision (Illustrative)

| Day | Decision or event | Who decided | Record | System |
|---|---|---|---|---|
| 0 | Order picked and packed; scans pass | Picker, under standard process | Pick and pack scan events | 3PL's WMS |
| 4 | Customer reports wrong insert, with a photo | Customer | Complaint ticket and attachment | Brand's helpdesk |
| 4 | Agent tags the ticket as a mis-pick and links eleven similar tickets | Support agent | Reason tag, linked tickets | Helpdesk |
| 5 | Replacement order approved within the agent's limit; batch escalated to operations | Agent, then team lead | Approval note, escalation comment | Helpdesk |
| 9 | Component list corrected so each version names its own card; 3PL confirms by email | Brand operations manager and 3PL account lead | Updated component list, confirmation email | WMS and email |
| 30 | Ticket count for that bundle reviewed; back to its usual level | Customer operations head | Saved report and review note | Helpdesk |

## Why each record matters as evidence

**Day 0, the contradiction.** A system of record that says "correct" next to a ticket that says "wrong" is the heart of the case. An AI agent trained on such histories has to learn which source to trust and why. Keep the scan record even though it shows no error.

**Day 4, the pattern.** One complaint is noise; twelve linked tickets with the same tag are a signal. The linking decision is a human judgment the record preserves.

**Day 5, the authority.** The replacement order sat within the agent's limit, while the batch-level problem went to a team lead. The approval notes show who was allowed to decide what.

**Day 9, the root cause.** The component-list correction is the fix that stops it happening again. It lives on the 3PL's side, which is why a brand's records alone rarely tell the whole story.

**Day 30, the checked result.** Without it, the case has a problem and an action but no proof the action worked.

## The record most often lost: ticket comments

Most of the reasoning above sits in free-text comments, not structured fields: the agent's description of the wrong card, the approval wording, the pointer to the warehouse email. Whether those survive depends on how the history was saved. Zendesk, for example, states that account exports must be switched on by request and that its spreadsheet-style export omits comments. A history saved that way keeps the reason tag and loses the explanation. The advisor does not need to know the format; asking whether comments are kept is enough.

## The same case, thinly documented

Compare the sequence above with what many companies actually retain. Each missing step removes one link in the reasoning, and the case collapses into a cost line.

| Step | Well documented | Thinly documented | What is lost |
|---|---|---|---|
| Contradiction | Passing scan event kept beside the complaint | Only the shipped status survives | Proof that the system of record disagreed with the customer |
| Pattern | Twelve linked tickets under one reason tag | Tickets closed one by one as "resolved" | The judgment that this was systemic |
| Authority | Approval note naming the agent's limit and the escalation | Refund line in the finance ledger | Who was allowed to decide, and on what grounds |
| Root cause | Component list change confirmed by the warehouse | A phone call nobody wrote down | The fix that stopped repeats |
| Checked result | Saved report and review note on day 30 | Nothing | Evidence that the remedy worked |

The thin version is not worthless, but it records outcomes without decisions. For training and evaluation, the decisions are the useful part: an agent learns from why a person chose an action, not only from the fact that money moved.

## How to recognize similar cases at a client

Ask the customer operations head, and write down only the answers:

- Do complaint tickets carry a structured reason such as "mis-pick" or "wrong item", and an order number?
- Are similar tickets linked, or counted in a saved report?
- Do replacement and refund approvals record who approved and within what limit?
- When a root cause was found at the 3PL, is the fix recorded, and where?
- Are ticket comments and attachments kept, and for how many years?
- Roughly how many mis-pick tickets a year, and for how long?

A brand that can say yes to most of these holds cases like this one. The [system map](/guides/mis-pick-recovery-records-across-systems) shows the keys that join WMS and helpdesk records, and [3PL data ownership](/questions/3pl-data-ownership) explains which side owns what. Similar evidence chains appear in [cycle count variance investigations](/data-types/cycle-count-variance-investigation), in the guide to [identifying logistics exceptions and their documented resolutions](/guides/how-to-identify-logistics-exceptions-and-their-documented-resolutions), and in [accounts payable exception handling](/data-types/accounts-payable-exception-handling-process).

## Qualification and what stays unknown

An introduced company needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. Partners sign the Channel Partner Agreement before submitting introductions and never take tickets, photos, order lists or logins.

Until SourceX reviews it, nobody knows which side's records the company has rights to, how customer details in tickets are de-identified, whether buyers want recovery histories or whether an offer follows. The [decision tree on who can license these records](/questions/who-can-license-mis-pick-recovery-records) identifies the signer, and the [referral brief template](/resources/mis-pick-recovery-referral-brief-template) captures the metadata.

## Next step

> **Refer a company. Earn up to $100,000.** Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.

If a brand can follow its recoveries from scan to complaint to component fix to checked result, [register as a partner](/register), check the company against [who qualifies](/who-qualifies) and read the [program terms](/terms) before you approach the customer operations head.

## Sources

- https://ref.gs1.org/standards/gtin-management/
- https://support.zendesk.com/hc/en-us/articles/4408886165402-Exporting-ticket-user-or-organization-data-from-your-account
- https://refer.sourcex.si/terms