Nosh is a patchwork of technical systems held together by human intervention. Nosh relies upon multiple disparate pieces of software to operate. Breakdowns in their patchwork technology stack are commonplace and must be repaired through human intervention. This human intervention is what compels stakeholders to participate in Nosh. However, human intervention requires deep local knowledge, takes time, and costs money. In this section, we outline the contours of Nosh’s technology stack and identify how stakeholders engage in repair work to address gaps and breakdowns, paying special attention to the role of platform administrators. We summarize what technologies each stakeholder interacts with and how they engage in repair work in Table
4.
6.1 Stakeholders struggle with Nosh’s patchwork of technical systems
Restauranteurs we interviewed complained that Nosh’s ordering system was clunky and required them to operate a separate order aggregation system and a tablet dedicated solely to Nosh’s orders. Mainstream food delivery platforms can integrate directly with most restaurants’ point-of-sale software and order aggregation systems, reducing friction in the system. Couriers complained that as a result of the complicated order aggregation system, restaurants often forgot important steps such as starting a countdown timer that couriers relied on to estimate when the order would be ready for pickup:
“it’s hard you know because everybody wants to point fingers, so it’s hard... to say, like, if they’re actually just, like, not able to understand how the app works, or they just didn’t start the order because they, you know, were lazy or busy or whatever. And they’re just like oh like, it wasn’t actually my fault, like the App is bad .” (D3, emphasis added)
Nosh’s complex technical interface and the inability to integrate it into existing infrastructure resulted in frequent breakdowns that impacted restauranteurs and couriers. Despite their familiarity with the system, platform administrators also articulated difficulty navigating the patchwork technical stack Nosh used.
During the course of a shift, platform administrators said they used, on average, four different platforms simultaneously. One platform administrator describes their shift as follows:
“... it’s a nightmare, we need to... streamline it because my computer just wants to it’s like about to start on fire, because I’ve got so many things running yeah so so slow, because I always have a million things open”(P3)
Jumping back and forth between platforms introduced inefficiencies and confusion in their work. Administrators would actively monitor WhenIwork to manage their fleet of couriers, triage customer service requests that came through ZenDesk, answer phone calls from restauranteurs, and coordinate refunds with payroll administrators via Slack. One administrator who oversaw operations at one of the hubs said they wished they could purchase software from Salesforce to streamline their workflow better, but it was prohibitively expensive.
Administrators acted as the buffer between stakeholders and Nosh’s technical infrastructure. When couriers disagreed with delivery instructions or assigned tasks, administrators would be alerted to the situation. For example, couriers recounted times when they were assigned a delivery for a restaurant that was far away towards the end of their shift. In this situation, since the couriers wanted to stop working when their shift ended, they contacted a platform administrator via chat and asked them to manually re-assign the order to someone else. Another example of human intervention by platform administrators occurs when restaurants ask them for the same detailed profit and loss reports they received from mainstream platforms. Because the DataDreamers software Nosh used did not support report generation, backend administrators would manually compile these. The limitations of Nosh’s technical infrastructure pushed stakeholders to engage in additional invisible labor to make up for shortcomings:
“The point I’m trying to make is the platform that we currently use is very limited. So there are many things that we can’t access, although the data is there, so we have to kind of find alternatives in order for us to create visual reports so that we can analyze the data, send it to our couriers and our restauranteurs, etc.” (P2)
Repair work and invisible labor were essential to making Nosh function properly. At all points in the food delivery process, the technical infrastructure of Nosh was subject to breakdowns. Stakeholders throughout the food delivery process intervened when the technical systems broke down, relying on human intervention to rectify the situation.
6.2 Human intervention was necessary to overcome breakdowns
Human operators in Nosh overcame breakdowns through invisible but essential labor. This labor is what the other stakeholders like because they want to interact with people and not machines when things go wrong. However, human intervention requires deep local knowledge and money, and takes time.
Human mediation plays a critical role in Nosh’s operational logic. Platform administrators regularly intervene during the course of food delivery to provide emotional and informational support to restauranteurs, couriers, and customers. As restauranteurs started re-opening and became busier with dine-in traffic, couriers often had to wait long periods to pick up their orders. This wait time was compounded by the possibility that restauranteurs did not use the Nosh interface correctly to time the order preparation. To defuse potentially tense situations between restauranteurs and couriers, Nosh administrators
“actually created these templates to send to our couriers that are acting out, getting frustrated with restauranteurs... say[ing] hey we know you’re frustrated, but we’re all a team here let’s work together, here are some ways that you can you know, deal with those types of situations, you can walk away, you can contact us, you can you know, take a deep breath.” (P3).
These interactions aimed to show couriers that Nosh stood behind them and wanted to support their well-being on the job. Couriers appreciated these interactions, often explicitly calling out the unique degree of the personal connection they had with administrators during our interviews.
A healthy skepticism of the capabilities of the technology used further motivated stakeholders to engage in and rely upon human mediation. Couriers developed rich mental models of what food delivery looked like from the restaurant perspective and anticipated where breakdowns might occur, then worked to address those failure points before problems arose. For example, couriers knew that the restaurant-facing UI was complicated and often led to mistakes with timing so they would call up restauranteurs directly and inquire about order status:
“So I would literally call every single time every restaurant like ‘I have this order. Here’s the order number/ here’s the name. Anything else you need? Can you let me know if this food has been received by you and do you have any idea how long it’s going to take?’. And obviously, you know, whoever’s answering, like, the hostess or whoever, they’re just going to say it’s going to take this long, and then you have to, like, multiply it by three you know, because they don’t really know.” (D3)
Many couriers we spoke to learned how to discern whether the person on the phone worked front or back of the house and knew they had to speak with someone from the back of the house if they were to get an accurate estimate for their order.
Administrators also knew that the algorithmic systems underlying the food delivery process were subject to breakdowns. They treated the algorithmic systems they used proactively, anticipating that they would break down and require human intervention. As one administrator put it: “our job as dispatchers is to skim and identify issues.”(P1). Administrators played a vital role in manually checking and correcting the logic of the algorithmic system when complications common to food delivery occurred. This contrasts sharply with mainstream platforms, which have little flexibility for situations deviating from the algorithm’s prescribes. For example, a courier described a situation where they were delivering multiple orders, but a restaurant had forgotten to start the timer on their end, introducing delays in the process. The courier knew that waiting for the order to be completed would result in the order they had already picked up getting cold, potentially displeasing a customer. The courier contacted Nosh’s dispatchers and informed them of the situation. The dispatcher, understanding that these problems arise in food delivery manually changed the delivery routing system to allow the courier to make a single delivery without being penalized for not picking up the delayed order. Platform administrators are trained to intervene manually in the order dispatching system because they know that problems, such as the one described above, do occur.
Stakeholders act as the glue that holds the technical infrastructure of Nosh together. Platform administrators played a key role in maintaining the cohesiveness of the system: they engage in crucial repair work that takes the form of human-to-human interactions to mediate and patch over breakdowns. Restaurateurs, couriers, and customers point to these interactions as integral to their perception of being respected and having agency during food delivery. However, platform administrators articulate the limitations of their technology when it comes to supporting the business operating at a larger scale. As one administrator put it: “you will break the business because there’s no way that you can support the current infrastructure in a big city it’s just not gonna work.” (P2). This highlights a major tension in designing within the platform economy: at scale, human-to-human interactions that promote sentiments of respect and agency are often untenable.