Time to Notice Sticker — 1.1 minute The average time for a partner to notice an MOP order has arrived through the sticker 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 time in system from our data collected.

Window Constant — 1 minute for 1-2 items, 2 for 3+ Creates a window output by adding and subtracting the window constant to the max time in system output.

Errors Missing data — use max service time over all sta-

tions + average queue time (found from data col-lection to be 0.78 minutes)

Absolute minimum — one minute Absolute maximum — sum total station service

times + 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

Objective Determine arrival rate based on historical data for each product type Arrival Rate: number of items ordered per half hour

Process

Historical Data Aggregation Alternatives 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 Aggregation Alternatives We tested our null hypothesis that the aggregation 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 pattern, indicating that the variance between arrival rates was possibly insignificant and may be aggregated.

These graphs revealed which factor aggregations to explore using an analysis of variance.

Results Our results showed that combinations of months is the only factor aggregation 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

Objective Determine data-driven service time for each product offered in the MOP feature Service time is the time it takes to prepare an item (excluding time in queue)

Process Data Collection

18 different days

10 different stores

5 Rapid Test Store (RTS) observations

5 mocked store observations in the Innovation Lab

22 hours and 35 minutes

1156 data points collected

Beverage Sequencing in Production

A partner’s ability to sequence beverages has a significant affect on an item’s total time in system. To incorporate this into our model, we looked at consecutive items where the second item’s start time was earlier than the first item’s completion time. This overlap time was on average 55 seconds.

We assumed that half of this time (27.5 seconds) would contrib-ute to the service time of each of the two items. We then sub-tracted 27.5 seconds from the service time for each product from our recorded data.

Objective To obtain the number of servers (partners) contributing to produc-tion at each station

Process

Station Classification— possible partner responsibilities 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 time, the number of servers and store type are pulled from historical data. The playbook then uses these values to report what stations are being utilized. Flexed Servers As a part of playbook, all partners not only have a primary routine but also a secondary routine that allows them to flex into assisting another position. If a station is over-utilized, meaning arrival rate > service rate * number of servers, then the model moves flexible partners to that station. A flexible partner is one that is categorized as “Other” and can therefore be easily moved from their primary routine into another role.

As shown in Figure 2, the current model assumes all four partners

are contributing to production. While according to playbook

staffing, only two contribute. Additionally, in this scenario one part-

ner may flex in to support an over-utilized station if necessary.

Objective To determine which model version is most accurate by using the innovation lab, a mock store setup, to collect data as the basis of values for testing

Model Recommended The final model recommended after model testing 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 contributing to production Allow partners to flex roles when needed

Aggregated historical data determines arrival rate per unit type (IPLH) Separated queues for each partner’s station responsibilities Uses service rates for individual items Considers order size and complexity

Future Maintenance Update historical data (for new stores and inaccurate data) Input service times for new items

Future Suggestions

Implement Andons for MOP arrivals (to reduce time to notice sticker)

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-timates MOP order fill time, the time be-tween when an order is placed and complet-ed by considering:

Order complexity Number of items per transaction Staffing levels Arrival rate Excel based algorithm

Use Queuing Toolpak 4.0 Add-In

Project Introduction Final Modifications

New Model Logic — Functional Diagram

Model Element 1: Service Time Model Element 2: Number of Servers Model Element 3: Arrival Rate

Model Testing

Final Results

Current State Opportunity

Arrival rate based on

transactions per la-

bor hour (TPLH)

Consider items per la-

bor hour (IPLH)

Assumes all partners

are assisting in pro-

duction of orders

Only consider part-

ners contributing to

the production line

Aggregates all prod-

uct types into one

queue

Separate queues for

various for product

types

Fails to adjust to ex-

ception cases (e.g.

coffee travelers, large

orders)

Create a dynamic

model that accounts

for individual service

times

Customer dissatisfac-

tion due to unrealis-

tic order fill time

Increase MOP accura-

cy to create a positive

customer experience

Low accuracy

These screenshots show the nondynamic

nature of the current MOP algorithm.

Figure 1: service times (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 potential insignificant aggregations

Figure 2: Green represents partners contributing to production Figure 5: Average percent error of each model compared to actu-al time recorded from innovation lab. Overall model 1 and 2 have 4 times 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: Relative percent accura-

cy between current model (left)

and new model version 2 (right).

According to the model testing,

the current model output wait

time interval captures the actual

wait time 20% of the time, while

the new model captures the actu-

al wait time 65% of the time.