Service level agreements in software are written for IT departments, and the parts they emphasize aren't the parts that matter to a restaurant. A percentage in a contract tells you almost nothing about what your Saturday looks like when something goes wrong.
The question that actually matters is narrower and more concrete: when the system is unavailable, what does a person calling your restaurant hear? Get a specific answer to that in writing and you've covered more real risk than any availability figure will.
Why the percentage is the weakest part
Three reasons.
Measurement definitions vary. Is uptime measured on the platform as a whole or on your specific line? Does degraded performance — the system answering but responding too slowly to hold a conversation — count as downtime, or only a complete failure? Is planned maintenance excluded? Two vendors quoting the same number can be describing quite different realities.
The math is misleading at restaurant scale. Even a high availability figure permits some minutes of downtime per month. Whether those minutes fall at 3am on a Tuesday or at 7pm on a Friday changes their cost by an enormous multiple, and no percentage distinguishes between them.
The remedy is thin. The standard remedy is a service credit proportional to the outage, which for a restaurant is essentially symbolic. You lost a dinner rush; you got a few dollars off next month.
None of this means uptime doesn't matter. It means the number is a poor proxy for the thing you care about.
The question to ask instead
"What does a caller hear when your system is unavailable?"
There are several possible answers and they are not equally acceptable:
Calls fall back to ringing your restaurant. The best of the available options. You're back to where you were before the system existed, which is survivable — your staff answer the phone the old way. Ask specifically whether this is automatic and how quickly it engages.
Calls reach a recorded message. Acceptable if the message is sensible and gives the caller a next step. Much better than silence.
Callers get a busy signal or an error tone. Bad. It reads as a business problem, not a technology problem.
Calls fail silently into dead air. The worst outcome. A caller assumes you're closed or gone. The engineering effort to avoid this is small; the difference to your reputation isn't.
Get the answer in writing. It's a fair question and any vendor who's thought about restaurants will have a ready answer.
The failure modes worth asking about separately
"Down" isn't one thing. Ask about each of these individually, because they have different behaviors and different remedies. We go into the design side in human handoff and failover.
Vendor platform outage. The scenario above.
POS integration down, voice working. The agent can talk but can't check availability or write orders. Does it keep taking orders against a cached menu, degrade to information-only, or hand off? Each is defensible; not knowing which isn't. See POS 86 sync failure modes.
Your internet or power out. Often the agent keeps working, which sounds good until it's taking orders your dark kitchen can't make. You want a fast way to flip the line to closed from a mobile phone.
Carrier-level problems. Largely outside anyone's control, but worth asking whether there's a secondary route and how you'd be told.
Degraded performance rather than failure. Latency climbing to the point where conversations don't work. Ask whether this triggers any automatic fallback or whether the system just gets slower until someone notices.
Notification and status
Two practical questions that get skipped:
How do you find out there's a problem? A status page you'd have to think to check is weaker than a text message. During service, nobody is checking a status page.
How long until you're told? Ask for a rough commitment. A vendor who notifies proactively within minutes is operating differently from one where you're the one who discovers it from an angry customer.
Also worth asking: is there any monitoring on your specific line? Platform-wide health doesn't catch a problem affecting only your integration or only your number.
Support response during service hours
An SLA usually includes support response targets, and this is one place where the numbers do matter — but check the hours.
Restaurant emergencies happen at 7pm Friday and 1pm Sunday, which are precisely the hours a standard business-hours support window doesn't cover. Ask what support looks like during dinner service and on weekends, what the escalation path is for something urgent, and whether there's a phone number or only a ticket queue.
A twenty-four-hour response target is fine for a billing question and useless when your phone stopped taking orders during a rush.
Maintenance windows
Ask when planned maintenance happens and whether you're notified in advance. Restaurant peak hours are unusual compared to typical software customers — a maintenance window scheduled for "off-hours" by an engineering team may land squarely in your dinner rush or your Sunday brunch.
It's a reasonable thing to raise, and a vendor that serves restaurants should already have thought about it.
What to write into the agreement
If you have any negotiating room, prioritize in this order:
- Specified failure behavior. Calls fall back to ringing your line, or to a stated message. This is the highest-value clause in the whole document.
- Proactive notification with a stated timeframe, by a channel you'll actually see.
- Support availability that covers your service hours, with an escalation path.
- Maintenance windows that avoid your peak periods, with advance notice.
- The uptime percentage and credits, last, because they're the least useful.
Most operators reverse this order, which is how you end up with a strong number and dead air on a Friday.
Being realistic about it
Every system has downtime eventually. Cloud infrastructure fails, carriers have incidents, integrations break. A vendor claiming otherwise is either new enough not to know or not being straight with you.
What separates vendors is not whether they'll have an outage but how they've designed for it, how fast they tell you, and how honestly they explain it afterward. That last one is worth testing during a pilot, which is one of the reasons we suggest paying attention to the first thing that breaks in designing a voice AI pilot.
The bottom line
Ask what a caller hears during an outage before you ask about the percentage. Push for automatic fallback to your existing line, proactive notification through a channel you'll see during service, and support hours that overlap your dinner rush. Treat the availability figure and the service credits as the least important part of the document, because they are. The clause that protects your Friday night is the one describing what happens when things go wrong, not the one promising they won't. It belongs on the same list as everything else in our buyer's checklist.