Channel silos, evaluated for restaurants

Restaurant ordering channel silos: why phone is the silo aggregator middleware cannot fix

A typical restaurant runs five ordering channels at once: dine-in, web, third-party delivery, drive-thru where present, and phone. Most articles on channel silos lump those five together and recommend a unified POS or aggregator middleware. That story works for four of the five. It does not work for phone, because phone has no app to consolidate and no API to translate. Below is the diagnosis and the fix that actually fits the phone channel.

Matthew Diakonov, Written with AI

Published May 9, 20267 min read

Direct answer (verified 2026-05-09)

What is a restaurant ordering channel silo?

A separate ordering channel (phone, web, dine-in, drive-thru, third-party delivery) whose orders, menu, and customer data live in their own system instead of sharing one source of truth with the others. Every order on a siloed channel costs labor to reconcile, drifts from the master menu over time, and is invisible to the customer record.

The phone silo is the hardest one to dissolve. Aggregator middleware fixes the delivery silos because each delivery app exposes a webhook the middleware can translate. The phone channel exposes voice and PSTN, not JSON. Historically the cashier was the integration: a human picked up the phone and typed the order into the POS by hand. Remove the cashier and the bridge disappears unless the replacement commits to the POS the same way. background on channel silos

The five silos in a typical restaurant

Walk into any independent or mid-market restaurant and count the surfaces that take an order. There are five, and only the first one was ever designed to be the source of truth. The other four are bolted on, and each one solves its own integration problem in its own way, which is the part most operators do not realize until they are reconciling at midnight.

Where orders enter the building

Dine-in: enters via the POS terminal, lands on the master ticket. Source of truth by definition.
Web ordering: lands on the POS via a direct integration from the ordering vendor (Toast Online Ordering, Square Online, ChowNow, Slice). One channel, one webhook.
Drive-thru, where present: lands on the POS via the drive-thru terminal. Same path as dine-in, different physical surface.
Third-party delivery (DoorDash, Uber Eats, Grubhub): historically arrived on a tablet farm and was retyped. Now collapses into the POS via aggregator middleware (Otter, Deliverect, ItsaCheckmate). Solved at the API layer.
Phone: rings into a handset. No app, no webhook, no tablet to consolidate. The cashier is the integration. This is the silo nothing else fixes.

The four channels in the green column have one thing in common: each one produces a structured event the POS can ingest. A web order produces a JSON payload. A delivery order produces a webhook. A counter order produces a keypress. The phone produces an audio stream and a person typing as fast as they can while another person waits to pay at the counter. That is what makes phone different.

Why aggregator middleware does not touch the phone silo

Aggregator middleware (Otter, Deliverect, ItsaCheckmate) earned its place by solving the tablet farm. It receives webhooks from each delivery platform, maps each app's items and modifiers to the operator's POS GUIDs, and posts the result to the POS as a regular order. The model is elegant because every input is structured. Every delivery app speaks JSON.

The phone gives middleware nothing to chew on. There is no webhook to register. There is no item id in the call. There is no modifier id in the call. There is a person on a 102 second recording asking for a Lumberjack Slam with scrambled eggs and sourdough toast plus a Coke, and somebody (or something) has to turn that audio into the same shape of order that a delivery webhook would have produced. Middleware was never designed to do that, because middleware was never voice-first.

Operators who buy aggregator middleware and call their phone problem solved are correct that their counter is tidier. They are also still missing 30 to 40 percent of phone calls during the rush, because nothing in their stack changed about who picks up the phone.

Two ways to bridge the phone silo

There are exactly two architectures that bridge the phone silo. One is the cashier (the historical default) and one is an AI phone agent that commits to the POS during the call. Most marketing material lumps both into “phone ordering” without naming the difference. The difference is whether the kitchen ticket fires automatically when the call ends, or whether a person still has to push a button.

Before vs. after the phone silo dissolves

Calls land in a handset that nobody has time to pick up. The orders that do get answered are typed by the same staff member juggling the counter. The cart never lives in the POS as a structured order, just as a hand-typed line.

30 to 40 percent of calls go unanswered during the rush
Order accuracy depends on how distracted the cashier is
Customer record contains zero phone callers (the cashier did not log them)
Menu drift: phone-only specials end up not matching the master menu
Reservations and takeout share the same ringing line, both suffer

What committing a phone order to the POS actually looks like

The reference call shipped at public/audio/dennys-order.mp3in the mediar-ai/pieline-phones repo is 102.36 seconds end-to-end, customer on the left channel, AI on the right. During the call the agent collects the cart from the transcript, posts it to the POS, and reads back the confirmed total before hanging up. The 2.4 second gap between “Placing your order now” at 89.12 seconds and “Done. Your total is $34.11” at 91.52 seconds is the round trip you see below.

Phone call -> POS commit -> kitchen ticket

The shape is the same against Square, Clover, NCR Aloha, and Revel; only the labels change. Square calls the cart an Order with line items and modifiers. Clover calls it an Order with line items and modifications. Toast calls the line a Selection. NCR Aloha threads it through a partner certification gateway. Revel hands you a flatter cart with explicit modifier price deltas. None of those differences matter to the caller. All of them matter to the integrator, which is why the phone silo cannot be fixed by one universal box; it is fixed by a set of per-POS adapters.

Per-POS commit latency: the silence the caller hears

The agent waits for the POS to validate the cart and return an order id before speaking the confirmed total. That wait is what the caller hears as silence at the end of the order. PieLine’s benchmark runs the same reference cart through every adapter and reports a per-POS p50. The output below is a single run on 2026-05-07.

eval-voice-models.py --pos all (2026-05-07)

The 520 ms gap between the fastest adapter (Clover) and the slowest (NCR Aloha) is audible. On a 102 second call, half a second is the difference between a confirmation that lands cleanly on top of the caller’s last word and one that drifts into a barge-in. The right number to publish is the per-POS one, because that is what the operator’s customer experiences. If a vendor quotes you one round number across every POS they say they integrate with, ask which one.

The integration test, in one sentence

When the call ends, does anyone on staff need to do anything for the order to reach the kitchen? If yes, the phone silo is still there, dressed up with new software. If no, the phone channel is now structurally identical to dine-in: an order in the POS with item GUIDs, a customer record, a kitchen ticket on the same printer route. That is what dissolving the silo means in practice.

“The experience was better than speaking to a human. No hold time, no confusion, no rushing.”

Anonymous caller

Order placed at Idly Express via PieLine

See your phone channel committed to your POS

A 20 minute walkthrough on your menu, your POS, and the per-POS commit latency you would actually see on a real call.

On phone, channels, and silos

What exactly is a restaurant ordering channel silo?

A separate ordering channel whose orders, menu, and customer data live in their own system instead of sharing one source of truth with the rest of the restaurant. A typical operator runs five at once: phone, dine-in (POS terminal), drive-thru (where present), the restaurant's own web ordering, and a fan of third-party delivery apps (DoorDash, Uber Eats, Grubhub). When those five do not share a common backbone, every order on a siloed channel costs labor to reconcile, drifts from the master menu over time, and is invisible to the customer record.

Why is phone the hardest silo to dissolve?

Because the other silos can be unified by software and the phone silo cannot, at least not by the same software. Third-party delivery silos collapse into the POS via aggregator middleware (Otter, Deliverect, ItsaCheckmate) which translates each delivery app's webhook into a POS order. Web ordering and kiosk silos collapse into the POS via direct integrations from the ordering platform vendor. The phone silo has no app to consolidate (the channel is voice and PSTN, not a JSON payload) and no published API the operator can route through middleware. Historically the cashier WAS the integration: a human picked up the phone, typed the order into the POS by hand, and that was the only way the silo got bridged. Replace the cashier and the bridge disappears unless the replacement commits to the POS the way the cashier did.

How is the phone silo different from the tablet farm problem?

The tablet farm is the visible symptom of delivery-app silos: a counter cluttered with a DoorDash tablet, an Uber Eats tablet, a Grubhub tablet, each chiming on its own and each requiring someone to retype the order into the POS. Aggregator middleware exists to make those tablets disappear. The phone silo has no tablet. It has a ringer. Its symptom is not a cluttered counter; it is a ring that goes nowhere because the staff who would have answered it is taking an order from the person standing in front of them. The tablet farm wastes staff minutes; the phone silo loses calls outright. Fixing one does not fix the other.

What does it mean to commit a phone order directly to the POS?

It means the AI phone agent POSTs a real cart to the POS's native orders endpoint during the call, with item GUIDs, modifier GUIDs, taxes, and the customer's name attached, and reads the resulting order id and total back to the caller before hanging up. This is different from agents that display orders on a tablet, send the staff a text summary, or hand off to a third-party order-management system that eventually writes to the POS. Each of those is still a tablet farm in disguise; one of them just routes through voice. The integration test is on the AI vendor's POS integration page: after the call ends, does anyone on the staff need to do anything for the order to reach the kitchen? If the answer is anything other than no, the phone silo is still there.

Per-POS commit latency, why does it matter for the caller?

Because the agent waits for the POS to validate the cart and return an order id before it speaks the confirmed total. That round trip is what the caller hears as silence on the line at the end of the order. PieLine's reference benchmark against the 102.36 second recording at public/audio/dennys-order.mp3 measures p50 commit times of Clover 820 ms, Square 940 ms, Revel 1010 ms, Toast 1180 ms, and NCR Aloha 1340 ms. A 520 ms gap between the fastest and slowest is audible. It is also why publishing one round number across all POSes is dishonest; the phone silo is not one engineering problem, it is five.

We already have aggregator middleware for delivery apps. Do we still need a phone solution?

Yes. Middleware unifies the channels that have published APIs. The phone channel does not. If you bought Otter or Deliverect and called your phone problem solved, the phone is still ringing into a silo, just with a tidier counter. The two solutions sit alongside each other: middleware on the delivery side, an AI phone agent that commits to the POS on the voice side. Both end at the same kitchen ticket.

What does a restaurant lose to the phone silo specifically?

Three things. First, calls that go unanswered during peak (the staff is on the floor; the ringer rolls to voicemail or busy signal; the customer opens DoorDash). Second, order accuracy on the calls that do get answered (a cashier mis-keying a half-and-half pizza or a spice level into the POS while a customer waits at the counter). Third, the customer record (a phone caller reaches the restaurant directly, but if the order was hand-keyed there is no row in the customer table, no order history, and no path to remarket).

What is the simplest test of whether my phone channel is still siloed?

Pick up a call from the line, take a real order, and watch what happens. Did the cart appear in your POS as a regular order with the same item GUIDs as a counter order, or did your staff retype it from a notepad? Did the customer's name and phone number land in your customer record alongside their pickup time? Did the kitchen ticket fire from the same printer route as a dine-in ticket? If the answer to any of those is no, your phone channel is still its own silo, regardless of what software it sits on top of.