Mispick Verification: From “Wrong Item” to “What Actually Happened”

TL;DR

When a customer says “you shipped the wrong item,” the easy assumption is that the warehouse mispicked. But that assumption is wrong more often than people think — and acting on it means replacements, refunds, and escalations that never had to happen. So I built an evidence-first investigation workflow that compares what was ordered against what was actually received, spec by spec, and classifies the case into one of six root causes. The rep stays in the loop: AI helps draft the customer response and the internal notes, but the human confirms the specs, owns the classification, and decides the resolution.

How this started

It started as product search. I built a Gemini Gem for real-time, verified catalog product searches during calls — enforcing catalog item-number validation, cross-referencing manufacturer part numbers, redirecting to the manufacturer when needed, and returning a scannable, call-ready format. That work made me faster at finding the right part.

But the harder problem wasn't finding parts — it was the call that starts with “you sent me the wrong thing.” Those calls are slow, ambiguous, and expensive. They often end in a replacement or refund because nobody has the time to figure out what actually happened. So the work evolved: from product search into investigation — did the warehouse actually ship the wrong item, or did something else happen?

The problem

The default response to a mispick claim is assumption-first: assume the warehouse got it wrong, ship a replacement, move on. That's fast in the moment and expensive in aggregate — and it hides the real root cause. A “wrong item” can be any of six completely different situations, and each one needs a different response:

• True warehouse mispick — a different SKU was physically picked and shipped. Genuine error; the received item is not the item that was ordered.
• Manufacturer packaging change — same item, new box. The part is correct; only the packaging or branding changed.
• Vendor / manufacturer substitution — the part number was superseded. The old number maps to a new one; the item is functionally equivalent.
• Customer ordered the wrong item — what arrived matches the order; the customer expected something different. The error is upstream of the warehouse.
• Catalog listing error — the listing itself is wrong (wrong spec, wrong material, wrong image). The warehouse shipped exactly what the listing said; the listing is the defect.
• Product variation confusion — the customer ordered one variation of a family (a thread size, a voltage) and received a different variation. A close-but-wrong part.

Each of these has a different resolution. Treating them all as “mispick” means shipping replacements for items that were never wrong, refunding for packaging changes, and never surfacing the listing errors that will generate the next ten identical calls.

The investigation process

The workflow is evidence-first, not assumption-first. Four steps, in order:

1. Understand what was ordered. Pull the Sales Order — the catalog item number, manufacturer part number, description, listing images, and every listed attribute. This is the source of truth for what should have arrived.
2. Determine what was received. Read the box print, the manufacturer number on the item, the UPC, and the physical specs — dimensions, voltage, material, color, finish, capacity. This is the source of truth for what actually arrived.
3. Compare every specification. Dimensions, manufacturer number, revision, packaging, branding, generation, distributor labeling — field by field, ordered vs. received. Any mismatch is evidence.
4. Classify into one of the six categories. Use the decision tree. The classification determines the response.

Before / after

All names, part numbers, and order numbers in the examples are illustrative.

How the human stays in the loop

1. The rep gathers the evidence — order record, box label, physical specs. No evidence, no classification.
2. The AI drafts the spec comparison, a customer-ready explanation, and standardized internal notes — never a final.
3. The rep verifies the specs against the actual item and the listing. The AI can be wrong about a spec; the human confirms it.
4. The rep owns the classification and decides the resolution — replacement, keep-it, redirect to the manufacturer, or escalate the listing.
5. The rep posts the notes and sends the response.

The AI does the time-consuming, repetitive parts — compare specs, draft the email, format the notes — so the human stays focused on the part that takes judgment: confirming the evidence, naming the root cause, and deciding the right resolution. That's the whole point.

The playbook

The investigation is captured as a repeatable playbook with five components, so the workflow doesn't live only in my head:

• Evidence checklist — the exact fields to capture for “what was ordered” and “what was received,” so nothing gets skipped under pressure.
• Decision tree — a priority-ordered set of questions that turns the evidence into one of the six classifications.
• Confidence rating — high / medium / low, based on how much evidence supports the classification. Low confidence means escalate, don't guess.
• Customer-ready explanation — a plain-language response that explains what happened and what happens next, in the customer's terms.
• Standardized internal notes — consistent, scannable order-management notes that the next person can read in five seconds.

Metrics to track

Outcomes are not yet formally measured — these are the metrics I'd track to validate the workflow.

• First-contact resolution (primary) — cases resolved on the first touch because the root cause was identified in the investigation, not after a needless replacement.
• Avoided replacements & refunds — dollars and units saved when a “mispick” turns out to be a packaging change or substitution that needs no replacement.
• Recontact rate — how often the same customer comes back about the same order, a signal the classification or response was wrong.
• Time to classification — how long it takes to move from “wrong item” to a confident root cause.
• Escalation rate — how often low-confidence cases get escalated vs. resolved at first touch.
• Documentation completeness — whether every case captures the evidence, classification, and resolution consistently.

Edge cases & future state

The hard case: multi-item, multi-issue orders. A single order can mix several of these categories at once — one true mispick, one packaging change, one customer error. The single-classification model doesn't fit cleanly when an order has several different problems.

Planned feature: per-line classification. For the future state, I want the workflow to classify each line item independently and produce a combined response and note set that handles a mixed order cleanly — instead of forcing one classification onto a multi-problem order.

Feedback loop to the catalog. The longer-term value is upstream: every confirmed listing error is a signal back to the catalog team. The investigation doesn't just resolve one customer's call — it surfaces the listing defects that would have generated the next ten.

Why this matters (the bigger picture)

AI in support should do all the time-consuming, repetitive tasks so humans can remain the warm human element in the relationship.

This isn't just “a faster way to handle mispicks.” It's a pattern: take a high-cost, high-ambiguity contact type, replace assumption with evidence, let AI draft the repetitive artifacts (comparison, email, notes), and keep the human as the one who confirms the evidence and owns the decision. That pattern generalizes — to call-note drafting, knowledge-base work, and coaching — which is exactly the lane I'm building toward: AI-enabled support operations and CX workflow design.

Tech stack