Why your pizza tracker lies to you

I was hiking round the Indieweb recently and stumbled upon this post on Ruben Schade’s site. I recommend you read it as it’s a pretty good primer but my summary of the post is that Ruben and his partner ordered pizza from their local chain via an iOS application and then the estimated times on the app changed suddenly, prompting them to go to the store to pick it up:

We ordered our pizza, then saw the estimated cooking time as forty-five minutes. This seemed reasonable; Friday night would almost certainly be their busiest time, and we weren’t in a hurry. But then the estimated time flashed and changed to ten minutes.

Upon arriving at the store, the store was clearly very busy and the staff overworked with everyone waiting for their order having been lied to by the order tracking service / predicted cooking times:

We’d only managed to get there half an hour later, so the overworked staffer told me I only needed to wait a few minutes more. But it was evident that other people had seen the same time issue on their phones, and were demanding pizza that wasn’t ready yet.

Ruben uses his time to ponder the situation by asking questions of the application design, wondering what could have possibly causes the issue:

The few minutes waiting gave me some time to think about how we got to this situation. Was there an internal API the mobile application was polling every X amount of time, or was it a push notification? Was the local client making a best guess about the time to cook based on the time of day and week, then getting overridden by erroneous data? Could it have been as simple as one of the servers not having time in sync, or was there a race condition?

Ruben concludes by pondering the role of system design in supporting people doing on the ground work:

Computers, much like the economy, are built for people. Or at least, they’re supposed to be. The worst feelings I’ve had in this occupation are the thoughts that a system I’ve designed or helped build have worked against people in some failure scenario. I hope those pizza folks made it through the night okay.

Coming from a HCI background, I fully agree with Ruben’s concerns around building systems that affect people; particularly workers and the accomplishment of “interactional work” within a setting. Strangely enough, I also come from a Pizza-making background and this is the subject of my contribution to this discourse.

From 2008 to 2014 I worked as an in-store staff member (ie not a driver or manager) in several branches of Domino’s Pizza in the North East of England. I started off in my hometown branch of Cramlington in 2008, worked my way through 6th form, and then ended up helping open up the Heaton branch in Newcastle upon Tyne when I moved there for uni. Owing to the fact that all the stores in the North East were operated under a single franchise I also spent some time in other stores in the area. I stayed until spring 2014 where I left to ensure I focused on my final year of undergraduate studies (in Computing Science). In 2014, I also began my research career in Digital Civics and HCI which lead to my PhD where I employed ethnographic methods to understand work practices. The takeaway from this (pun intended) is that I’m surprisingly well-placed to provide insight into what may have happened to Ruben in Australia.

What follows is adapted from an email I sent Ruben to respond to his post. It takes the format of a relatively thick description of the setting’s (Domino’s pizza) interactional work to organise orders and produce pizzas with support from a digital system.

Trackers, Timers, and Managers: A tale of work practice and digital systems

From 2008 to 2014 there were three ways we could receive an order at Domino’s: walk-in customers at the front desk; a phone order (most common); and a web order. In 2010–2011ish Domino’s got a new system called “Pulse” installed. It updated a few things like how orders were taken and entered into the system via the phone or the counter, and updated some of the graphics (it was a DOS programme previously!), but the core interaction remained the same throughout. So this thick description applies to both systems I worked with.

Regardless of how the order was taken it was assigned an id and entered the system to be shown on a series of screens dotted around the store which displayed various aspects of the order depending on what station you (a worker) are working at. The person slapping out the dough would see the size, crust-type, and sauce while those on the makeline would see these same details more compactly (to support recognising the pie as it came along) as well as cheese-levels, and toppings. Toppings had various codes e.g. Jalapeños were J, Sweetcorn was N, Beef was B, Bacon was K etc. Off-the-menu pizzas had, generally, two letter codes which were displayed in brackets. Any modifications to an off-the-menu pizza were presented in a sequence after the two-letter code. Some examples:

• 13R (BQ) -G, 2K would translate to Large (13.5 inch) Regular Crust Texas BBQ pizza, no green peppers, double bacon
• 11X (VS) -X Bq -F J would translate to Medium (11.5 inch) Thin Crust Veggie Supreme, minus pizza sauce, substitute BBQ sauce, no fresh tomatoes, add jalapeños (Coincidentally this is basically what I get now if I ever order)
• 13R X 2C W N M would translate as Large Regular Crust pizza with double cheese, White Chicken, Sweetcorn, and Mushroom

Makeline staff would also see things like side orders, as these were stored underneath the makeline in refrigerated bins. That’s the context. The interesting bit, the part that’s key to this setting, is that on every screen all staff would also see a timer.

All orders are timed. If an order was scheduled for later it doesn’t appear until the system calculates that it’s due to make, but once it appears on those screens a timer starts counting up from 00:00 in minutes and seconds. The goal was to get all pizzas into the oven before the two-minute mark (02:00), or at least try to maintain a two-minute average. These orders came down from on-high from Domino’s head office (I’m unsure if an international or UK-specific mandate) to the franchise / area managers, store managers, and eventually us lowly proles on the makeline.

The system was informed of a pizza entering the oven by the makeline staff responsible for a pizza (or a delegate) highlighting it on the screen using a keyboard (perhaps touchscreens are used now!) and “clocking it off”. This was done simply by hitting the Enter (Return) key when the pizza was highlighted on the screen. This clears the pizza from the screen, but it also has a few interesting effects in the system as it pertains to what the customer sees if they’re monitoring the order via the web. The oven was a conveyor belt-type oven which, in our store, was set to cook pizzas perfectly within 7 minutes. After these 7 minutes were up, the pizza appeared magically on another screen for the drivers. This driver-screen also had a timer indicating how long the pizza had been out of the oven or otherwise waiting to be picked up. I’m not overly familiar with this screen but I know that the time counted down, unlike the makeline screens, and the goal was to pick it up before the timer hit zero. When a driver returned they were supposed to sign in, get assigned a delivery, find it on the hot rack, and take it out for delivery. All of these stages are tracked by the system online, and relayed to the viewer. If the pizza is marked as for collection, that’s the end of its journey across the displays but the system relays that it’s ready to the customer if they’ve ordered it via the web.

The delivery time predictions and “status” of the pizza were (are?) based on the system’s knowledge of that order alone and didn’t take into account the overall status of the system ie how many orders there were and staffing levels. As far as the web app / server was concerned a pizza took 2 minutes to make, 7 minutes to cook, then it was waiting for a driver or a customer to to come in. As the pizza is clocked off the makeline, the system informs the Domino’s website that it’s in the oven. When the system thinks that the pizza has finished cooking and is waiting for delivery it will update to say so (I think Domino’s says it’s under “Quality control”) and then when it’s assigned for a driver it thinks it’s “Out for delivery” (or equivalent).

Now all this works great when the human components of the system behave as the system designers were lead to believe. It’s during rushes / busy periods that the managers misbehave and it gets fun.

As noted, store managers and staff are “incentivised” (pressurised or, as I saw in some cases, bullied) to maintain a 2-minutes-or-faster average for orders. This is often impossible during rush times and the average is going to creep up. Usually the store is trying to operate on the bare minimum numbers of staff, to maximise profits for the franchisee and the Head Office (capitalism is so fun); so people are usually doing several things at once. Managers will often stand by the oven and yell out orders for makeline staff to memorise quickly and then clock them off en masse before the 2 minute mark is up (or as close to it as they can get). This also happens on the other end with the drivers screen. After prematurely clocking orders off of the makeline the manager will then move to the driver screen to await them appearing on there. During heavy rushes the orders will be clocked off in batches, so they often yo-yo between the two screens. During lighter rushes the manager may help out on makeline for the time it takes for the system to catch up while it thinks the pizzas are in the oven, and display them. When the orders do appear on the driver screen, the manager clocks these out as well by overriding the driver logins and assigning orders to drivers.

Having spoken to colleagues working at other branches or other franchises/chains (via our Union), I can confirm that this practice was common across the sector where these conditions were present. For clarity, these conditions seemed to be: pressure to “make the numbers right” for a franchise boss or head office; and the presence of a digital order-tracking system designed to monitor time/efficiency in some way.

The effect that this has to those relying on the system updates to inform them of the status of the pizza is that the system is now not representative of the status of the order at all. Whether this manifests as an order-tracker or a predicted delivery time; both representations are totally thrown askew when the system is unaware of how it’s being manipulated to appease bosses.

Conclusions

I have no profound conclusions from this. This is a public response to a blog post I found interesting and one of the few that I thought I could legitimately contribute to a discourse on. If any system designers, HCI researchers, ethnographers, or union officials want to discuss my experiences at Domino’s please get in touch! You’ve got my permission to use the thick description for your research unless you’re a for-profit research company.