Restaurant automation software stops at the resolver layer. That is where the phone channel lives.
Every automation software comparison lists the same six categories. None of them names the piece that decides whether a spoken sentence lands in your POS as a clean ticket or as a transcript a human still has to retype. Here is the layer every guide leaves out, why it is the whole job when you automate phone, and how PieLine builds it during onboarding.
The six categories every comparison names, and the seventh that every comparison skips
Pull up the top five guides for this topic and write their category headers on a whiteboard. You will always get the same list: POS, KDS, online ordering, inventory, labor scheduling, reporting. Six boxes. The reason every guide produces the same six boxes is that every product in the market fits into one of them.
The seventh category nobody draws on the whiteboard
A resolver translates a caller utterance into a POS payload. Input: a sentence. Output: a set of catalog object IDs plus modifier group IDs plus fulfillment metadata that the POS accepts without human review.
- Why it is missing from every comparison: the other six categories assume a touch UI, which has the mapping baked into the button.
- Where it becomes essential: the moment you automate the phone channel, the touch assumption breaks.
- What it produces: a POST to the POS Orders API, not a voicemail and not a Slack message.
Verify in the product repo at src/app/page.tsx:263-301 (feature grid) and src/app/page.tsx:551-611 (live POS list).
What a comparison chart usually lists under "restaurant automation software"
How the resolver sits between a caller and your POS
The surface (phone call) produces ambiguous text. The catalog (your POS) requires unambiguous IDs. The resolver is the piece that turns one into the other. Here is the actual shape of that pipeline when a PieLine call lands.
Caller > PieLine resolver > POS ticket
The four layers of restaurant automation, from surface to kitchen
The cleanest way to pick a software stack is to draw the four layers explicitly, name which product lives at which layer, and refuse to skip the resolver just because the other six categories did.
Surface: where the order is placed
Phone, web, mobile app, kiosk, counter tablet, drive-thru. Every surface has its own input shape. The phone surface is spoken sentences. The web surface is clicks and typed text. The counter surface is a touchscreen. Each surface drives a different set of downstream requirements.
Catalog: the POS source of truth
Item variations, modifier sets, modifier groups, prices, categories, tax rules. The catalog is owned by the POS (Clover, Square, Toast, NCR Aloha, Revel) and every order eventually writes into it. No surface can produce a valid ticket without addressing catalog IDs.
Resolver: surface to catalog
The layer every comparison skips. Maps a phrase like 'large pep, thin, extra cheese' to a variation ID plus three modifier IDs in the specific POS you use. For touch surfaces the resolver is the button. For voice surfaces the resolver must be built.
Fulfillment: kitchen and delivery
KDS routing, expediter logic, delivery dispatch, pickup timing. This is the layer that picks up the resolved ticket and executes on it. Works identically regardless of which surface produced the order, as long as the resolver did its job.
Where PieLine sits
At the phone surface and the resolver, together. PieLine answers the call, resolves the utterance against your Square or Clover or Toast or NCR Aloha or Revel catalog, and writes to the Orders API. The catalog and the fulfillment layers are your existing stack. We add the missing seventh.
The dish description record: the half of the resolver nobody writes about
The item ID half of the resolver is the obvious half. The dish description half is the one that separates answering the phone from answering the phone well. During onboarding PieLine maps every dish to a record covering ingredients, spice level, sweetness, and preparation notes. Here is what one of those records actually looks like on the wire.
Touch resolver vs. voice resolver, side by side
A cashier pressing a button is executing the resolver mentally and the POS is recording the output. When the cashier disappears from the loop, the mental step has to be explicit. The same sentence becomes an API call, not an item-button tap.
Phone call during rush: cashier flow vs. PieLine resolver flow
When the cashier is the one running steps 2 and 3 in their head, modifier drop-off is the failure mode. "Extra cheese" gets forgotten because the cashier is also watching the rush. When PieLine runs steps 2 and 3, modifier drop-off is rare because the resolver is deterministic against the catalog, not dependent on attention budget.
What the POST actually looks like
This is what reaches the POS after the resolver runs. The shape is the same as an online order from your web surface, because the catalog does not care which surface the order came from, as long as the IDs are right.
Automation software with a resolver vs. automation software without one
The honest comparison is not PieLine against a POS or PieLine against a KDS. It is how a stack behaves on the phone channel when the resolver is present vs. absent.
| Feature | Stack without a resolver | Stack that includes a resolver |
|---|---|---|
| Phone rings during rush, staff is in the kitchen | Call goes unanswered, order lost | Call answered, order resolved, ticket printed |
| Caller says 'large pep, thin, extra cheese' | Human repeats back, keys three buttons | Utterance maps to one variation ID plus two modifier IDs |
| Menu change (new item added to POS catalog) | Retrain staff on the new button location | Resync catalog, resolver picks up new IDs automatically |
| Answer 'is the tikka masala mild?' | Staff guesses or asks the kitchen | Dish description record returns spice_level: medium on range 1-5 |
| Handle 20 calls at once | No. One cashier, one call, one phone | Yes. Resolver has no concurrency limit at the surface |
| Upsell attached to cart | Staff forgets under load | Resolver returns priced pairing from dish record on every order |
| Escalate on edge case (complaint, catering, etc.) | Callback, retry, or lose the caller | Resolver routes to staff with full conversation context |
What a rush looks like on each side of the resolver
The sharpest test for any automation software is what it does when things are hardest. Friday 7:38pm, three calls inbound, one counter cashier, kitchen at full tilt. Here is the sequence on a stack that includes the resolver.
Frame 1: three phones ringing at once
How PieLine assembles the resolver during onboarding
Menu scrape from your published online menu
PieLine's onboarding team pulls your full menu from your public ordering page or POS online store. Output: raw item list with names, descriptions, prices, category hierarchy. Takes hours, not days.
POS catalog fetch over OAuth
PieLine authenticates against Clover, Square, Toast, NCR Aloha, or Revel and pulls the catalog tree. Output: the exact item IDs, modifier group IDs, and variation IDs that the POS Orders API requires.
Cross-map menu items to POS IDs
Every scraped menu item is mapped to the POS item ID and the modifier groups the POS expects. Mismatches (online menu has an item that is not in the POS catalog, or vice versa) are surfaced to the operator for cleanup.
Dish description authoring
Each dish gets a description record covering ingredients, spice level, sweetness, allergens, preparation, and voice hints (common mispronunciations, common modifier phrasings). This is the record the AI reads from when a caller asks a question the order path cannot answer.
Rules and escalation config
Hours, pickup windows, delivery zones, upsell pairings, escalation triggers (complaint, catering over a threshold, manager request, repeat-clarification). All configured once at the merchant account level, then applied to every call.
Go live and first-month refinement
PieLine starts answering calls. During the first month PieLine monitors calls and refines the dish descriptions, voice hints, and escalation rules against your actual traffic. If the resolver does not clear the contract, the first month is refunded.
Buyer checklist: do you need a resolver in your automation stack?
- Do you take phone orders today? If yes, you have a resolver problem whether you admit it or not.
- Do you miss more than 5% of calls at peak? That is the number where the resolver pays for itself in the first month.
- Do your cashiers answer phones during rush? If yes, staff time is the hidden cost of the missing resolver.
- Is your POS one of Clover, Square, Toast, NCR Aloha, or Revel? Then the integration half is already solved.
- Does your catalog change more than once a month? If yes, the resync workflow matters; hand-maintained mappings will drift.
- Do callers ask factual questions (hours, allergens, spice level)? The dish description record handles those without routing to staff.
- Do you already have a voice tool connected to your POS by hand? Then the resolver exists, it is just expensive and brittle.
The numbers that make or break the resolver case
Pulled from PieLine's restaurant deployments and from the public feature grid on the landing page.
Simultaneous calls the resolver can handle
0
per location, per minute, regardless of staff
Order accuracy against the catalog
0%+
across Clover, Square, Toast, Aloha, Revel
AOV lift from cart-matched upsell
0-20%
priced pairing attached at resolve time
Three questions to ask any automation software vendor
The resolver question is not usually on the buyer's checklist, which is why most automation stacks have a hole under the phone channel. Ask these three and you will know where each vendor actually sits.
Question 1
Does your product take a spoken sentence and produce a POS ticket with correct item and modifier IDs, without a human between the two?
This is the resolver test. Touch POS vendors will answer no, because they assume a cashier. Voice AI vendors should answer yes; if they answer "we send you a transcript and you key it in", they are selling transcription, not automation.
Question 2
What happens when I add a new item to my POS catalog on a Tuesday afternoon?
A real resolver resyncs the catalog and the new item becomes callable the same day. A brittle mapping requires the operator to hand-edit a rule, which is how drift starts. The answer reveals whether the vendor treats the catalog as the source of truth or as a one-time export.
Question 3
Can the AI answer "is the tikka masala mild?" without calling the kitchen?
This is the dish description test. If the vendor does not build per-dish annotation during onboarding, factual questions like spice, sweetness, allergens, and preparation either get refused or hallucinated. The answer reveals whether the resolver has a knowledge layer or only a mapping layer.
Run your own menu through the resolver.
Bring your POS login. We will OAuth into your Square, Clover, Toast, NCR Aloha, or Revel sandbox, scrape your online menu, write the dish description records, and place a live phone call so you can watch the resolver produce a real POS ticket. $350 per month flat up to 1,000 calls, money back on the first month.
Book a 15-minute demo →Close the resolver gap in your automation stack
Fifteen minutes, a live OAuth into your POS, and a real phone call producing a real ticket on your own catalog. No sales deck, no generic demo environment.
Book a call →Frequently asked questions
What does restaurant automation software actually automate, and where does it stop?
Most restaurant automation software automates one of six layers: point of sale (Clover, Square, Toast, NCR Aloha, Revel), kitchen display and expediter routing, online and app-based ordering, inventory and supplier reorder, labor scheduling, and reporting. Every comparison article lists the same six categories. None of them automate the phone channel, because automating the phone requires a resolver that translates a caller's sentence into a POS item ID with the right modifier tree. PieLine is the resolver, sitting in front of the POS and writing a ticket that the POS and every downstream system treats as a normal order.
What is a resolver, concretely?
A resolver is the piece that takes a human utterance, for example 'can I do a large pep, light sauce, thin crust, and a Coke', and outputs a machine payload the POS will accept without human review. In PieLine that payload contains the Square or Clover or Toast catalog object IDs for the pizza variation, the modifier group IDs for crust and sauce level, the beverage catalog ID, and the fulfillment type. The resolver is not the language model; it is the mapping the language model writes into. Without this layer, you have voice transcription, which is still manual.
Why do other restaurant automation tools not include a resolver?
Because their source of truth is a touch UI. A cashier touches a button that is already tied to the item ID. The mapping problem is solved at the UI layer by humans pressing buttons. When you move to voice, the mapping problem comes back in full, because the caller does not say 'item ID 48812', they say 'a Coke'. The resolver is the piece that handles that gap. Restaurant automation software built around touch interfaces never needs one. Restaurant automation software that automates voice cannot work without one.
How does PieLine build the resolver during onboarding?
PieLine's onboarding team scrapes your online menu, maps each item to the specific POS item ID and modifier group IDs in your POS (Clover, Square, Toast, NCR Aloha, or Revel), and writes a dish description record for each item covering ingredients, spice level, sweetness, and preparation notes. The language model is then grounded in your actual catalog, not a generic menu prompt. Restaurants go live the same day on the phone side because the resolver is assembled in the onboarding workflow rather than left to the operator.
Is this different from 'integrating with my POS'?
Yes. Integration means the pipe exists. Resolver means the mapping on top of the pipe exists. Most automation software integrates with a POS and then writes whatever the operator configured. PieLine integrates with the POS and also owns the resolver, so a voice utterance becomes a correctly-IDed ticket without the operator drawing the map. If you already have a voice tool plus a POS, you are likely hand-maintaining the mapping between them, which is where accuracy falls off a cliff during menu changes.
Can I buy restaurant automation software without buying a phone module?
Yes, and most operators do. The question is whether the phone channel is part of your revenue mix. At peak times, 30 to 40 percent of restaurant calls go unanswered. Every automation category that exists, including POS and KDS, can be fully deployed while the phone keeps bleeding. The rational purchase sequence for operators with heavy phone volume is POS first, KDS second, and a phone resolver third, treating it as a peer to online ordering rather than a voicemail tool.
How does the resolver handle menu changes?
When a restaurant changes its POS catalog, PieLine resyncs the catalog tree (item variations, modifier sets, prices) and updates the dish description records during the first-month active refinement window. New items flow in automatically. Discontinued items stop being resolvable. Operators do not hand-edit the mapping table. The dish description layer is the one piece that benefits from a human review during the first month, because spice and sweetness annotations inform the small-talk half of calls, not the order-taking half.
How much does the phone automation piece cost against a POS or KDS line item?
PieLine is $350 per month flat for up to 1,000 answered calls with money back on the first month, $0.50 per additional call. A dedicated phone employee runs $3,000 to $4,000 per month and handles one call at a time. Most POS subscriptions land in the $60 to $165 per location per month range for base tier plus hardware capex. A KDS display subscription is typically $25 to $50 per terminal per month. The phone resolver line item sits between a KDS and a phone employee in monthly cost, while handling 20 simultaneous calls and replacing the per-location phone hire.
Do restaurant automation software comparisons ever mention this resolver?
The standard articles do not. Open the top-ranking pages and you will find tables of POS systems, KDS vendors, online ordering platforms, and inventory tools, plus pricing tiers and feature checkmarks. The mapping layer between utterance and POS ID never appears as a row. That gap is the single most visible evidence that the phone channel has been excluded from the automation conversation by the category as a whole.
Your catalog, your call, your ticket.
We will connect to your POS (Clover, Square, Toast, NCR Aloha, Revel), scrape your online menu, build the resolver in an hour, and place a live call while you watch the ticket land on your kitchen printer. The rest of your automation stack does not change.
Book the demo