HUL Samadhan

HUL wanted an "order today, deliver tomorrow" model for retailers: an order placed today, picked and packed that evening, dispatched overnight, on the shelf the next day, designed around a target of roughly 20,000 orders a day running through a new PTL/SBL automation layer. I'd just come off a successful pilot at HUL's Chennai site, testing conveyor communication against StackBOX's WCS and training pickers on a system they'd never used before. Once that pilot proved out, I was sent to Vapi to build the same thing from zero, with no pilot cushion this time. Vapi was a bare warehouse. The conveyor and physical stations were installed by a separate hardware vendor; everything else, including the PTL lights, controllers, the network, and the StackBOX system itself, was mine to build. I was under six months into my time at StackBOX. If this site failed, HUL was a client we stood to lose.

I ran Vapi as a set of parallel, independent workstreams: network readiness, conveyor-to-WCS-to-StackBOX communication testing, PTL bin setup, picker and supervisor training, and a live issue tracker feeding both the hardware vendor and StackBOX's product team, instead of one sequential chain gated on the vendor finishing first. That was the deliberate rejection: never let a vendor blocker, like a conveyor fix or a diverter fault, stall the whole timeline. Whatever couldn't move, I flagged and tracked to resolution. Whatever could move, like training and network testing, I pulled forward and ran anyway. Treating the build as parallel tracks instead of one blocked queue is the reason the timeline held.

The BRD was already locked by a previous project manager before I arrived; my scope started at infrastructure and system readiness. UAT ran roughly 30 days against a large infrastructure footprint. I trained and certified around 20 pickers and 3 shift supervisors from scratch, covering picking strategies for both SBL and PTL, app navigation, and repicking flows, in parallel with the infrastructure fixes. I was the only person on-site who understood both what the StackBOX system expected and the physical and network infrastructure behind it, which made me the sole source of technical visibility on the floor. When something broke, like a crate not diverting or looping the conveyor instead of dropping to its station, I traced it back through the StackBOX WCS logs myself, then routed the fix to the hardware vendor or StackBOX's product team depending on where the fault actually lived. I also ran mock order test cycles to validate that StackBOX, the WCS, and the conveyor were working in unison before signing off on readiness. My scope ended at UAT-complete, training-complete, handoff-ready. I was transitioned to a different project as soon as the site cleared for go-live, and handed the account back to the original project manager.

The site passed UAT and moved to go-live on the strength of that readiness work. Handover was clean: every picker and supervisor was certified on both the system and the physical infrastructure, and the incoming project manager inherited a site with no open technical unknowns. I wasn't on-site for go-live day itself, so the post-launch throughput numbers aren't mine to claim. The deliverable was a bare warehouse taken to a fully tested, staffed, and validated go-live-ready state, solo, inside a UAT window that held despite starting from zero infrastructure.