Product Features & Development Efforts

The Automated Storage and Retrieval System (ASRS) operates differently from traditional warehouse processes. In a traditional system, team members receive products, stock items, pick online orders, and manage replenishment manually. The ASRS, however, uses robots to manage these tasks automatically. After team members induct items into the system, robots handle stowing, picking, and replenishment operations before transferring products to team members for final packaging. Due to this automated process and unique storage method, we developed an automated replenishment system that triggers orders based on system data without human intervention.

Ryan defined requirements spanning over 15 systems and led the program across five engineering teams to design, implement, test, and launch the software in December 2024.  The components of the requirements are summarized below

Eligibility Service

To identify items for automation, we built a user interface powered by DynamoDB and APIs to verify eligibility. Users log into the web UI to designate items for automated purchasing in ordering systems.

Ordering Inputs & ROQ Calculation

We implemented a mechanism to upload unique MFC-specific Target Inventory Positions and vendor schedules, accounting for distinct ordering days, delivery days, and vendor lead times. For eligible items, we ran a separate channel specific Re-Order Quantity calculation via backend Lambdas, using only online demand.

Capacity Guardrails

We built a direct integration with the 3P equipment to retrieve real-time capacity data, allocate capacity between Whole Foods and Fresh, and apply logic to truncate items after ROQ generation if they exceeded the machine's capacity.

PO Identifiers for Suppliers, Inventory, and Accounting Purposes

We created configurable identifiers that enabled MFC items to be placed on separate POs, included account # identifiers for suppliers to ingest via EDI-850 messages and treat this product differently in their fulfillment system to ship products on separate pallets and trucks, and ensured purchase orders were mapped to the correct cost accounts for P&L and balance sheet reporting. These identifiers were propagated through all downstream systems for receipt processing and integrated into existing reporting.

 Receiving Workflows

We introduced new receiving messages within the Store Receive Tool a mobile application on a Honeywell CT60 scanner to clearly indicate whether MFC products were part of a 3P or DC shipment, enabling team members to route them to back-of-house equipment instead of the sales floor.

Perpetual Inventory

Upon receipt, we established processes to track inventory events at key stages, including receiving, induction into equipment, sales, and spoilage for real time inventory tracking. Inventory was assigned to a distinct virtual bin to indicate whether it was designated for or already inside the equipment.

Technical Challenges

The hardest technical part of launching the program was the capacity guardrails process. WFM buying systems did not have a concept of capacity incorporated in re-ordering calculations. For MFC, we defined requirements for controls for WFM and Amazon automated ordering systems to constrain ordering to what the automation hardware can physically hold, known as Capacity Guardrails. Capacity can be seen as three separate components 1) A component to provide visibility to what space is currently available within the machine 2) A component to split the machine capacity between WFM, Fresh, and Core space 3) a way to prioritize the order in which the item and its quantity is applied to available capacity and truncation of items that will not fit in the machine.

Component 1

The machine was organized in lanes of trays and each lane had three different dimensions.  The size of the lane width which varied in different 13 different sizes to fit all types of products, the temperature rating they could be stored in the lane ambient, chilled, or frozen product, and the FDA classification which was five separate categories of type of product such as raw meat or ready to eat.  We decided to name the combination of the 3 dimensions “bucket type”.  This resulted in over 200 bucket types.

Component 2

Once we knew the bucket type combinations and the quantity of lanes available per bucket type, we had to allocate the total buckets across Whole Foods, Fresh, and Core Product.  We decided to let the business decide two inputs which total our systems how to divvy this up.  One input was capacity %, this had to total to 100% and spread out across the three business units so that we wouldn’t consume into each other’s capacity to allow for the proper assortment of product.  Utilization factor was applied after the split and used to add a buffer if input from the machine we a little off to reduce the risk in over-ordering.  One key complexity in why we had to approach it this way is because ordering tools and backend services were different for Whole Foods and Fresh, in other words different tech stacks.  If we didn’t have different tech stacks we wouldn’t have had to split the capacity across business units, because we would be using one system. However, this was a technical limitation, so both systems had to know the capacity of the machine and use that in separate calculations and logic

Component 3

The final component of capacity guardrails involved using Whole Foods’ Lane allocation by bucket type to incrementally process items and their order quantities. Each item was assigned to a specific bucket type, with a maximum unit capacity per bucket. Additionally, we applied an item importance factor to prioritize higher-importance items before processing lower-priority ones.

As items were processed and buckets filled, any items that exceeded capacity were truncated and logged in a DynamoDB database to track unmet demand. Items that fit within the system were processed into a purchase order and transmitted to the supplier via EDI-850. The supplier then fulfilled the order, loaded the product onto a separate truck, and receiving tools facilitated the three-way match between the purchase order, receipt, and E-invoice. Upon receipt, the product was added to a back-of-house virtual bin, ensuring accurate tracking of equipment-specific inventory. Product was then brought to induct to be loaded in the equipment

Timeline Challenges
The Grocery Supply Chain (GSC) tech team was engaged late to support a 2024 launch. I wrote the Business Requirements Document (BRD) on April 19, just two weeks after being assigned the program. Our workback plan set a tech-ready date of October 25, allowing only five months for development and one month for testing and UAT, all while managing several other high-priority, in-flight features critical to the business. Given the number of systems involved and our existing headcount, I quickly recognized that we had two options: reduce scope and deprioritize certain requirements or request additional resources. Since resource allocation is often a lengthy process, I opted to proceed by cutting scope.

At a high level, the project required us to automatically generate reorder quantities, process purchase orders with unique identifiers, ensure proper receipt of products into the correct virtual bin, enable system-wide awareness of the MFC concept for transactional processing, and ensure no disruption to retail items or front-of-house store processes. To meet the October 25 deadline, we descoped the following:

• Capacity guardrails were postponed until ramp-up in January, as the gradual rollout allowed flexibility.

• Automation for Produce items was deprioritized since these items comprised only 15% of total machine-serviced volume.

• Low-volume edge cases (e.g., transformed items, DC pre-order items) were deprioritized, as they accounted for only 5% of total online retail items.

These changes were presented to key business stakeholders through a tradeoff document, which included VPs from Retail Operations, DC Operations, In-Stock, and E-Commerce—totaling approximately 50 stakeholders across five VPs. The document evaluated all potential options, ultimately recommending the descoping of the outlined requirements while treating them as fast follows. It also detailed other work that would need to be put on hold until the MFC implementation was completed. The business aligned with our recommendations and agreed to prioritize MFC over other planned 2024 roadmap initiatives. As a result, we met our tech-ready date of October 25, delivered capacity guardrails by the end of January, and are now working through the backlog for 2025.

Other challenges within this project were making all our supply chain systems aware of if the item was to go into the machine, input quality from catalog data authorities such as item vendor-mapping, and working though all the edge cases that could occurs.  If processes are fully automated, inputs need to be accurate so the right item, gets order from the right vendor, with the right quantity, as there is no human intervention.

We successfully deployed the equipment and automated supply chain components, enabling a select group of customers to order Fresh and Whole Foods products in a single checkout, all fulfilled via robotic automation. The rollout continues in 2025 as we scale to over 21,000 items being stored and automatically ordered through the system. Once fully implemented, the ASRS equipment will support $10M in online revenue while reducing fulfillment costs by 40%, generating $3.5M in annual savings.