Time to Noce Scker — 1.1 minute The average me for a partner to noce an MOP order has arrived through the scker printer. Queue Capacity — arrival rate * 6.1 minutes + MOP orders in past X minutes This helps remove the steady state issues of the Queue- ing Toolpak 4.0. 6.1 minutes was the maximum possible me in system from our data collected. Window Constant — 1 minute for 1-2 items, 2 for 3+ Creates a window output by adding and subtracng the window constant to the max me in system output. Errors Missing data — use max service me over all sta- ons + average queue me (found from data col- lecon to be 0.78 minutes) Absolute minimum — one minute Absolute maximum — sum total staon service mes + constants (1.1 + 6.1 + 2) Developing Starbucks Mobile Order & Pay Algorithm Using Queueing Theory Tae-Eun Kwak, Tea Mijatovic, Amber Sun, Ryann Ulrich, Teanna Waltenburg Objecve Determine arrival rate based on historical data for each product type Arrival Rate: number of items ordered per half hour Process Historical Data Aggregaon Alternaves To address concerns with app maintenance and data storage, we created two models. One model contained the most detailed level of historical data, while the other aggregat- ed insignificant factors in order to condense data. These factor groupings included: Store: individual / volume segments Month: individual / quarterly Day of Week: individual / weekday and weekend Analysis of Aggregaon Alternaves We tested our null hypothesis that the aggregaon of factors has an insignificant impact, using seven random stores from each of the four volume segments, totaling 28 stores. Exploratory analysis showed what data segments followed the same paern, indicang that the variance between arrival rates was possibly insignificant and may be aggregated. These graphs revealed which factor aggregaons to explore using an analysis of variance. Results Our results showed that combinaons of months is the only factor aggregaon that is in- significant. Months were aggregated as shown below. This reduces our data by over 50 percent. January / February March / April / May June / July / August September / October November / December Objecve Determine data-driven service me for each product offered in the MOP feature Service me is the me it takes to prepare an item (excluding me in queue) Process Data Collecon 18 different days 10 different stores 5 Rapid Test Store (RTS) observaons 5 mocked store observaons in the Innovaon Lab 22 hours and 35 minutes 1156 data points collected Beverage Sequencing in Producon A partner’s ability to sequence beverages has a significant affect on an item’s total me in system. To incorporate this into our model, we looked at consecuve items where the second item’s start me was earlier than the first item’s compleon me. This overlap me was on average 55 seconds. We assumed that half of this me (27.5 seconds) would contrib- ute to the service me of each of the two items. We then sub- tracted 27.5 seconds from the service me for each product from our recorded data. Objecve To obtain the number of servers (partners) contribung to produc- on at each staon Process Staon Classificaon— possible partner responsibilies Espresso / Cold Beverage / Brewed / Hot Tea / Prepared Food / Bakery / Packaged Food Brewed / Hot Tea / Prepared Food / Bakery / Packaged Food Brewed / Hot Tea / Bakery / Packaged Food Espresso / Cold Beverage Prepared Food Cold Beverage Espresso Other (customer support, drive-thru register, drive-thru order, café point of sale, line concierge) Playbook Playbook is Starbucks’ staffing tool for labor deployment. Using store number, month, date, and me, the number of servers and store type are pulled from historical data. The playbook then uses these values to report what staons are being ulized. Flexed Servers As a part of playbook, all partners not only have a primary roune but also a secondary roune that allows them to flex into assisng another posion. If a staon is over-ulized, meaning arrival rate > service rate * number of servers, then the model moves flexible partners to that staon. A flexible partner is one that is categorized as “Other” and can therefore be easily moved from their primary roune into another role. As shown in Figure 2, the current model assumes all four partners are contribung to producon. While according to playbook staffing, only two contribute. Addionally, in this scenario one part- ner may flex in to support an over-ulized staon if necessary. Objecve To determine which model version is most accurate by using the innovaon lab, a mock store setup, to collect data as the basis of values for tesng Model Recommended The final model recommended aſter model tesng is model version 2, with the aggregated data. New Features Aggregated historical labor data assigns number of partners Uses playbook to: Find number of partners contribung to producon Allow partners to flex roles when needed Aggregated historical data determines arrival rate per unit type (IPLH) Separated queues for each partner’s staon responsibilies Uses service rates for individual items Considers order size and complexity Future Maintenance Update historical data (for new stores and inaccurate data) Input service mes for new items Future Suggesons Implement Andons for MOP arrivals (to reduce me to noce scker) My Starbucks Rewards Mobile Order & Pay (MOP) feature enables customers to bypass the line by placing an order shortly before ar- riving in store. Project Deliverables Deliver an algorithm that more accurately es- mates MOP order fill me, the me be- tween when an order is placed and complet- ed by considering: Order complexity Number of items per transacon Staffing levels Arrival rate Excel based algorithm Use Queuing Toolpak 4.0 Add-In Project Introducon Final Modificaons New Model Logic — Funconal Diagram Model Element 1: Service Time Model Element 2: Number of Servers Model Element 3: Arrival Rate Model Tesng Final Results Current State Opportunity Arrival rate based on transacons per la- bor hour (TPLH) Consider items per la- bor hour (IPLH) Assumes all partners are assisng in pro- ducon of orders Only consider part- ners contribung to the producon line Aggregates all prod- uct types into one queue Separate queues for various for product types Fails to adjust to ex- cepon cases (e.g. coffee travelers, large orders) Create a dynamic model that accounts for individual service mes Customer dissasfac- on due to unrealis- c order fill me Increase MOP accura- cy to create a posive customer experience Low accuracy These screenshots show the nondynamic nature of the current MOP algorithm. Figure 1: service mes (in minutes) measured for various product types Figure 3: Arrival rates per half-hour for months in the same season Figure 4: ANOVA tables for potenal insignificant aggregaons Figure 2: Green represents partners contribung to producon Figure 5: Average percent error of each model compared to actu- al me recorded from innovaon lab. Overall model 1 and 2 have 4 mes less error than the current model. *Model 1 is version with full data, model 2 is version with aggre- gated data Figure 6: Logic behind new excel-based model Figure 7: Relave percent accura- cy between current model (leſt) and new model version 2 (right). According to the model tesng, the current model output wait me interval captures the actual wait me 20% of the me, while the new model captures the actu- al wait me 65% of the me.