Operations management for restaurants finally has closed-loop control on the order itself. It takes 8.64 seconds.

It means: every order passes through a confirmation step where the recorded order is read back to the source of truth (the customer) before it is committed to the kitchen. Inventory has this: the count is read against theoretical and reconciled. Labor has this: the clock punch is read against the scheduled punch and reconciled. Food cost has this: invoice variance is read against the recipe and reconciled. The phone-taken order historically had no read-back step; the cashier wrote it down, the kitchen made it, the customer accepted or refunded. PieLine's reference call adds a read-back at t=75.42 to t=84.06: the AI repeats the entire compound order, the customer says yes at 85.78. That is closed-loop control on the order itself.

Open /src/components/voice-activity-data.ts and look at the caption array. Captions 33 through 38 are the readback: the AI segments at t=75.42, 78.55, 81.51, 83.34 plus the closing question at 84.06, then the customer's confirmation at 85.78 and 86.26. Five AI segments and two customer segments, 8.64 seconds of AI plus 1.03 seconds of customer answer. The same pipeline that produced the file (described in /scripts/build-voice-activity-data.py) writes this row for every call. The audio is at /public/audio/dennys-order.mp3 if you want to hear it.

Service quality metrics are lagging: you measure order accuracy after the fact, by counting refunds or remakes or reading reviews. Closed-loop control is leading: the loop closes before the order leaves the channel. The difference matters operationally. A lagging metric tells you that last week 2.4% of orders were wrong; a closed loop reduces that 2.4% next week because the misheard item gets caught at t=84.06 and corrected before the kitchen ever hears about it. Operations managers prefer leading controls because they remove the failure mode rather than just reporting it.

Multiple things on a real call would be caught here: a misheard modifier (eggs cooked the wrong way), a missing line item (forgot the strawberry topping), a wrong item entirely (Coke vs Sprite), or a wrong pickup name. On this specific call there are six order facts: lumberjack slam, scrambled eggs, sourdough bread, soft drink, NY style cheesecake, strawberry topping. All six are repeated back at t=75.42 to t=83.34. If any one of them is wrong the customer can stop the AI before t=84.06. The blast radius of a misheard order in restaurant operations is one ticket of food, one staff intervention, and one customer interaction. Closing the loop here drops that to zero.

Add one row in the labor block: order_readback_pass_rate. It is the percentage of phone orders where the customer answered affirmatively to the readback question (the t=84.06 prompt: 'Is that correct?'). On a healthy phone channel that number sits above 96%. The 4% or fewer where the customer corrects something is the new operations signal; those corrections should be tagged and used to tune the menu prompts. Same review document, same cadence, same FOH owner, one new line that operations has never had a number for.

In theory, yes. In practice, almost none do. Spot-check any drive-thru or phone-taking restaurant for a week and the readback rate is somewhere between 0% and 30%, depending on training and staff fatigue. The reason is structural: a human cashier reads the order back when they remember to and skips it when the line is long, which is precisely when error rates spike. A deterministic AI prompt fires every call regardless of queue depth. That is the operational difference between hoping for closed-loop control and having it.

Three numbers describe it. First: roughly 35% of inbound calls go unanswered during peak, so the order never enters the channel at all. Second: of the orders that do enter, between 1.5% and 4% are wrong on arrival (the figure varies by menu complexity). Third: there is no recording of any of it, so root cause analysis happens by re-reading bad reviews. Closing the loop addresses problem two directly and turns problem three into a data set.

The reference call is exactly the case where multi-modifier discipline matters. The lumberjack slam alone forces three modifier choices: how the eggs are cooked, what kind of bread, plus a free-form addition (the strawberry topping the customer requested at t=65.98). The readback at t=75.42 covers all of them in a single 8.64-second pass and then asks for confirmation. The pattern scales: every modifier the customer commits to between t=0 and t=72 ends up in the readback string. The longer the order, the more valuable closing the loop is.

Each of those owns a different closed loop. Toast owns the POS to kitchen loop. Restaurant365 and MarginEdge own the invoice to recipe loop. 7shifts owns the schedule to clock-punch loop. ChowNow owns the online order to POS loop. None of them touch the inbound voice channel because none of them ingest audio. PieLine is the order-channel loop. It is additive: it does not displace anything, it writes a row of data that the other systems cannot.

The customer interrupts. On a passing call (this one) the AI lands its question at t=84.06 and the customer answers within 1.7 seconds. On a failing call the customer says something other than yes between t=75.42 and t=84.06: 'wait, no Coke', 'I said over easy', 'add a coffee'. The AI restates the corrected order and re-asks. Either path produces a closed loop, but only the failing path also produces a labeled training example of where the order channel misheard the customer. That label is what feeds menu-prompt tuning the following week. Operations gets two artifacts out of one prompt.