AI in Warehouse Operations: Trace Pick Errors Back to Their Cause

Coding Liquids tutorial cover featuring Sagnik Bhattacharya for AI in Warehouse Operations: Trace Pick Errors Back to Their Cause.
Coding Liquids tutorial cover featuring Sagnik Bhattacharya for AI in Warehouse Operations: Trace Pick Errors Back to Their Cause.

A small warehouse can export its pick error log with the order lines, bin locations and shift attached, ask an AI assistant to sort each error into a cause category, then group them by SKU, location, picker experience and time of day. The groups with the most errors per 1,000 lines point to the cause; you then test one fix at a time.

The AI is useful here because the log is untidy and the grouping is tedious, not because it knows your building. A cause it proposes is a hypothesis to walk to the shelf and check. In the worked month below, the obvious culprit (new starters) turns out to be one cause seen three ways, which is why the grouping step matters more than the ranking.

Follow me on Instagram@sagnikteaches

What the error log needs before the AI sees it

Most warehouses have two partial records of errors: customer complaints (wrong item arrived) and internal catches (the pack bench noticed a mismatch). Combine both, because complaints alone under-count and skew towards what customers notice. The columns that make the later grouping possible:

Connect on LinkedInSagnik Bhattacharya
  • Date and order number, and the order line (so one error is one row).
  • SKU expected and SKU picked, or quantity expected and picked.
  • Bin location the item was picked from and the location it should have come from.
  • Picker ID (not name) and the date that person started picking.
  • Shift and time of the pick, and the pick method (paper list, handheld scanner, pick-to-cart).
  • How it was found: pack bench, customer complaint, cycle count.
  • A free-text note from whoever logged it.

If you do not have all of these, start with the ones you have and add one column a week. A column you can fill by joining to the WMS later (picker start date, bin of origin) is better added by export than by hand. Also export a denominator: the total order lines picked in the same period, by zone and by shift. Without it you will confuse "most errors" with "busiest".

Subscribe on YouTube@sagnikteaches

Remove picker names and replace them with IDs before upload, and use a business plan with training on your data off.

The Complete Excel Course with AI Integration thumbnail

The Complete Excel Course with AI Integration

From formulas and pivot tables to Power Query, DAX, VBA and AI with Copilot, ChatGPT and Claude — hands-on from the first lesson.

By Sagnik Bhattacharya and Virginia Thorn, Primetime Emmy Award winner

Buy now

The worked month: 62 errors in 5,400 orders

This is an illustration with invented figures. Say a small e-commerce fulfilment warehouse with 14 staff picked 5,400 orders (13,100 order lines) in a month. The error log has 62 rows, giving 4.7 errors per 1,000 lines. The manager cares because each error costs about $11.50 on average once you add the reship, the return handling and the support time. That is $713 in the month, plus the customers who do not come back.

Step one is to ask for categories. Do not supply a list; let the AI propose one from the notes, then fix it.

Attached is a pick error log (62 rows). Columns: date, order_line, sku_expected, sku_picked, qty_expected, qty_picked, bin_expected, bin_picked_from, picker_id, picker_start_date, shift, pick_method, found_by, note.

1. Read each row and assign one error type from this set, adding a new type only if none fits: wrong SKU, wrong variant (size or colour), wrong quantity (over), wrong quantity (short), item in wrong bin (stock location error), damaged item shipped, other.
2. Show a table of the types with count and share of the 62.
3. For each type, quote two example notes.
4. List any rows where the columns contradict each other (for example, sku_picked equals sku_expected but the type is wrong SKU).

Illustrative reply:

Error typeCountShare
Wrong variant (size or colour)2134%
Wrong SKU1423%
Wrong quantity (short)915%
Item in wrong bin (stock location error)813%
Wrong quantity (over)58%
Damaged item shipped35%
Other23%

The AI also flags three contradictory rows. Two are typos in the SKU column; the third is a "wrong SKU" that its own note describes as a damaged item. The manager corrects them and asks for the table again. Fifteen minutes in, the ranking says that variant mix-ups, not careless picking in general, make up a third of errors.

Group by where, who and when, per 1,000 lines

A category tells you what went wrong. Grouping tells you where to look. Ask for rates, not counts, using the denominator you exported.

Using the error log and the lines-picked table (zone, shift, pick_method, lines), calculate errors per 1,000 lines for: (a) each pick zone, (b) each shift, (c) each pick method, (d) pickers with under 4 weeks' experience versus others. Show the numbers and the lines behind each, because small bases are unreliable. Mark any group with fewer than 10 errors as "low base, indicative only". Do not conclude anything about individuals.

Illustrative output:

GroupLinesErrorsPer 1,000 lines
Zone C (apparel)3,900317.9
Zone A (accessories)5,800122.1
Zone B (homeware)3,400195.6
Day shift9,700363.7
Evening shift3,400267.6
Paper list2,9002910.0
Handheld scanner10,200333.2
Pickers under 4 weeks1,800179.4

Three things stand out, but notice they overlap. Zone C has the apparel lookalikes, the evening shift is mostly new starters working paper lists, and paper lists are mainly used in zone C because the handhelds do not reach the mezzanine. Each of those groupings looks like a cause, and they are probably one cause seen three ways. That is the central risk of pick error analysis, and the next section deals with it.

Untangle overlapping causes before choosing a fix

When groups overlap, ask the AI to cross-tab them, not to rank them separately.

Cross-tabulate errors per 1,000 lines for zone C only: pick_method by experience (under 4 weeks or more). Then the same for zones A and B combined. Show lines and errors in each cell. Say which cells are too small to read.

The illustrative result: in zone C, paper-list picks by newcomers run at 16.7 errors per 1,000 lines (9 errors in 540 lines) and paper-list picks by experienced staff at 8.8 (19 in 2,160). The 1,200 zone C lines picked by scanner, at the end of the mezzanine the handhelds do reach, run at 2.5 (3 errors, a low base). In zones A and B combined, scanners run at 3.3 (30 errors in 9,000 lines) and paper lists are barely used (1 error in 200 lines, too small to read). So newcomers make it worse but are not the cause: experienced pickers on paper in zone C still err at more than double the scanner rate, and apparel picked with a scanner is no worse than the rest of the building. The combination of lookalike apparel variants and a paper list with no scan confirmation is the problem, and a scan check on the variant barcode would cut most of it. The apparel zone also has no size-change labelling on the shelf: sizes S, M and L of the same style sit in adjacent bins with matching labels except for one letter.

Now the finding is specific enough to test, and it was not the first thing the raw counts suggested. If the manager had simply moved the new starters to zone A, errors would have been hidden, not fixed.

Go and look: the cause is on the shelf

Take the AI's findings and walk the building with the 21 variant errors list. For each of the top ten rows, stand at the bin and ask what would make you pick the wrong one. Write down what you see in plain words, then paste the notes back for grouping.

Illustrative notes from the walk: "S and M labels both 9 pt black on white, 6 mm apart"; "Style 4410 and 4411 differ only by a digit, bins side by side"; "Bin 3-14 holds two SKUs in one tote"; "paper list prints SKU at 8 pt, no size column"; "returned stock put away to the first free bin". Ask the AI to group these into fix candidates and attach the number of logged errors each would plausibly address.

Group these walk notes into fix candidates. For each candidate, list the error log rows it could have prevented (by row number), the rough effort (under an hour, a day, a week) and what I would measure to prove it worked. Do not claim a fix will work; call each a test.

You will get something like this, which the manager trims:

  1. Print size in large type on the paper list, and as its own column. Could address 11 of 21 variant errors. Under an hour. Measure: variant errors per 1,000 lines in zone C.
  2. Separate adjacent lookalike styles by at least one bin and use a coloured label for size. Could address 9 errors. A day. Measure: same.
  3. Add a scan check on the variant barcode at the pack bench. Could catch most variant errors before they leave. A day, subject to the system. Measure: errors found at pack bench versus by customers.
  4. Put returned stock through a put-away check, not the first free bin. Could address 6 of the 8 location errors. A week to train. Measure: location errors from cycle counts.

Link this stage to your standard operating procedures: training cards for picking and packing are the natural place to put the rule once a fix has worked.

Run one fix at a time for a month

Resist doing all four at once. If errors fall, you will not know why, and if they rise you will not know either. A simple testing plan:

  • Week 0: record the baseline per 1,000 lines for the zone. In the example, 7.9 in zone C.
  • Weeks 1 to 4: apply fix 1 only (the bigger print and size column). Keep everything else, including staffing mix, as steady as practical.
  • End of week 4: re-run the same prompt on the new month. Compare per 1,000 lines, not counts.
  • Then keep the fix if the rate fell by a margin you would notice, say from 7.9 to under 6, and start fix 2.

With only a few dozen errors a month, a drop from 7.9 to 6.5 could be chance. Ask the AI for the lines and errors for each week, so you can see whether the rate fell steadily, not once. If the improvement is small, run the month again before deciding.

Illustrative result for the example: zone C goes from 7.9 to 5.2 per 1,000 lines after fix 1, then to 3.8 after fix 2. At 3,900 lines a month, 7.9 meant 31 errors; 3.8 means about 15. That is 16 fewer errors, about $184 a month at $11.50 each, plus fewer unhappy customers. The cost of the changes was an afternoon and some labels.

Where the AI's grouping lets you down

  • It trusts the notes. If a logger wrote "picker error" on every row, the AI will categorise by what is in the columns, which is useful, but it cannot recover facts nobody wrote down.
  • It treats small bases as findings. Always ask for the lines behind each rate and keep the "low base" instruction in the prompt.
  • It mixes up cause and symptom. "Picker under four weeks" is a symptom of rushed training or a hard zone; the cause is what you change.
  • It cannot see near misses. If the pack bench quietly fixes errors and logs nothing, your log understates the problem. Log catches for a month, even on a tally sheet.
  • It can invent a neat story. A reply such as "errors cluster after 3 pm due to fatigue" needs the time column to support it. Ask: which rows show that?

A quick audit of the AI's output: pick two groups it highlighted, count their errors by hand in the spreadsheet using a filter, and compare. If they differ, the AI misread the file; fix the file or the prompt.

The month the manager blamed the wrong picker

Here is a mistake that is easy to make, shown as a short story with illustrative details. In the first run, the AI's per-picker table put one experienced picker, ID P07, at the top with 9 errors. The manager was ready to have a word. Then the prompt was re-run with lines picked per person: P07 had picked 2,600 lines, almost double anyone else, because P07 covered zone C every evening when the others rotated out. Per 1,000 lines the figure was 3.5, below the warehouse average of 4.7. The word was never needed, and the rota changed instead: zone C rotates between three people, so no one carries the lookalike zone alone.

The lesson for your own file is to keep "lines picked" next to every count, for every group, including individuals. And keep the instruction "do not conclude anything about individuals" in the prompt; ask for the individual view only when a coaching conversation needs it, and read the zone first.

A near-miss tally the pack bench can keep

Complaints show the errors that got out. To see the ones that did not, give the pack bench a tally sheet for a fortnight. It needs only five columns, filled in with a pen: time, order line, what was wrong (tick: wrong item, wrong size or colour, wrong quantity, damaged, other), the bin the item came from if known, and initials. At the end of the fortnight, type it in and merge it with the complaints log. Illustrative result: 38 catches in two weeks against 24 complaints in the same period, which means the real error rate was about 2.6 times the one the manager had been tracking. The categories matched, but the bins did not: catches clustered in zone B, which had few complaints because customers there were mostly business buyers who checked deliveries and said nothing.

Ask the AI to compare the two sources:

Here are two lists: customer complaints (24 rows) and pack-bench catches (38 rows) for the same fortnight, with the same columns. Compare error type and zone shares between the two lists. Where do the shares differ by more than 10 percentage points? Suggest reasons as hypotheses I can check, not conclusions.

A realistic reply notes that zone B is 42% of catches and 17% of complaints, and suggests that zone B customers may be less likely to report errors, or that the pack bench checks zone B items more carefully because they are heavier. Either explanation changes what you do, so ask the pack bench.

A weekly scorecard worth pinning up

Once the log is clean, reduce it to one page the team can read in thirty seconds. Ask the AI to produce it from the sheet each Monday, in this shape (illustrative figures):

MeasureThis weekLast weekFour-week average
Order lines picked3,1803,0503,275
Errors found (complaints plus bench)111415
Errors per 1,000 lines3.54.64.6
Of which wrong variant355
Of which caught at the pack bench689
Fix on trialSize column on paper list (week 3 of 4)

Notice that the table has the trial fix written on it. A scorecard that names the thing you are testing keeps the team looking at the same question, and when the four weeks end the decision to keep or drop it is made in public. Do not publish error counts by person on the wall; keep the individual view for private coaching.

A trade counter and a food distributor: same method, different errors

A building-supplies trade counter has far fewer lookalike items but a lot of unit-of-measure errors, such as a pack of 10 versus a single. Its log would show "wrong quantity" at the top, and the fix is a clear unit on the pick list and the bin label, not new technology. A small food distributor sees date-code errors, where the right product but the wrong batch was picked. That changes the data you capture (batch or best-before date) and the fix (first-expiry-first-out labelling), and the cost of an error is a rejected delivery, not an $11.50 reship. The method is identical: log, categorise, group by rate, walk the floor, test one fix.

Feed the findings back into stock and planning

Pick errors rarely live alone. Bin location errors connect to how you plan cycle counts: counts catch mislocated stock before a picker walks to an empty bin and substitutes. Lookalike clusters connect to slotting by pick frequency, where you can add a rule that similar SKUs never share an aisle face. If your clients get weekly reports on service levels, 3PL client KPI reports are a place to show errors per 1,000 lines honestly, with the trend after each fix. And if you want a structured way to ask "why" repeatedly about the stubborn ones, five whys prompts help once you know the cause category.

Time, cost and a first-week plan

Expect half a day for the first run: an hour to export and clean the log, an hour for categorising and correcting, an hour for grouping and cross-tabs, and an hour on the floor. Later months take about 30 minutes. A general-purpose assistant on a paid individual plan, from about $20 a month (ChatGPT Plus, or Claude Pro billed monthly), handles files of this size; a business plan with training on your data off costs a little more per seat.

  1. Day 1: combine complaints and pack-bench catches into one sheet; add the denominator table.
  2. Day 2: run the categorisation prompt, fix the contradictions, agree the category list with your shift leads.
  3. Day 3: run the rate and cross-tab prompts; pick one group that stays high after the cross-tab.
  4. Day 4: walk the shelves, write what you see, ask for fix candidates.
  5. Day 5: choose one fix, write the baseline on the wall, start the clock.

If you would rather go through your own log with someone, mapping the first fix and the measure that proves it, that is what an AI implementation consultation is for.

Questions from warehouse managers about pick error analysis

How many pick errors do I need before patterns mean anything?

About 40 to 60 logged errors gives you a first look at the top two or three causes. Under 30, read them yourself. If you have few errors because accuracy is already very high, widen the window to three months or record near misses caught at the pack bench as well.

What is a good pick accuracy rate?

Targets vary with order mix and how errors are counted, so measure your own baseline first. Count errors per 1,000 order lines, not per order, because a ten-line order with one wrong line is a much better result than a one-line order that is wrong. Then watch the trend, not a published figure.

Does the AI need access to my warehouse management system?

No. An export from the system, or your own spreadsheet of errors with the order lines attached, is enough. Keep the analysis offline from live stock: the AI reads a file, and you decide what changes in the building.

Should I discipline pickers with the most errors?

Not on the AI's ranking alone. A picker who works the busiest zone or the lookalike products will show more errors without being less careful. Check the cause category and the zone first, and use the figures to coach, not to punish.

Further reads

Sources: your own pick error log and WMS exports; the worked example uses illustrative figures and a generic e-commerce fulfilment warehouse.

Want your pick error log turned into fixes?

On a 1:1 call we can look at how errors are recorded in your warehouse, choose the categories worth tracking, and set up a monthly review your team can run with an AI assistant.

Book a 1:1 call with me