Never underestimate the error introduced by a lack of incentive for humans to comply with the API (or the API itself being human-hostile).
My favorite example is the Domino's "Your pizza is ready" signal. Since the data feeding the signal also feeds the store's performance analysis (i.e. they track how fast employees are getting pizzas ready), there's significant incentive for employees to lie to the algorithm and hit "It's ready" before it's physically ready, on the assumption that customers will take nonzero time to wander over and show up for pickup.
> there's significant incentive for employees to lie to the algorithm and hit "It's ready" before it's physically ready
It's the same with fast food in general. One of my first jobs was at a McDonald's where the standard practice was to hit the 'finished' button for any order that was taking 'too long', at which point the people doing food prep would have to keep track of a sequence of three or four orders in their head. As you can imagine, errors were constant, but customer satisfaction was less important to management than satisfying this imaginary metric.
I managed at Domino's back about a decade ago when they forced the transition to the updated in-store POS that was required for this.
To add a bit of color to what's happening:
- You don't actually hit an "It's ready" button. When you knock the pizza off of the makeline screen, it transitions from "so and so is making your food" to "it's cooking".
- The "It's cooking" phase is just a simple timer. It's supposed to be adjusted to the time of the conveyor oven (which can vary from ~3-9 minutes depending on the particular oven they use). Most stores never customize that setting in the system, and it stays at the default. And other stores may have ovens running at two different speeds.
- Average make time is one of the metrics monitored by corporate audits, so you do have gaming of the system by knocking pizzas off the make screen early. But you can also have a backup at the oven during rushes, where food sit at the end of the makeline ready to go in the oven when capacity opens. At the same time, some items such as wings have to go through the oven twice (depending on the oven configuration). In both of these cases, even without gaming the system there will be dissonance between actual cook time and the cook time shown in the pizza tracker.
- For those that did try to game the performance metrics, it came with an equal headache internally beyond just that "It's cooking" timer. The scheduling system used that average make time as an input into calculating labor needs. The more you knocked stuff off the makeline early, the more optimistic the scheduler became and the more you'd have to override the suggested schedule and the more "Labor Waste" you'd create by having more people working than the system thought you needed.
It was really quite fascinating to see that system transition before I started my career. I witnessed it at two stores under two different franchises - one did the bare minimum to comply and the other one embraced the new system and it's capabilities. There were a lot of incredibly capabilities and forecasting optimizations that were made possible by the update. But they all presumed accurate data in the system at all times. But in many cases, managers were either disincentivized to do what was required to maintain that level of accuracy or transparency, or a component of the system would be designed in such an idealistic fashion that it didn't allow for the amount of pragmatic flexibility it needed. Both of which have been really valuable lessons I've taken forward with me.
My favorite example is the Domino's "Your pizza is ready" signal. Since the data feeding the signal also feeds the store's performance analysis (i.e. they track how fast employees are getting pizzas ready), there's significant incentive for employees to lie to the algorithm and hit "It's ready" before it's physically ready, on the assumption that customers will take nonzero time to wander over and show up for pickup.