5 questions that reveal what’s really behind a warehouse automation proposal

1. What assumptions drive your throughput model and how are they applied?

A throughput model is only as good as its inputs. The math itself is straightforward; any integrator with an Excel license can build a capacity model and screenshot its results into a proposal. What the proposal rarely shows in detail is where that number came from. Was it built from your actual order data, your historical SKU velocity distribution, your real seasonal peaks? Or was it built from industry benchmarks adjusted to land near your stated volume requirements? Sure, there may be assumptions listed, but the methodology for how those assumptions are applied is harder to discern, and what really matters. 

A vendor who has built the model rigorously will be able to name the specific data sources used and walk through the logic clearly. It should be possible for them to describe which operational records informed the model, how they treated seasonal variation and promotional peaks, where they made assumptions, and why, in the absence of complete data. In the best-case scenario, they’ve put these assumptions in front of you long before the proposal due date. If a vendor cannot reconstruct their methodology without referencing the answer it produced, it’s worth probing deeper.

References to industry benchmarks, "operations of your type and scale," or a general inability to separate the method from the output are signals that the model may be working backwards from a target rather than forwards from your data. These kinds of statements are great (and very appropriate!) for a ROM level of detail or for a “quick and dirty” business case analysis, but a system whose final detailed design is built on borrowed assumptions has a critical issue: it performs well under borrowed conditions. When your operation diverges from the scenario the model was built on, the gaps become visible.

Two assumptions that are almost always present in a throughput model, and almost always underexplored, are hit rate and user rate. Hit rate, sometimes called batch factor, describes how often a bin presented to a port operator contains picks for multiple open orders simultaneously. A high hit rate is efficient: it means the system is working hard for each bin retrieval, but it is also sensitive to order profile. A shift in product mix, the introduction of a new sales channel, or a change in how orders cluster can move hit rate significantly, and since most models are built on historical data that predates those changes, the assumption tends to be optimistic. An overly aggressive hit rate produces a throughput figure that looks strong on paper but degrades under real operating conditions. User rate compounds the same problem from a different direction: the mechanical throughput ceiling of a port and the rate a real operator can sustain — accounting for scanning, lot capture, label application, and the natural variation in how people work — are often meaningfully different numbers. When a vendor presents their throughput figure, it is worth asking specifically: what hit rate and user rate were assumed, and what data were they based on?

2. What high-stress operating scenarios did you evaluate, and how does the system perform under them?

A system that performs well at average daily volume is not necessarily a system designed for your actual operating environment. Peak periods, promotional events, seasonal surges, end-of-quarter pushes, are exactly when automation needs to earn its investment, and exactly when a design that was never evaluated under real pressure will show the gaps. The question is not whether peaks will happen. It is whether the design was built around yours, specifically.

A vendor who has thoroughly evaluated the design will be able to name the scenarios they tested and how the system performed under those conditions. The method matters less than the rigor: whether through simulation, analytical modelling, or capacity calculations, they should be able to demonstrate how the design was evaluated under demanding operating conditions. Specificity is the signal. An answer that describes what the system does at a defined multiple of average volume, names the component that becomes the constraint at that point and explains the design decision taken to address it, is much more robust than a general statement about built-in capacity headroom.

Confident assurances that the system "handles peaks well," or references to capacity buffers without supporting analysis are not evidence of a stress-tested design. If a vendor cannot describe what their analysis modelled and what the outputs showed, the peak performance figures in the proposal are estimates. That distinction matters significantly when your Black Friday volume (or order profile!) hits a system that was sized for an average Tuesday. One example is a retailer who offers free shipping for orders over $50 for most of the year, but drops that number to $25 on Cyber Monday. As a result, your annual average units per order may be 5, but your Cyber Monday units per order is 3… a system designed for 5 units per order at peak is likely to struggle under 3 units per order. The same logic can be applied to Singles %, Bag -v- Box%, lines per order, and batch factor – all these things need to be evaluated with nuance to ensure your system can perform best when it needs to.

3. Where is the system constrained?

This is the question vendors are most structurally reluctant to answer, which makes it the most revealing one to ask. Every automated system has a point where adding demand produces diminishing returns, a throughput ceiling tied to a specific component, configuration, or flow. An integrator who has genuinely stress-tested or fully analyzed the design knows exactly where that point is, and what causes it. One who has not tends to discover it in commissioning, after go-live, or at peak, when the cost and disruption of addressing it is orders of magnitude more than what it would have been if caught and addressed at the design stage.

A good answer names the constraint specifically, for example the ceiling on the per-port throughput, a robot fleet density limit, a conveyor merge point, or a software sequencing boundary. A good answer explains the design decision, contingency, or relief valve made to manage it. Constraints exist in any automation technology, even very flexible solutions such as AutoStore – so understanding where and when they occur is critical to achieving expected throughput and operational performance.

Reluctance to identify any constraints, or constraints that emerge for the first time during commissioning conversations, are both signs of a design that has not been adequately evaluated. A vendor presenting a system with no apparent limitations is not describing something “better engineered”; they are describing something less thoroughly examined. This is the question that, when asked directly, most visibly reveals the gap between a rigorous design process and a superficial one. Similarly concerning is if the communicated rates for your system are equal to the machine rates advertised for the machine. For example, an Autostore Carousel port is advertised at ~350 Bins/Hour, but this is the mechanical top-end, and does not account for the fact that the user process at the carousel port may be constrained by something else – such as scanning, lot capture, label application, etc. So, always try to ask what limits not only the full system, but the subsystems and user rates.

It is worth acknowledging that the pre-sales design process is a rapid and demanding one – and that most solutions are, at least in some way, custom. As a result, the depth of engineering analysis feasible before a proposal is signed will vary. The vendors most worth working with are those who are transparent about what was evaluated during pre-sales and committed to rigorous analysis continuing through post-award engineering and project execution.

One constraint worth asking about specifically is bin contention. In an AutoStore system, multiple robots operate simultaneously across the grid, each assigned to retrieve a bin from a specific location. When several robots are directed to bins stored in close proximity, they can end up queuing behind one another waiting for access to the same area. The effect is that effective throughput falls below what the robot fleet is theoretically capable of, not because the robots are slow, but because they are waiting on each other. Bin contention is manageable with the right design decisions: bin distribution strategies, inventory slotting, and grid layout all influence how often it occurs and how severely, but it only gets managed if the vendor has looked for it. A design that has not been evaluated for bin contention will surface it at peak, which is exactly the wrong moment to discover that your throughput ceiling is lower than your proposal suggested.

4. How can I build this system to allow for future growth?

Most proposals address growth at the level of a statement: the system is scalable. What separates a design that can absorb growth from one that merely claims to be whether specific expansion mechanics have been built into the original installation. A system that was not designed for expansion does not just require investment to grow; it often requires partial dismantling of what was installed. 

Look for a concrete expansion roadmap tied to your specific operation and growth projections: defined extension paths, infrastructure pre-installed to allow capacity additions without taking the system offline (such as building a larger AutoStore grid than required and simply not filling it completely with bins), and a growth model that references your actual volume and SKU trajectory. 

A useful follow-up to the main question is “How quickly could meaningful capacity be added, and what would that operationally require?” The answer should be specific enough that you could put it in a planning document, but please be patient with us integrators, it’s difficult to tell the future when it comes to scheduling pricing 1, 2, 5 years out, so what we give you will be the best we know at the time we’re asked. 

"We can add more later" is not an expansion plan. If a vendor cannot describe the specific design decisions made today that enable tomorrow's capacity additions, and the practical difference between adding capacity with the system running versus during a planned shutdown, the flexibility being described is a claim rather than an engineered outcome.

5. What is the critical path of my project timeline?

This question sits apart from the others; it is less about design quality and more about project risk. It belongs on this list because lead time surprises are one of the most common and most preventable causes of delayed go-lives in complex automation projects. Every project follows a throughline of the critical path, and what’s on that critical path changes depending on the project. 

A thorough answer identifies specific components, gives realistic procurement timelines, and has already built those windows, with a buffer, into the proposed project schedule. A vendor with a clear handle on this should be able to say which component(s) sit on the critical path, what the lead time looks like, and what the implication is for your target go-live date if procurement does not begin by a defined point. While procurement timelines are a key consideration, buyers should also consider the long-term support strategy behind the solution, including maintenance, optimization, and lifecycle services. That information should be in the proposal, not surfaced in a later conversation.

Generic project timelines that do not identify component-level lead times, or lead time disclosures that appear mid-project rather than at proposal stage, are both avoidable with preparation. A vendor who has delivered systems of this type knows exactly which components carry the longest procurement windows. If that information is absent from the proposal, ask for it explicitly before you sign, and factor the answer into your go-live planning.

That said – you could also be on the critical path. Key milestones like site access or WMS availability may be extending your project timeline beyond what any vendor can control. Durations that you own, such as UAT and post-go-live support, typically lie on the critical path too, and the vendor most focused on a successful go-live will be the one that actively collaborates with you on those milestones rather than treating them as your problem alone.

The best warehouse automation proposals are backed by a rigorous design process. By asking these five questions, buyers can better evaluate assumptions, system performance, scalability, and project risks before making a decision.

These questions stem from the same design disciplines used to develop successful automation solutions. For a closer look at the process behind building and validating a system design, read our warehouse automation solution design blog.