Context
The client is a mid-sized omnichannel retailer running about 60 stores and a growing e-commerce channel. Over 2024–25, online orders doubled but the order-fulfilment team — which picks, packs, and ships from two central warehouses — had not restructured. Customers were complaining about late shipments, the ops director was hiring contract staff to catch up every Friday, and finance had flagged rising refund rates.
I was brought in for six weeks with a narrow brief: diagnose the bottleneck and propose a fix that could ship before Black Friday. No software budget. No new hires. The operational reality had to change, not the tooling.
Challenge
Leadership suspected "the warehouse" was slow. The warehouse manager suspected "the system." Customer service suspected "the courier." Everyone had a theory; nobody had a measurement. The first real challenge was cutting through that ambiguity with a baseline number.
I framed three concrete questions:
- What is the actual end-to-end cycle time, from "order placed" to "tracking number sent to customer"?
- Which step in that flow consumes the most time — and how much of it is wait time versus work time?
- Are delays concentrated in a few SKUs, a few operators, or spread evenly?
Approach
I ran the engagement in four phases, each ending with a one-page brief for the steering committee so decisions didn't pile up at the end.
1. Baseline
I pulled 90 days of order data from the OMS and joined it with the warehouse management system's timestamps. After cleaning, I had a per-order timeline across five steps: order received → payment cleared → pick → pack → ship. The median cycle time was 4.2 days. The P90 was 8.1 days. That alone was a story: the average customer was experiencing a tail much worse than the average.
2. Process map
I shadowed two shifts in each warehouse and documented the as-is flow in BPMN. Two hand-offs turned out to be invisible on the org chart but expensive in time: (a) the manual fraud-review gate that kicked in for any order over $500, and (b) the batch pick-list generation that ran only twice a day.
3. Root cause
I ran a Pareto on delay hours per step. The fraud-review gate held 34% of all delay hours despite touching only 12% of orders. The batch pick-list window held another 37%. Together: 71% of the problem, two process steps.
4. Redesign & rollout
I wrote new SOPs for the two hot-spot steps, piloted them in the smaller of the two warehouses for two weeks, adjusted, and rolled out to the main site.
Solution
Three targeted changes, all implementable without new software:
- Fraud review: risk-tiered, not flat. I worked with finance and customer risk to split orders into three tiers. Tier 1 (low risk) auto-approved. Tier 2 (medium) got a 15-minute target. Tier 3 (high) kept the manual review. This reduced manual-review volume by 68%.
- Pick-list batching: hourly rolling windows. We moved from two pick-list generations a day to a rolling hourly window, with a floor of 25 orders per batch to preserve efficiency. No new software — the WMS already supported it; the policy just hadn't been updated.
- SOP card at each workstation. A one-page laminated card for packers showing the three most common error modes and the correction. Simple but the error rate dropped measurably in week one of the pilot.
"In six weeks Jayant Sharma did what two of our internal projects couldn't do in a year — told us exactly where we were losing time, and gave us a plan our ops team could run themselves." — Director of Operations
Impact
The change survived Black Friday. On the heaviest day of the year the cycle time held at 3.1 days — roughly the level the team had struggled to hit on an average Tuesday before the engagement.
Lessons
Three things I'd do again, and one I'd do differently:
- Baseline first, fix second. Every stakeholder had a confident theory. None of them were right about the distribution. An afternoon of SQL beat a month of meetings.
- One-page briefs at every checkpoint. This kept decision latency tiny and gave the sponsor cover for the decisions they had to defend upward.
- Pilot in the smaller site. It's tempting to pilot where the problem is biggest. The smaller site gave us cheap learning and cleaner data, which made the main-site rollout almost boring.
- What I'd change: I'd have invested more in the operator side of change management. The SOP card worked, but I underestimated the need to explicitly celebrate the pickers and packers who hit the new SLAs. Momentum is a real thing; I treated it as a nice-to-have.