AI phone for restaurants vs trades dispatch: same category, different product

No. They share a category label (AI phone for service businesses) and almost nothing else. A trades dispatch AI captures the call, qualifies a job by symptom ('unit is icing up,' 'breaker keeps tripping'), and books an appointment on the dispatch board. The transaction completes hours or days later, on a truck, in a customer's basement. A restaurant phone AI has to close the order inside the same call: parse cuisine-specific modifiers, post the cart to the POS, get the kitchen ticket to fire, and read back the line items and total before the caller hangs up. The integration target is different (POS vs. dispatch board), the call duration is different (call ends when the POS acks, not when an appointment slot is found), and the failure mode is different (a misbooked truck is recoverable; a wrong order across town during the Friday rush is not).

Some of it transfers. The shared part is the missed-call number: service businesses lose meaningful revenue from the calls that never reach a human, and an AI agent that answers on the first ring closes that gap. The part that does not transfer is the after-call architecture. Avoca's value lands when an inbound call becomes a booked appointment in a dispatch board with a technician name on it. PieLine's value lands when an inbound call becomes a line on the kitchen display with the half-and-half pizza modifier mapped to the right POS item ID. Both answer the call. Only one closes the transaction inside the call. The companies that win the restaurant slice will look more like POS-integration companies than like dispatch companies, because that is the integration target the work actually depends on.

Not cleanly. The two products share a voice layer and split everywhere else. The dish ontology that handles 'half pepperoni, half veggie, extra cheese on the veggie half only, gluten-free crust' is its own engineering investment — modifier trees, fraction handling, allergen flags, POS item mappings. The POS round-trip (Clover, Square, Toast, NCR Aloha, Revel) has to be wired into production, not behind a Zapier shim, because the kitchen ticket has to fire while the caller is still on the line. The pricing model has to be flat per call, not per minute, or the operator is taxed during the rush they are trying to recover. A trades agency that bolts on 'restaurants' usually keeps a CRM hook, a per-minute meter, and a free-text-to-inbox order flow. That ships the missed-call number, but it does not ship the order.

Listen to a captured call sample. A trades sample ends at 'we will have a tech out Tuesday at 2 PM, you will get a text confirmation.' A restaurant sample ends at the AI reading back line items, hitting a brief silence as the POS round-trips, and then announcing the total and pickup window. PieLine ships such a sample publicly: public/audio/dennys-order.mp3 in the repo, 1,229,949 bytes, 102.36 seconds, multichannel transcribed through Deepgram nova-3. The 2.4 second silence between 'Placing your order now' and 'Done' is the POS round-trip. The total ($34.11) and the pickup window arrive after. If an agency cannot produce that end-state, it is built for dispatch.

Yes, on both. A typical HVAC or plumbing shop sees a steadier daily call load, with cold snaps and storm spikes that are predictable on a multi-day horizon. A restaurant sees a Friday 6:45 PM spike that hits and dies inside a forty-five minute window, plus a Super Bowl Sunday and a Valentine's Day that look nothing like an average week. PieLine's published concurrency ceiling is 20 simultaneous calls per location, sized to the worst hour of a restaurant week, not the average day. That number alone forces the pricing to be flat per call and the call routing to be parallel by default. A trades agent sized for sequential intake (one caller, one agent, one booking, repeat) breaks during a restaurant peak. The shape of the curve is the architectural input.

Reservations are the part of restaurant phone work that is closest to trades dispatch in shape, and even there the parallel only goes so far. A reservation is a future commitment with a party size and a time slot, which lines up with a trades appointment. But on a restaurant phone line, reservations share airtime with takeout and delivery orders, which are transactional and have to clear the POS in real time. PieLine's call flow handles both in the same agent: reservations go to a confirmation queue staff reviews on a dashboard, with a confirmation text to the customer; takeout and delivery orders go straight to the POS with payment processed over the phone for delivery. A trades-only architecture handles the first half cleanly and has nothing for the second.