Your robotic picking demo handled the sample tote beautifully. That does not tell you whether the system will improve your operation. The real test starts after the demo: when the SKU mix changes, an exception interrupts production, a barcode scan adds seconds to every cycle, or peak volume turns a promising rate into a daily requirement.
So skip the human-versus-robot framing. The better question is whether robotic picking can multiply the productivity of the picking environment you already have without narrowing your automation opportunity to a tidy set of easy products.
For mixed-SKU fulfillment, four questions reveal far more than a headline picks-per-hour number: How much of your assortment can the system handle? How reliably can it run and recover? What throughput can it sustain for your actual task? And how quickly do those results create financial value?
But those four questions only establish operational fit. Before approving the investment, finance and technology leaders also need to know whether the business case survives a downside scenario, whether the system can be integrated and secured at scale, and whether vendor promises are written into measurable acceptance criteria.
1. SKU coverage: Can it pick the assortment you need to automate?
You may want to check SKU coverage first because a fast robotic picking system that handles only a narrow slice of inventory leaves the rest of the work and the labor planning untouched.
Mixed-SKU operations rarely get the luxury of uniform cartons. The assortment may span spark-plug-sized parts and radiator-sized components, rigid boxes and flexible packaging, cylinders, porous materials, heavy items, and new products the system has never seen before. Your evaluation set should reflect that reality, including the products everyone is tempted to leave out of the demo.
Look beyond a simple yes-or-no pick test. Ask:
- Coverage today: What percentage of your current assortment can the system handle at the required quality and rate?
- Adaptability: What happens when packaging, dimensions, or the SKU mix changes? Does every new product require SKU-specific programming?
- Tool strategy: Can the system select or change gripping tools to match the item instead of forcing one end effector across every product?
- Future coverage: Is the vendor continuously expanding what the system can pick, and how do those improvements reach systems already in production?
End effector swapping illustrates why the tradeoffs matter. A multi-tool end effector may avoid a tool-change step. A slimmer end effector with dynamic cup swapping adds that step to some cycles, but may reach tighter spaces and smaller tote subdivisions. Neither design wins in the abstract. The right choice is the one that produces the best combination of coverage and performance for your SKU mix.
2. Reliability: What happens when production stops going perfectly?
A reliable robotic picking system is not one that never encounters an exception. It is one that runs for long periods without intervention and makes the interventions it does need fast, clear, and recoverable.
Evaluate reliability through three operational questions:
- How long can the system run without help? Ask for production data, not only a controlled demonstration. Understand what counts as an intervention and whether the metric includes the full cell.
- How quickly can the operation recover? Find out which exceptions an operator can resolve, which require a technician, and how long recovery typically takes.
- Who supports you when the easy fix is not enough? A mature lifecycle services organization, clear escalation paths, spare-parts planning, and around-the-clock support can matter as much as the robot itself, especially across multiple sites or regions.
This is also where averages can hide pain points. A respectable uptime number may still create operational disruption if the failures cluster during peak, take hours to diagnose, or require scarce technical talent. Ask to see the exception workflow from the operator’s point of view.
3. Throughput: What rate can it sustain for your actual task?
Not all throughput is created equal. Picking an item and releasing it into a large destination is a different job from scanning a barcode, orienting the product, placing it precisely, or packing it into an order container. Each additional requirement affects cycle time. Humans slow down for those steps, too.
Before comparing rate claims, define the work behind the number. Document the source and destination containers, SKU mix, tote density, required scans, placement accuracy, packing steps, exception handling, and any tool changes. Then ask the vendor to model and prove that complete process.
Peak speed is useful for understanding technical limits. Sustained throughput tells you whether the operation can hit its plan. Test performance over a representative production window, with realistic SKU transitions and the interruptions that occur in daily work.
Most importantly, measure the result at the operation level. Compare units per labor hour, staffing by shift, and total flow before and after automation—not just isolated robot cycles.
4. Time to value: Do coverage, reliability, and throughput add up financially?
Time to value is the financial outcome of the first three questions, plus the work required to insert the system into your operation.
A system with broad coverage, stable performance, and strong sustained throughput can still miss the business case if deployment requires a long shutdown, a major facility redesign, or an integration project no one scoped. Conversely, a solution that fits the existing workflow and ramps in stages may start producing measurable value sooner.
Build the time-to-value case around specifics:
- How much of the current SKU volume enters the automated flow on day one?
- What facility, conveyor, workstation, safety, and controls changes are required?
- How will the cell exchange orders, inventory, and status data with the WMS or WES?
- How long will installation, testing, operator training, and ramp-up take?
- What performance assumptions drive the ROI, and how will the team validate them after go-live?
If the vendor cannot connect technical performance to these operational inputs, the ROI is still a promise, not a plan.
The executive due diligence layer most evaluations miss
A robotic picking system can pass a demonstration and still fail the investment committee. That usually happens in the gap between a technical claim and an operating assumption: a pick rate becomes an annual benefit, theoretical SKU coverage becomes day-one volume, or labor capacity becomes cash savings without a plan to remove, redeploy, or avoid the cost.
Closing that gap requires three additional reviews: financial resilience, technical resilience, and operational ownership.
The CFO question: Does the business case survive reality?
An ROI model can be mathematically correct and still be operationally fictional. Start with total cost of ownership, then pressure-test the assumptions that create the return.
The cost model should include:
- Upfront costs: equipment, integration, facility and conveyor changes, controls, safety work, testing, training, and internal project labor.
- Ongoing costs: software and support fees, preventive maintenance, spare parts, energy, technical staffing, cybersecurity work, and future upgrades.
- Transition costs: parallel operations, ramp-related productivity loss, test inventory, travel, change orders, and deployment restrictions during peak.
- End-of-life costs: component obsolescence, migration, decommissioning, and any cost to retrieve data or move to another platform.
Treat benefits with the same discipline. Labor removed, labor redeployed, avoided hiring, reduced overtime, added capacity, and improved service are all valuable, but they are not the same kind of value. A labor hour does not become cash savings unless the operating plan shows what happens to that cost.
Model at least three cases: expected, downside, and upside. Vary the inputs most likely to move the answer, like SKU coverage, sustained throughput, utilization, time to ramp, intervention rate, labor cost, volume, and support expense. Then show when cash leaves, benefits begin, the project becomes cash-positive, and how the decision looks through payback, net present value, or the company’s preferred capital metric.
The CTO question: Can we integrate, secure, recover, and scale it?
“We have an API” is not an integration plan. The technical review should show where the robotic system sits in the architecture, which platform is authoritative for each data element, and who owns the flow from order release through exception resolution.
Require clear answers in five areas:
- Architecture and ownership: Which WMS, WES, ERP, controls, and identity systems are involved? Who maps the data, builds each interface, tests it, monitors it, and supports it after go-live?
- Failure and recovery: What happens during a network interruption, WMS outage, bad message, unavailable robot, or partial cell failure? How are orders reconciled, and can the operation continue in a degraded or manual mode?
- Cybersecurity: How are the cell and remote-support connections segmented and authenticated? What logging, patching, vulnerability management, access review, and incident-response practices are required?
- Software and data governance: Which operational data, event history, and exception logs can the customer access? How are releases validated, performance regressions detected, learned behavior governed, and failed updates rolled back?
- Scale and lifecycle: What changes when one cell becomes 20 or one site becomes 10? Ask about fleet management, master data, release coordination, support capacity, hardware availability, backward compatibility, and migration paths.
The goal is to know how the complete system behaves when a dependency fails and to make recovery an engineered workflow instead of an improvised one.
The operating question: What changes around the robot?
Automation rarely removes work without changing it. Someone still owns replenishment, damaged packaging, unrecognized products, exception queues, preventive maintenance, and escalation. If those responsibilities are not designed into the future-state operation, they return as hidden labor or lost throughput.
Follow the flow beyond the cell. Faster picking may expose a constraint in induction, packing, sortation, replenishment, or shipping. Test the complete operation at the shift and peak-volume level so the project removes a bottleneck instead of moving it downstream.
The rollout plan should name owners by shift, define staffing and skill requirements, document the manual fallback, and specify how operators, maintenance teams, engineers, and site leaders will be trained. It should also define who reviews performance after launch and who has authority to correct a process, software, or support problem.
What to require before you sign
This is where technical claims should become operating and commercial commitments. Before issuing approval, require:
- A representative test using agreed SKUs, order profiles, containers, scans, placement requirements, and exception conditions.
- Metric definitions for SKU coverage, sustained throughput, pick quality, intervention frequency, recovery time, availability, and the boundaries of the measured system.
- A site-specific deployment, integration, cybersecurity, safety, training, and production-ramp plan with named owners and dependencies.
- Financial scenarios based on agreed inputs, with costs, benefit categories, cash-flow timing, and downside sensitivities visible.
- Written acceptance criteria, support SLAs, escalation paths, warranty terms, software and data rights, upgrade terms, performance remedies, and expansion pricing.
- A post-launch measurement plan that compares actual results with the approved case and assigns ownership for closing gaps.
Finally, evaluate the partner behind the proposal. Financial stability, installed-base experience, lifecycle-services capacity, spare-parts strategy, roadmap credibility, and the ability to support every planned region affect the useful life of the investment—even when they never appear in the pick-rate slide.
How Berkshire Grey Core approaches mixed-SKU robotic picking
The Core™ Robotic Picking System combines perception, adaptive gripping, motion planning, and software in a vertically integrated system designed to complete the pick-and-place task across broad and changing assortments.
Core does not depend on SKU-specific programming for every product it encounters. It can select gripping strategies for unfamiliar items and build on what it learns through repeated interactions. Dynamic cup swapping lets the system use a tool suited to the next SKU while keeping the end effector slim enough to reach confined pick locations, including small tote subdivisions.
Together, these capabilities enable Core to lead on SKU eligibility. Berkshire Grey continues to push that boundary, expanding coverage as new products, packaging formats, and fulfillment requirements emerge.
That design reflects the central lesson of mixed-SKU automation: speed, coverage, and reliability have to be evaluated together. The best system is not the one with the most impressive isolated number. It is the one that expands automation coverage, fits the surrounding architecture, and sustains the performance your operation needs—with a deployment and support model that gets the value into production.
Start with your operation rather than a generic rate
If you are evaluating robotic picking, a Berkshire Grey expert can help you model coverage, throughput, integration requirements, and financial impact using your workflows and SKU mix. Request a free ROI assessment.
