# Mis-pick recovery records: a system map | SourceX

Canonical: https://refer.sourcex.si/guides/mis-pick-recovery-records-across-systems
Last updated: 2026-10-19

Reconstructing one mis-pick recovery takes four keys that must match across systems: the order number, the SKU with its component-list version, a replacement reference that points back to the original order, and timestamps on a shared clock. The warehouse system holds the pick and ship events, the component list says what the box should contain, the ticketing tool holds the complaint and approval, and the order platform holds the replacement. Where any key is missing, the case breaks.

This system map is part of the [mis-pick recovery guide](/guides/workflow-mis-pick-recovery), which covers what to inventory before a fulfillment contract renewal. The [exception case](/guides/mis-pick-recovery-exception-examples) follows one wrong component decision by decision. This page answers a narrower question for 3PL account advisors: which system holds which piece, and what holds the pieces together.

## Four systems, one wrong-component recovery: the map

A retailer that outsources warehousing usually spreads one recovery across four places, often run by two companies. The table is the map: one row per system, the record it keeps, the identifier it can share with the others, and who administers it.

| System | Record it holds | Linking key it shares | Usual owner |
|---|---|---|---|
| Warehouse management system | Pick, pack and ship events with user and time; carton and tracking number | Order number, SKU, event timestamp | The 3PL; the retailer sees it through a portal |
| Component master | What each multi-item set contains, with effective dates and change history | SKU plus set version | Whoever assembles the sets: the 3PL or the retailer's merchandising team |
| Ticketing tool | Complaint, customer photo, reason tag, agent notes, replacement approval, escalation thread | Order number in a ticket field or the message body; customer email | Retailer customer operations |
| Order management or ecommerce platform | Original order, replacement order, refund or credit | Order number; replacement flag or note naming the original | Retailer ecommerce or finance |

The component master is the row most often forgotten, and it decides whether the pick was right. An event that confirms the outer SKU says nothing about the card or accessory packed inside it. Where set compositions carry a version number and an effective date, a reviewer can tell what the box should have held on the day it left the building. Where they were edited in place, that answer is gone for older orders.

## The identifiers that carry a case from pick to fix

Each join holds only if both systems recorded the same value at the time. The reliability column is where most histories thin out.

| Key | Where it starts | Where it must reappear | Join quality | Question to ask |
|---|---|---|---|---|
| Order number | Order platform | Warehouse pick record; ticket field | Good on the warehouse side, fair in tickets | Is order number a required ticket field, or typed only when the customer gives it? |
| SKU and set version | Component master | Pick line; complaint reason or photo | Fair | Does the pick line store the version, or only the SKU? |
| Replacement reference | Ticket approval | Replacement order | Weak | Is a replacement flagged and linked, or booked as an ordinary order? |
| Timestamps | Every system | Each other | Good if clocks agree | Do both tools record a time zone? |
| Root-cause reference | Escalation note | Component change history | Weak | Was the set correction logged with a reason that cites the complaints? |

On the ticketing side, a ticket's own history matters as much as its fields. Zendesk, for example, stores an audit each time a ticket is updated, with the author, the timestamp and an event for each change, so a ticket can show when an agent added the order number or changed the reason tag. Its developer documentation also notes that the account-wide audit list leaves out archived tickets, which are read one ticket at a time, and its export article says CSV exports drop ticket comments. Those are details the company's administrator confirms; a partner only notes that the question exists.

## One case joined end to end (Illustrative)

A fictional 230-person home fragrance retailer ships gift sets through an outside 3PL. Every identifier below is invented to show the shape of a fully joined case.

| Step | System | Record | Key carried forward |
|---|---|---|---|
| 1 | Component master | Gift set GS-12, version 3 effective March 4: candle, diffuser, card C | SKU GS-12, version 3 |
| 2 | Warehouse system | Order 40917 picked March 9; outer SKU GS-12 confirmed; shipped with tracking number | Order 40917, SKU GS-12 |
| 3 | Ticketing tool | Ticket opened March 13: customer photo shows card B, from version 2 | Order 40917 typed by agent |
| 4 | Ticketing tool | Replacement approved by team lead within agent limit; reason tag "wrong component" | Order 40917, approver |
| 5 | Order platform | Replacement order 41388 flagged as replacing 40917 | Order 40917 in the replacement note |
| 6 | Ticketing tool | Escalation thread with the 3PL account team: old card stock left in the assembly bin | Ticket number, 3PL reply |
| 7 | Component master | Bin cleared; version 3 confirmed; change note cites the escalation | SKU GS-12, version 3 |

Order 40917 runs through steps 2 to 5, so the recovery rebuilds. Step 3 is the fragile one: the order number exists in the ticket only because an agent typed it. Step 7 closes the loop only because someone wrote a reason on the set record. Remove either and the case becomes a complaint with no cause and a correction with no trigger.

## Where the chain snaps: replacements booked as new sales

Most retailers have clean warehouse identifiers and weaker joins everywhere else. Naming the breaks lets the company describe its history honestly instead of overstating it.

- **Replacement orders without a link.** When a replacement is entered as a normal order, it looks like a second sale. The recovery disappears from the order data and survives only in the ticket.
- **Tickets opened by email.** A customer who writes "my gift set was wrong" without an order number leaves a ticket that can only be matched by email address and date.
- **Set versions kept in a spreadsheet.** If compositions changed in a shared file with no dates, the step 1 row cannot be rebuilt for older orders.
- **Corrections agreed by phone.** A root cause settled on a call with the 3PL leaves no record on either side.
- **Pick history behind a portal.** The retailer may see warehouse data only while the contract runs; the [3PL data ownership explainer](/questions/3pl-data-ownership) covers who holds what, and the [3PL acquisition and WMS integration guide](/guides/3pl-acquisition-integration-wms) covers records that move when the provider itself changes systems.

The same test applies to approval limits elsewhere; the [procurement approvals and exceptions guide](/guides/how-to-assess-procurement-approvals-and-exception-workflows) uses it for purchase exceptions, and [cycle count variance investigation](/data-types/cycle-count-variance-investigation) shows a related warehouse record family.

## Questions for the customer operations head

These can usually be answered from a report or from memory, without opening a single ticket:

1. Which ticketing tool, order platform and 3PL portal hold recovery records, and since which year?
2. Roughly what share of complaint tickets carry an order number?
3. Are replacement orders flagged and linked to the original?
4. Where are set compositions kept, and do they carry effective dates?
5. Roughly how many recoveries a year, by reason tag?
6. Who administers the ticketing tool, and who at the 3PL controls warehouse reporting?

The answers feed the [referral brief template](/resources/mis-pick-recovery-referral-brief-template). The introduced company needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license the records 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 handle tickets, photos or exports. Whether the joined records can be licensed once customer personal data and the 3PL contract are reviewed, and whether a buyer wants them, stays unknown until SourceX reviews the opportunity with the company's authorized contact.

## 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 the customer operations head confirms that order numbers reach the tickets and replacements link back to the original order, [register as a partner](/register), check the retailer on [who qualifies](/who-qualifies) and read the [program terms](/terms) before making the introduction.

## Sources

- https://developer.zendesk.com/api-reference/ticketing/tickets/ticket_audits/
- https://support.zendesk.com/hc/en-us/articles/4408886165402-Exporting-ticket-user-or-organization-data-from-your-account
- https://refer.sourcex.si/terms