Inside a resilient ASRS solution design process
A warehouse automation project rarely fails at the equipment level. It fails at the design table, months earlier, when a bottleneck goes unnoticed, a single component becomes a single point of failure, or a solution gets built around assumptions no one wrote down. By the time a system is live, those decisions are poured into concrete and steel.
That is why resilience has become a defining theme in warehouse automation throughout 2026, alongside AI adoption and the ongoing talent gap facing supply chain teams. But resilience is not a feature added at the end of a project. It has to be engineered into the ASRS from the earliest design conversations.
Inside the ASRS solution design process: from client idea to signed contract
The design process rarely starts when a client picks up the phone. It starts earlier, when an existing system begins showing signs of strain: it stops coping during critical or peak periods, or a new business idea simply outgrows what the current operation can support. That friction is usually what prompts the first call.
From there, a sales phase begins. The client's team and Swisslog's design team have a series of discussions to capture requirements, collect operational data, and mature the concept.
That process runs until a solution is developed to a level both sides are confident in, at which point a contract is signed.
Engineering, implementation and the never-ending relationship
Signing a contract is not the finish line. The project then moves into an engineering phase, where every critical point of the solution gets detailed. Design changes at this stage are typically fine-tuning rather than a rework, since the requirements have already been validated. Implementation follows, and can run anywhere from one to two years depending on scale.
PRODUCT SPOTLIGHT - Software's role in resilience
Hardware-level design decisions, avoiding single points of failure and decoupling zones, sit alongside software resilience. Swisslog's SynQ software includes functions specifically built to compensate for failures elsewhere in the system, so the two layers of resilience, physical and digital, are designed together rather than bolted on separately.
Go-live introduces a genuinely new way of working, and that brings its own adjustment period: clients have to adapt to the new system, but the new system also surfaces new ideas about how the operation could run. From there, the relationship moves into continuous improvement and future expansion, a pattern visible across many of Swisslog's long-running case studies. In practice, the design of a solution does not have a fixed endpoint. It continues for as long as the partnership does.
Pressure-testing before handover: the 'break the system' session
Before a design ever reaches a client, Swisslog puts it through a structured pressure test the team calls, simply, breaking the system. It happens on practically every project: after weeks or months of work, sometimes through two or more rounds of revisions with the client, the project team invites colleagues from across Swisslog's global organization to deliberately try to find holes in what they have built.
We have a session where people from our global organization try to break the system: what if there's a problem here and I need this product right now? It's very fruitful, because it lets us see weaknesses that a team embedded in the solution sometimes misses.
The format is deliberately adversarial. Reviewers invent failure scenarios on the spot: what happens if this component goes down during a peak period, or if a customer needs a product immediately and the usual pathway is blocked. A team that has lived inside a design for months develops blind spots; reviewers seeing it for the first time do not.
TIP — What to ask a warehouse automation vendor
Before signing off on a design, ask whether the vendor runs a structured failure-testing session with reviewers outside the immediate project team. A team close to a solution for months can miss weaknesses that fresh eyes catch quickly, and that gap is far cheaper to close on paper than after installation.
Experienced design teams are not constantly surprised by their own break-the-system sessions. Most failure scenarios have already been countered through prior deployments, thanks to institutional experience in exactly where a design tends to be weak. But when something genuinely new does surface, it becomes fuel for the next project rather than a problem to bury quietly. That combination, a repeatable process paired with a genuine appetite to be proven wrong, is what keeps the exercise on the agenda for every project rather than treating it as a one-off checkpoint.
Engineering resilience into ASRS: eliminating single points of failure
Resilience has to be at the core of solution design. Every solution needs to be resilient. We try to make sure the solution doesn't have a single point of failure, that there are no bottlenecks, and we decouple areas so that one affected zone won't interfere with another.
In practice, that means structuring an ASRS so that a failure in one zone stays contained rather than cascading through the rest of the facility. This idea, known more broadly in engineering as a single point of failure, is deliberately designed out from the start rather than patched in later.
These are not abstract principles. A single point of failure in an ASRS can turn a localized issue, a jammed conveyor or a stalled shuttle, into a shutdown across an entire facility. Designing zones so they can operate independently, even if one section needs maintenance or is recovering from a fault, is what keeps a facility's overall uptime high rather than tied to its weakest link.
Standardized products, custom ASRS solutions: requirements before cost
Resilience also depends on not reinventing the wheel on every project. Swisslog draws on a large portfolio of proven, configurable products, from AutoStore cube storage to pallet and case shuttle systems, refined and standardized over time, and combines them into a solution that is unique to each customer's problem. That approach mirrors a broader industry shift: a recent MHI and Deloitte survey found robotics and automation among the technology categories supply chain leaders are investing in most heavily, even though the specific configuration of any two automated warehouses rarely looks the same. Teams are not starting from a blank slate on the hardware side, even though the resulting solution is one of a kind. When a genuinely new product need emerges from a specific project, it gets developed and folded into the standard portfolio for future use, rather than built as a one-off.
That same discipline shows up in how cost enters the conversation. Design starts with requirements only: identifying the must-haves the solution absolutely has to deliver, and the nice-to-haves that matter less. Cost is deliberately left out of this first phase. Once a solution meeting those validated requirements exists, it moves into a second phase where cost becomes central, and the team looks for ways to make the design leaner without eroding what was already validated with the client.
| Stage | Phase 1: requirements | Phase 2-3: cost optimization |
|---|---|---|
| Focus | Solution must-haves and nice-to-haves | Efficiency without losing requirements |
| Key question | Does this meet the client's goals? | How do we deliver this for less? |
| Cost in the equation? | Deliberately excluded | Central, but validated baseline stays fixed |
| Output | Validated solution concept | Lean, resilience-tested final design |
Structuring the process this way keeps budget conversations honest. A client sees what a solution meeting their full requirements actually costs, and can then decide, with real information, whether to hold the line or trade down to a leaner phase. It also lines up with where the industry is putting its money: nearly half of supply chain leaders surveyed by MHI said they plan to purchase new automation equipment, from AGVs to ASRS, in the year ahead, which is exactly the kind of standardized, catalog technology this staged approach is designed to deploy efficiently.
Designing with incomplete data, and where ASRS design is headed next
Clean, complete data at the start of a project is the exception more often than the rule, though the picture has improved considerably over the past five years. Where gaps exist, Swisslog gives the client a list of must-have and nice-to-have data points and works with them to fill it in. Where numbers genuinely are not available, the team makes assumptions, always stated explicitly and agreed with the client rather than made silently. The client, not the vendor, has the final say on which assumptions to run with. A first design iteration then often prompts the client to surface more information as they see the process take shape.
Looking further out, the pace of change in this field keeps accelerating. Pallet and case shuttles did not exist 30 years ago; they arrived and changed the landscape. Autonomous mobile robots followed, lowering the entry point for automation for many operators. Amazon's scale then pushed the wider industry toward faster cost optimization. Humanoid robots and AI are the current open question, and MHI's outlook for 2026 pointed toward this shift, with automation and AI adoption reshaping how supply chains build in resilience and operational intelligence. Nobody in the industry claims to know exactly what comes next, and that uncertainty is treated as the interesting part of the job rather than a risk to manage around.
ASRS solution design: where to go from here
Resilience, uptime and the ability to scale are not properties you can retrofit onto an automated warehouse after the fact. They come from decisions made during solution design and system engineering: how zones are decoupled, how a design gets pressure-tested before handover, and how honestly requirements are separated from cost. Operators evaluating a warehouse automation partner in Australia, New Zealand or any other market are better served asking about that process than about the equipment specification sheet alone.
To see how this design approach applies to storage and retrieval specifically, explore Swisslog's automated storage and retrieval systems. For answers to more common questions about getting started, Swisslog's warehouse automation FAQ covers everything from phased implementation to compliance.
People also ask
What does the solution design phase of a warehouse automation project involve?
The solution design phase covers requirements gathering, data collection and iterative concept development between the client and the automation provider, typically ending with a signed contract. It is followed by a system engineering phase that details and fine-tunes the design, then implementation, which can take one to two years depending on project scale.
How long does it take to design and implement an ASRS solution?
Timelines vary by project, but the pattern is consistent: a sales phase to gather requirements and mature the concept, an engineering phase to fine-tune the details, and an implementation phase that typically runs one to two years depending on scale. Many projects then continue indefinitely through ongoing improvement and expansion as the operation grows.
How do ASRS providers test a design before installation?
Many providers run a structured pressure test, sometimes called a break the system session, where reviewers outside the core project team deliberately invent failure scenarios to find weaknesses. This surfaces blind spots that a team embedded in a design for months can otherwise miss, before the system reaches the client.
How is cost balanced against requirements when designing an ASRS solution?
Requirements are typically validated first, with cost deliberately excluded from the initial design phase. Once a solution meeting the client's must-have and nice-to-have requirements is confirmed, a second phase introduces cost and looks for efficiencies without eroding the validated requirement baseline.
How is an ASRS solution designed when a customer's data is incomplete?
When complete data is not available, the provider and client agree on a list of must-have and nice-to-have data points, then make explicit, jointly agreed assumptions to fill any gaps. The client retains final say over which assumptions are used, and an initial design iteration often helps surface additional information as the process progresses.
