Starbucks introduced their now much-used app in December 2014 in Portland. As they rolled it out to the rest of the country it has seen increasing adoption. In August Starbucks reported that 20% of their orders were paid via mobile payments and two thirds of those were placed through Mobile Order and Pay. The app has definitely been a hit and the adoption has probably brought a lot of customers back to being regulars(including myself).
The mobile order takes the waiting in line aspect of the Starbucks store out of the equation and knowing that my order will take about 10 minutes to be ready, helps me time my walk from the office to the local Starbucks as I wrap up the minor email-checking type activities. There is the added bonus of every 12 drink orders giving me a free reward drink when using the app. It is a great technology solution to a non-technical problem and Starbucks is explicitly and implicitly encouraging adoption of the app among its clients. Apart from the reward that I just mentioned, Starbucks also asked the baristas to treat mobile orders as expedites. These orders jump ahead of the drinks that have not yet been started, which means that everyone in the store that hasn't placed an order has dropped a spot back in line.
In the world of flow, expedites are almost always bad. They disrupt the system and cause delays to every other work item in progress. There are multiple repercussions to giving expedite requests priority, the major one being that you eventually get flooded with nothing but expedite requests. My assumption is that this is the exact effect that Starbucks was counting on. Whether intentionally(most likely) or not, Starbucks is counting on the ratio of the online orders to grow. There is a direct benefit to doing this for them. It is taking the entire ordering process out of the hands of the baristas, and outsourcing it to the customers. The baristas can now spend more time making the drinks rather than taking the orders.
In essence Starbucks is encouraging the exact opposite of the behaviour we coach teams. We tell teams expedites lead to unpredictable systems. Starbucks is trying to use expedites to add capacity to the system by outsourcing the ordering system. This seems to be leading to a more stable system. Lets run a quick simulation on a few scenarios here. The following assumptions stand for all simulations -
Scenario 1 - No Mobile Orders, 1 employee taking orders, 1 employee making drinks.
Scenario 2 - 15% Mobile Orders, 1 employee taking orders, 1 employee making drinks.
Scenario 3 - No Mobile Orders, 1 employee taking orders, 2 employees making drinks.
The advantages of scenario 2 are numerous. The extension of the scenario, where 80% of the orders are mobile orders and the employee taking the orders spends more time making drinks than taking orders, actually come out similar to the scenario 3 results. In other words, by getting a good majority of their users to use the mobile app, Starbucks can have the employees do mostly drink making rather than order taking and double throughput(no. of orders satisfied) per hour. The simulation of this scenario showed a 4 minute net "cycle time" as well. Most of which would probably be spent by the user walking to the store rather than queuing up in the store.
These are results based on simulations and I would corroborate them with personal experience as well. I knew that the expedited nature(jumping the in-store line) of the app was working in my favour when I used it. I recently switched my phone and for the past week have not used the app and have found that the in-store line is taking less time that I remember as well. There could be multiple factors to this, but I am sure the adoption of the mobile app is a major contributor.
I am not sure if folks at Starbucks ran similar simulations before rolling out the app(I have a feeling they did), but they are definitely altering the flow of customer orders. The Starbucks app is not just an easy way to pay but a shift in user behaviour. The shift, on the surface, seems to violate some principals that we espouse while teaching flow, especially around expedites. The fact though is, these are not expedites, but reallocation of the work into the hands of the user from the hands of the employees.
The mobile order takes the waiting in line aspect of the Starbucks store out of the equation and knowing that my order will take about 10 minutes to be ready, helps me time my walk from the office to the local Starbucks as I wrap up the minor email-checking type activities. There is the added bonus of every 12 drink orders giving me a free reward drink when using the app. It is a great technology solution to a non-technical problem and Starbucks is explicitly and implicitly encouraging adoption of the app among its clients. Apart from the reward that I just mentioned, Starbucks also asked the baristas to treat mobile orders as expedites. These orders jump ahead of the drinks that have not yet been started, which means that everyone in the store that hasn't placed an order has dropped a spot back in line.
In the world of flow, expedites are almost always bad. They disrupt the system and cause delays to every other work item in progress. There are multiple repercussions to giving expedite requests priority, the major one being that you eventually get flooded with nothing but expedite requests. My assumption is that this is the exact effect that Starbucks was counting on. Whether intentionally(most likely) or not, Starbucks is counting on the ratio of the online orders to grow. There is a direct benefit to doing this for them. It is taking the entire ordering process out of the hands of the baristas, and outsourcing it to the customers. The baristas can now spend more time making the drinks rather than taking the orders.
In essence Starbucks is encouraging the exact opposite of the behaviour we coach teams. We tell teams expedites lead to unpredictable systems. Starbucks is trying to use expedites to add capacity to the system by outsourcing the ordering system. This seems to be leading to a more stable system. Lets run a quick simulation on a few scenarios here. The following assumptions stand for all simulations -
- There are about 40 orders placed per hour..
- It takes 30 seconds to take an order and process payment.
- It takes 2 minutes to prepare the drinks for an order.
- The simulation is run for 60 minutes.
Scenario 1 - No Mobile Orders, 1 employee taking orders, 1 employee making drinks.
This is the base simulation in a world where there are no Mobile orders. All payments and orders are done in person. The simulation saw 42 customers coming in and 15 of those orders successfully getting processed. Which means of all the customers that came in during the hour, less than half were successfully served at the end of the 60 minutes. The 15 customers spent an average of 1343 seconds, or about 22 minutes getting in and out of Starbucks. Based on our assumptions, that is 18 to 19 minutes more than the active ordering and drink making time.
Scenario 2 - 15% Mobile Orders, 1 employee taking orders, 1 employee making drinks.
This is similar to the numbers reported by Starbucks, in terms of percentage of orders coming in from mobile devices. With similar setup for arrival rates of orders, 26 customers had their drinks at the end of the hour. These customers spent an average of 490 seconds or close to 8 minutes getting in and out of Starbucks which is about 5 and a half minutes more than the active time.
Scenario 3 - No Mobile Orders, 1 employee taking orders, 2 employees making drinks.
What if we added capacity to the system in the form of an employee making drinks. With similar setup for arrival rates of orders, 34 customers had their drinks at the end of the hour. These customers spent an average of 326 seconds or close to 5 and a half minutes getting in and out of Starbucks which is about 3 minutes more than the active time.
Scenario 1
|
Scenario 2
|
Scenario 3
|
|
| Total Employees | 2 | 2 | 3 |
| Orders Completed | 15 | 26 | 34 |
| Average Order Cycle Time | 22 mins | 8 mins | 5.5 mins |
| Average Wait Time | 18.5 mins | 5.5 mins | 3 mins |
The advantages of scenario 2 are numerous. The extension of the scenario, where 80% of the orders are mobile orders and the employee taking the orders spends more time making drinks than taking orders, actually come out similar to the scenario 3 results. In other words, by getting a good majority of their users to use the mobile app, Starbucks can have the employees do mostly drink making rather than order taking and double throughput(no. of orders satisfied) per hour. The simulation of this scenario showed a 4 minute net "cycle time" as well. Most of which would probably be spent by the user walking to the store rather than queuing up in the store.
These are results based on simulations and I would corroborate them with personal experience as well. I knew that the expedited nature(jumping the in-store line) of the app was working in my favour when I used it. I recently switched my phone and for the past week have not used the app and have found that the in-store line is taking less time that I remember as well. There could be multiple factors to this, but I am sure the adoption of the mobile app is a major contributor.
I am not sure if folks at Starbucks ran similar simulations before rolling out the app(I have a feeling they did), but they are definitely altering the flow of customer orders. The Starbucks app is not just an easy way to pay but a shift in user behaviour. The shift, on the surface, seems to violate some principals that we espouse while teaching flow, especially around expedites. The fact though is, these are not expedites, but reallocation of the work into the hands of the user from the hands of the employees.
No comments:
Post a Comment