Buying software for your restaurant is a different exercise than buying it for most businesses. A bad menu integration or a missed order at 7pm on a Saturday shows up immediately, in front of a customer, and it's hard to walk back. That makes the buying questions worth taking seriously before you sign anything, not after.
This is a genuinely vendor-neutral checklist. Use it on us or on anyone else you're evaluating.
Questions about accuracy and your specific menu
Start by asking whether you can test the system on your actual menu before committing, rather than a generic demo menu. A demo menu is built to succeed. Yours has a half-and-half rule, three items with the same first word, and a modifier tree somebody built in 2019 and nobody has touched since. If a vendor won't run a trial on your real menu, you're being asked to buy on faith.
Then push on modifiers. Ask how the system handles the substitutions your customers actually make: half-and-half items, common allergen swaps, "light sauce," "the usual" from a regular. These are exactly where shallow systems produce a friendly conversation and an unusable ticket, which is the reason integration depth outranks voice quality in an evaluation.
Ask what happens when it doesn't understand something. You want the specific escalation logic, not a reassurance about accuracy. Does it try twice and transfer? Does it take a message? Does it keep asking?
And ask who updates the menu when it changes, and how fast. If a price changes or an item is 86'd mid-shift, can your closing manager make that edit in two minutes from a phone, or does it require a support ticket that lands Monday? This one question predicts more of your six-month experience than any other, because menus drift constantly and an agent quoting stale prices is a guest-facing problem.
Questions about integration and reliability
Confirm that your specific POS is a live, current integration rather than "compatible with most systems" or a roadmap item. Ask the vendor to name the exact integration, and to confirm it's already running for another customer on your POS and your version of it. Check it against their published integrations list rather than taking it verbally, because this eliminates options faster than any other question.
Then work through the failure cases, one at a time, and refuse general assurances.
If their system goes down, what does the caller hear? Silence, an error tone, or a fallback that rings your existing phone? If your internet goes down, does the order queue and land later, get lost, or route somewhere else? If your POS is down but the phone line is fine, can the agent still take orders and hold them, or does it stop selling? A vendor who has thought about restaurants will have crisp answers, because outages are ordinary rather than hypothetical.
Finally, ask whether you can pull real call transcripts and recordings after go-live. Not a dashboard summary. The actual text of what was said to your customers. A vendor who scores their own product and won't show you the underlying calls is asking for trust you have no way to verify.
Questions about cost and contract terms
Ask for the all-in monthly cost, including per-call, per-minute, and overage charges, not the advertised base price. Then ask them to price a month at your real volume. If you take 1,800 calls a month, have them show you that invoice, not the starting tier. Our own plans start at $250 a month, and any vendor should be able to do the same arithmetic against your numbers on the spot. The gap between advertised and actual is where the costs hide.
Ask whether the trial runs on real call volume, and whether it's long enough to cover a full weekly cycle including your busiest shift. Ask about setup fees and menu-import fees beyond the subscription. Ask for the contract length, the auto-renewal window, and the exact notice period for cancellation, in writing.
Cancellation is the term most often described accurately in conversation and differently in the document. Read that clause yourself.
One more cost question that rarely gets asked: what happens to your phone number. If the vendor provisions a new number and forwards your existing line, that's reversible. If they port your published number onto their account, leaving means porting it back, and the timeline for that is measured in days, not hours. Ask who holds the number on paper, and ask what the port-out process looks like before you need it.
What a good answer sounds like versus a deflection
Across all of these, the pattern matters more than any single response. A vendor who works with restaurants answers operational questions operationally: they name the sync interval in minutes, they describe what the caller hears during an outage, they know what a forced modifier is. A vendor selling a general-purpose voice product redirects. Ask about 86 sync, get an answer about natural language understanding. Ask about the ticket, get a voice sample.
Neither response tells you the product is bad. The second tells you they haven't been asked by enough restaurants yet, and you'd be paying to be the one who finds the gaps.
Questions about your data and your customers
Where do call recordings and transcripts live, and who inside the vendor can access them? Does the system disclose to callers that they're speaking with software, and can you control that language? Some states and some brands have firm positions here, so this is a policy question rather than a preference.
What happens to your data if you cancel? Specifically, do you leave with your order history and customer records in a usable export, or does it stay in the vendor's system? Ask for the export format. "You can request it" is not the same as a file you can hand to the next vendor.
Questions to ask yourself, not the vendor
- What's my actual missed-call problem, in numbers? Use the framework for estimating it before the first sales call, because walking in with your own figure changes the conversation entirely.
- Am I closing a coverage gap, or trying to cut labor hours? Both are legitimate, and they lead to different configurations and different definitions of success.
- Who on my team owns this: reviewing transcripts, updating the menu, handling escalations? Software without an owner drifts out of date within a quarter.
- What would make me cancel? Write the number down now, while you're skeptical, rather than after you've defended the purchase to a partner.
A reasonable evaluation process
- Shortlist two or three vendors on POS compatibility first, before you look at anything else.
- Get a live demo on your actual menu, not a template.
- Run a real trial covering your busiest shift, and personally call in with a normal order and a deliberately awkward one.
- Pull transcripts from the trial and read a sample, rather than trusting the dashboard.
- Get contract terms, cancellation policy, and outage behavior in writing before signing.
None of this is exotic. It's the same diligence you'd apply to any vendor that becomes the first voice a customer hears when they call you. Run the awkward test order in week one of any trial, and let that single ticket carry more weight in your decision than every demo you sat through.