Every restaurant automation system has a throughput number. The phone subsystem needs one too, and it is seconds per call close.

Every other subsystem in a restaurant automation stack already has one. A kitchen display system is graded on ticket-to-plate time (typically 10 to 14 minutes in full service, 3 to 6 in quick service). Inventory is graded on variance percent (under 2 percent is clean, 5 percent plus is leaking). Scheduling is graded on sales per labor hour. Online ordering is graded on conversion rate and abandoned-cart percent. If the phone channel is going to be part of the stack, it needs its own time-budget number, and the natural one is 'seconds from first AI hello to a ready POS ticket.' Without that number, you cannot tell whether your phone subsystem is a peer of the kitchen display system or a pretty voicemail. With it, the phone channel becomes legible to the same operator who reads the other dashboards.

The entire arc of a phone order to a POS-ready ticket. At 0.4 seconds the AI answers with 'This is Denny on a recorded line.' By 9.4 seconds the caller has asked for a lumberjack slam and a Coke. From 15.9 to 25.7 seconds the AI collects the two clarifications every QSR order needs, egg preparation and bread choice, plus a Coke subclass. At 55.5 seconds the AI offers a priced upsell ('a slice of New York style cheesecake'). At 66 seconds the customer accepts with a custom modification ('add strawberries'). At 75.3 seconds the AI read-back includes the modifier. At 89 seconds the AI says 'placing your order now,' at 95 seconds it says the total is $34.11 and the pickup time is 12:45AM, and at 101.8 seconds the customer says bye. The full transcript with timestamps is checked into the repository.

Open src/components/voice-activity-data.ts in the pieline-phones repository. The file exports voiceData with duration: 102.36 at the top, a sampleRate of 60, envelopes for customer and AI audio channels, and a captions array with start and end timestamps for every turn in the call. It was auto-generated from a Deepgram multichannel transcription of public/audio/dennys-order.mp3, which the landing page embeds via the VoiceActivityClip component on the hero. This is not a marketing number. It is the literal length of a recorded call that the product actually took.

It's a reference, not a claim that every call is that fast. The point of referencing a single publicly available call is to give operators a concrete time budget to test against. When you benchmark a kitchen display system you also start from one ticket and generalize: 'the average burger leaves the rail in 4 minutes 12 seconds, with a p95 of 6 minutes 40 seconds.' The 102.36 second PieLine call is the anchor a restaurant can stopwatch against its own calls, the same way it stopwatches its own kitchen. If your current human-staffed calls average 4 to 7 minutes at rush (industry norm for full-service order-taking), the gap is where the automation pays for itself.

The moment the order is written to the POS as a real ticket, not the moment the caller hangs up. Those are different events. PieLine's direct adapter posts the order to Clover, Square, Toast, NCR Aloha, or Revel at the confirmation step, which in the reference recording is 89 seconds in. Everything after that is wrap-up: reading back the total, pickup time, thanking the caller by name, goodbye. If you measure to ticket-in-POS instead of to call-hangup, you get a cleaner number that compares directly to kitchen display system 'ticket received' timestamps, which is the handoff between the phone subsystem and the kitchen subsystem.

A human cashier taking a phone order during peak hits three failure modes the stopwatch captures. First, wait time: the phone rings while the cashier finishes an in-store transaction. Industry data puts 30 to 40 percent of restaurant calls at unanswered during peak, which is implicit time to a zero-ticket close. Second, re-key time: even when answered, the cashier often writes the order on a pad first, then re-enters it into the POS after the call, adding 60 to 120 seconds of non-call labor. Third, upsell skip: a rushed cashier does not pitch the dessert, so the order closes at a lower ticket size. Against that, an automated phone subsystem that hits a 102.36 second close with an upsell attached is measurably a different class of system, not a faster human.

The metric applies anywhere phones ring. The target number changes by format. A pizza order with heavy customization (crust, half-and-half toppings, dipping sauces) will run longer than a QSR breakfast combo. A catering inquiry will not fit inside a second-per-call-close frame at all; those are the calls the handoff spec sends to a human (see the smart-call-transfer feature). Full-service restaurants with small phone volume can still measure the metric; they just care more about variance than about the average. The point is that there is a number to look at, not that the number is the same at every concept.

Multiplicatively. A human phone employee runs one call at a time, so throughput is constrained both by per-call duration and by sequential blocking. An automated subsystem that closes a call in 102 seconds and runs 20 of them in parallel has a theoretical ceiling of roughly 700 call-closes per hour. Real volume never approaches that ceiling, but the gap matters at rush: if Friday 7pm drops 80 calls in 20 minutes, a one-at-a-time channel takes 80 call-closes worth of clock time (plus wait) while a 20-wide channel takes 4 rounds of 102 seconds, which is the difference between calls answered and calls lost. The full picture is (duration per call) divided by (parallel slots), and both numbers have to be on the dashboard.

Order accuracy, handoff quality, upsell acceptance rate, conversation empathy. Those are separate numbers with their own targets. PieLine publishes a 95 percent plus accuracy figure on complex modifications. Smart call transfer handles non-order calls with context forwarding. Upsell attach rate is emitted to the analytics dashboard. Seconds per call close is the throughput axis; accuracy is the quality axis; handoff rate is the exception axis; upsell attach is the revenue axis. A restaurant automation system needs a number on each of the four, not one composite number that hides tradeoffs.

Not cleanly. The metric depends on a machine-readable 'ticket arrived in POS' event to stop the stopwatch. If orders arrive in the POS via text message or email that a cashier re-keys, the relevant close time is the re-key completion, not the call completion, and the re-key latency drifts with staff workload. PieLine's direct adapter covers Clover, Square, Toast, NCR Aloha, and Revel at the API level. For POS platforms on the longer tail of 50-plus supported integrations, verify with the onboarding team whether the adapter path closes the ticket programmatically or whether the time budget has to include a human step.

Three columns. First, a rolling average and p95 of 'seconds from AI hello to POS ticket posted' broken down by daypart and by day of week. Second, a counter of calls that closed above a chosen threshold (for example, 180 seconds) with reason codes populated from the conversation transcript, so you can see whether the slow calls were heavy customization, multiple upsells, or handoff candidates that should have routed to staff. Third, a per-location breakdown once you are multi-unit, because the target time differs by menu complexity. All three should read from the same event stream the POS reads for its ticket counts.