Attend Our Live Robots-to-Goods Webinar May 13th
Every successful warehouse automation program starts with one moment of clarity, which is the proof of concept (PoC). It’s where ideas turn into data, assumptions get tested, and teams learn whether a solution will actually hold up when picks start to fall behind, labor is tight, or the floor gets backed up. It also gives teams a low-risk way to evaluate automation and build confidence before committing to broader change, especially when the real question is whether the operation can hold pace when conditions aren’t ideal.
For Staples Canada, that learning process was the foundation of its warehouse transformation. Long before the company rolled out Locus Robotics’ autonomous mobile robots (AMRs) across its network, the team launched a structured proof of concept designed to validate value before scaling it.
Rather than relying on top-down directives, Staples built its program from the floor up to engage engineers, operators, and leadership to measure success with precision. The result was an automation model that paid off not just in productivity, but in operational confidence, which is the ability to scale decisions with clarity, knowing the operation could maintain pace without things backing up downstream.
Groundwork: Define the “Why” Before the “What”
A proof of concept is only as strong as the problem it’s built to solve. Staples Canada began its journey by analyzing data from across its fulfillment network, including SKU velocity, order profiles, and cycle times, to understand where inefficiencies existed. More importantly, it showed where time was being lost in travel, pick paths, or handoffs that slowed the entire shift. It also ensured the team could evaluate automation in a low-risk, measurable way before committing to scale.
“We started with lots and lots and lots of data pulls,” said Mert Selcuk, Director of Supply Chain Strategy & Solutions Design at Staples Canada, during his appearance on the Warehouse Automation Matters podcast, where he discussed building flexible, scalable automation programs. “Our goal was to identify inefficiencies we could quantify and improve and not just automate for the sake of it.”
That mindset framed the POC as a discovery process rather than a deployment project. The objective wasn’t to prove that automation worked — it was to prove that it would work for them on a real shift, with real volume, without introducing new bottlenecks. This approach reflects a more flexible way to evaluate automation, grounded in real operational conditions rather than assumptions.
Stakeholder Alignment: Build Ownership Early
A successful proof of concept doesn’t happen in isolation. It requires cross-functional alignment from the start, and Staples’ internal engineering team, operations leaders, and front-line associates all participated in designing test parameters.
Your Move
To replicate this alignment in your own POC:
- Identify a champion from each stakeholder group, including operations, IT, and finance.
- Define what “success” means from their perspective, like cost reduction, predictability, or capacity gain.
- Set measurable KPIs that all parties agree on before testing begins.
Staples’ team validated every assumption with data. Early collaboration ensured that once results arrived, everyone trusted them, and no one felt the need to “re-prove” outcomes later. That alignment also creates a smoother path from pilot to full-scale deployment, where confidence across teams becomes critical. When operations, IT, and finance are aligned early, decisions move faster later without slowing things down when the volume is already hitting the floor.
Design for Reality, Not Perfection
The company approached its proof of concept with a “bottom-up” philosophy to start small, learn fast, and refine continuously. The pilot area replicated the complexity of the full warehouse with mixed SKUs, variable pick density, and real-world bottlenecks.
That realism mattered because it allowed the team to test how the system would perform when the floor was moving, orders were stacking up, and timing mattered. Engineers adjusted layouts, routing logic, and pick paths dynamically, using the real-time data feed from LocusHub to validate improvements.
The test wasn’t about hitting perfect numbers; it was about proving repeatable improvement. “We didn’t need a record day,” Selcuk noted. “We needed a reliable day that showed we could sustain the change.”
In other words, they were looking for a system that could keep work flowing consistently, not just spike performance for a short window.
Designing the test this way ensured the solution could adapt to real-world variability, not just controlled scenarios.
Your Move
When designing your own automation proof of concept:
- Mirror your actual workflows, including exceptions.
- Collect baseline performance data for fair comparison.
- Prioritize operational learning over short-term optics.
Translate Data into Decisions
Once automation went live in the test zone, Staples monitored every performance metric, including units per hour, travel distance, pick accuracy, and order lifecycle time. The proof of concept quickly provided clarity on where robotics delivered the highest impact. It showed where time was being recovered, where movement was reduced, and how much more work could be completed within the same shift.
The findings weren’t theoretical:
- Productivity nearly doubled, from 42 to 82 UPH.
- Cycle time decreased by 70%.
- Quality control steps were eliminated, freeing both labor and space.
This level of clarity is what allows teams to move forward with confidence, not assumptions. It also answered a more practical question of could the team hit rate consistently without the shift falling behind?
But the numbers were only half of the story. Associates reported less fatigue, higher engagement, and a smoother daily rhythm. Less walking, less fatigue, and fewer slowdowns meant associates could stay on pace without the usual drop-off later in the shift.
As Ash Van Schelven, Regional FC Manager, explained, “People can do their jobs better. The environment is safer, and they actually enjoy being here.”
That human feedback became part of the ROI equation, which is a reminder that sustainability and efficiency go hand in hand — and contribute to a more resilient labor model.
Build Confidence Before Scale
A proof of concept succeeds when it produces both data and belief. At Staples Canada, the engineering team didn’t wait for the final report to start planning next steps. They reviewed progress daily, comparing metrics in LocusHub against their baselines and adjusting workflows as needed. That visibility made it easier to catch issues early before they turned into bigger slowdowns across the operation.
This iterative rhythm created momentum. By the time the test concluded, leadership didn’t need persuasion to expand the program because they already saw it working. This iterative approach reflects a flexibility-first deployment model, where continuous adjustment drives stronger long-term outcomes.
Your Move
To build momentum after your POC:
- Schedule daily debriefs with stakeholders to share data transparently.
- Capture associate feedback as qualitative evidence of change.
- Use measurable wins, like shorter shifts or fewer errors, to justify next-phase funding.
Staples’ proof of concept proved that the technology, along with a culture of collaboration, could scale.
Keep Improving After Success
Perhaps the most valuable lesson from Staples’ experience is that the proof of concept never truly ends. Data from the initial test now informs ongoing decisions about layout design, labor allocation, and seasonal planning. That matters when volume shifts quickly and operations need to adjust without disrupting the flow of work. Each improvement compounds, reinforcing the ROI of that first, well-structured experiment.
As programs expand, platforms like LocusONE™ make it possible to apply those learnings across sites, workflows, and seasons without starting over.
Your Move
Even after a successful rollout:
- Continue collecting the same metrics that defined success during the POC.
- Revisit workflows quarterly to identify new optimization opportunities.
- Treat automation as a continuous feedback loop, not a finished project.
A proof of concept is a statement of intent that shows your team, your partners, and your leadership that automation decisions are grounded in evidence, not enthusiasm.
For Staples Canada, that approach built a foundation of trust and clarity. The result was a strong return on investment along with a repeatable framework for every automation project that followed — one grounded in data, adaptability, and operational confidence, so when volume spikes or labor shifts, the operation can keep moving without missing pace.
Article 
