Case Study: From Paper Pick Lists to Scan-to-Bin Picking
At a glance
- Where: An online retailer with about 100 employees, several million dollars in annual revenue, and its own warehouse with 10â13 people picking, sorting, and shipping each day
- My role: Requirements, research, testing, hardware setup, documentation, and training. I was the go-between for the warehouse team and a remote engineering team.
- What changed: Batched paper pick lists and a separate sorting step were replaced with a barcode system that picks each order straight into its own bin
- Outcome: Live for every order by the time I left. By my estimate, picking errors dropped about 80%, and new pickers were ready in hours instead of days.
The old process: every item handled three times
Orders were batched about 20 at a time onto one printed pick list. A picker took the list, walked the warehouse, and put everything into four large totes on a cart. The list didnât separate items by order, so all 20 orders ended up mixed together in those four totes.
The totes then went to an order sorter. The sorter sat at a computer, scanned an order, scanned each of its items one at a time to group them, and sent the finished order on to shipping. Shipping then checked every item on the order a second time.
So every item was handled at least three times: picked, sorted, and verified. On a typical day that meant 4â5 pickers, 3â4 sorters, and 3â4 shippers all working on the same items.
Most of the slowness came from a few recurring problems:
- Out-of-stock items showed up last. Nothing on the pick list said an item was out on the shelf. A sorter might scan 13 of an orderâs 14 items before finding out the 14th didnât exist. That order then had to be set aside after all that work.
- One SKU could hold up the whole batch. When a new product launched, many orders would include it. If it sold out, all 20 orders in the batch could end up waiting on one item.
- Lost paperwork. If a pick list went missing, someone had to work out which orders in that batch had been picked and which hadnât.
- No routing. Pickers walked the warehouse in whatever order the list happened to be in.
- Tribal knowledge. There were plenty of unwritten rules about locations and products. A new picker usually learned them by making a mistake and getting corrected.
Seeing it for myself
Everyone agreed the process didnât work. It took a new company president to approve fixing it. Once the project was mine, I didnât want to design from other peopleâs descriptions, so I spent a couple of hours picking orders and then sorted some myself.
It was worse in person than it sounded. The waste was obvious, but so was how much a picker had to just know to do the job right. That shaped the main goal for the new system: someone who had never picked an order should be able to get a short walkthrough and be picking correctly in about 10 minutes.
Constraints
Bin and location names couldnât change freely. Over the years, our engineers had hard-coded behavior around the original warehouse layout and its location names. Modern picking systems expect a clean, consistent location scheme, and we didnât have one. The hardest part of the project was fitting our old location system into a modern picking workflow without breaking the code that depended on it.
The engineers were remote. They never saw the floor, so they couldnât watch a picker hit a problem. Turning what happened in the warehouse into something they could reproduce and fix was a large part of my job.
Web app, not native. The tablet interface was a web page inside our existing .NET MVC ERP, backed by MySQL. A native Android or iOS app calling an API would have been smoother, but nobody on the team had built a mobile app before. We accepted some clunkiness to stay with tools the team could actually build and support.
The new workflow
I researched how other picking systems worked and which of their ideas we could use. The design we landed on was built around barcoded order bins.
1. Load the cart. A picker takes 16 empty order bins and puts them on a rolling rack. Every bin has its own barcode. When the picker scans a bin, the system assigns it the next available order. After 16 scans, the cart holds 16 empty bins, each one tied to a specific order.
2. See problems before picking. Before picking starts, the system shows any issues coming up, such as an out-of-stock SKU. The picker finds out at the start of the run instead of a sorter finding out halfway through scanning an order.
3. Follow the route. The system shows the next SKU and quantity in a set route, along with a product image so the picker can see exactly what to grab. That matters when several products look nearly identical on the shelf. The route loops around the warehouse and ends near the shipping stations, close to where the picker started.
4. Scan to pick, scan to place. The picker scans the product, and the system says which bins it goes in and how many in each. If bin 2 needs three of an item, the picker scans the product three times and then scans bin 2 to confirm where they went. A wrong item triggers an on-screen error and an alert sound right away.
5. Hand off and repeat. The picker leaves the full cart at shipping. Shipping takes out the 16 orders and sets the cart aside for the next picker, so carts move in a steady loop.
The separate sorting step went away entirely.
The rules underneath it
These were the requirements that made the workflow trustworthy:
- One order, one bin. An order can only be assigned to one bin. The only way to change that is a deliberate manual transfer to an empty bin.
- Every placement is verified. Each item is scanned when picked and its bin is scanned when placed, so an item canât end up in the wrong order without someone noticing.
- Quantity is scanned, not typed. Three units means three scans, which takes away the habit of grabbing âabout three.â
- Problems show up early. Out-of-stock items are flagged before picking starts, not found partway through an order.
- The system holds the knowledge. Routes, locations, quantities, and product images are on the screen, so a picker doesnât need to remember them.
Testing with real data, without risking real orders
I didnât want to test on made-up orders, and I didnât want to risk orders that still needed to ship. So I loaded a large set of orders that had already shipped into the new system as test data. That gave us real SKUs, real locations, and real order sizes with no risk to live orders.
I also set up the hardware: inexpensive Android tablets paired over Bluetooth with handheld barcode scanners. Then I ran pick after pick, adjusted the workflow, and wrote up what broke.
Working with engineers who canât see the floor
I didnât write the tablet code. My job was to make sure what got built worked for the people using it. In practice that meant a lot of bug reports, and I learned quickly that a vague ticket from the warehouse often got misread or put aside by someone who had never seen the problem.
So I got very thorough. Each ticket said what the picker was doing, what they expected, what happened instead, and how to reproduce it, with screenshots. When a problem still wasnât getting through, I recorded a video of it happening on the tablet. That cut down a lot of back-and-forth, and it changed how I write requirements: assume the reader has never been in the room.
Rollout and results
After the pilot and some tuning, we moved to the new system. By the time I left, every order went through it.
I donât have before-and-after reports, so these numbers are my estimates from working on the floor:
- Picking errors: down about 80%. Product images helped pickers grab the right item the first time, bin verification caught anything placed in the wrong order, and wrong-item scans were blocked on the spot.
- Onboarding: new pickers went from days of learning unwritten rules to being productive within hours
- Bottlenecks: the separate sorting step was gone, out-of-stock items were caught before picking, and one sold-out SKU no longer stalled an entire batch
- Morale: this one isnât a number, but it was real. The warehouse team could see their daily work getting easier, and it built trust for the projects that came after.
What I took away
The biggest lesson was to experience the problem as the user does. A couple of hours of picking taught me more than any meeting could, and it gave me the goal that guided the rest of the project: a new picker should be productive in 10 minutes.
Nobody wants to be held back by clunky software. A good system takes knowledge that used to live in peopleâs heads and puts it on the screen, so the job is easier to learn and less frustrating to do.