01What the commitment will cover
The SLA is scoped to two things a restaurant actually experiences: whether an inbound call to a live location gets answered, and whether the people who need to see the result — through the operator console and the staff tablet — can reach it. It doesn't stand in for the separate commitments that cover security incidents, data handling, or payment processing; those live in their own schedules and are cross-referenced from the full legal text, not duplicated here.
Coverage is also specific to what a restaurant has actually turned on. A capability that hasn't been activated for a given location, or a system a restaurant runs entirely on its own — its own internet connection, its own phone carrier — isn't part of what Dohos is measuring. The agreement measures the service Dohos provides, not everything that happens to touch a phone call.
02How availability would be measured
The method is a straightforward one: take the minutes in a billing period the service was scheduled to be available, subtract the minutes it wasn't, and express what's left as a percentage of the whole. A minute only counts against Dohos if the cause was inside Dohos's control — a maintenance window announced in advance, or an outage caused by the restaurant's own carrier or internet connection, would be handled as a named exception rather than counted as downtime.
That method only describes how a percentage would be produced, not what the percentage is. A health check quietly returning "OK" isn't sufficient proof of availability on its own — the intent is to measure whether a caller could actually get through and be understood, a functional-success measure, not just whether a server responded to a ping.
03What's not approved yet
A signed SLA needs five specific figures, and the current draft leaves all five as open blanks rather than filling them with an estimate. That's a deliberate discipline, not an oversight — a plausible-sounding number inserted now, before it's been measured against real call volume, would be a worse outcome for a reviewer than the gap stated plainly.
| WHAT A SIGNED SLA WOULD STATE | CURRENT STATUS |
|---|---|
| Availability percentage | Not set. This is the figure most vendor reviews ask for first, and it's the one the draft is most explicit about leaving open. |
| Response, restoration, and resolution windows, by priority | Not set, for any of the four priority levels described below. |
| Staffed support hours and channels | Not set — see support for how this same gap plays out from the support side. |
| Service-credit percentage, formula, and cap | Not set. No credit amount exists to calculate against yet. |
| A threshold that defines repeated or chronic failure | Not set, along with the escalated remedy that would eventually attach to it. |
04How an issue would be prioritized
The draft sorts a service problem into four priorities — critical, high, medium, and low — based on how much of the service is affected, whether a safe workaround exists, and whether the issue touches security, payment, or order integrity rather than ordinary functionality. A critical issue is one with no reasonable workaround affecting a meaningful scope of restaurants, not simply "something broke."
| PRIORITY | WHAT PUTS AN ISSUE HERE |
|---|---|
| Critical | The service is unavailable or unsafe for a meaningful scope of restaurants, with no reasonable workaround. |
| High | A material capability is degraded or intermittent, and any workaround is limited or burdensome. |
| Medium | A non-critical function is impaired, but a reasonable workaround exists. |
| Low | A question, a cosmetic issue, or something without material service impact. |
05Voice-specific measurement
Speech recognition accuracy, response latency, and order-confirmation correctness are tracked as separate questions from whether the platform was reachable at all — a call that connects but consistently mishears an order is a different failure than a call that doesn't connect. A specific accuracy or latency figure for either would need its own defined measurement — which dataset, which language, what counts as an error — and none of that has been specified yet, so no figure is published in its place.
06Remedies, once a target exists
The structure for a service credit is fully drafted: it would apply against a future invoice rather than as a cash refund, it would be tied to the specific service and period affected, and a restaurant wouldn't need evidence only Dohos can produce in order to claim one. What's missing is the input that structure needs to actually produce a number — the target percentage itself, and the percentage of fees a miss would credit back.
A credit, once one exists, isn't intended to be the only remedy available for something more serious than a missed availability number — a security or payment failure follows its own process, described on incident response, regardless of what the availability figure for that period turns out to be. A safety or security event is never averaged into the availability percentage as if a well-handled incident could offset it — the two stay on separate tracks, with separate remedies, on purpose.
07The fallback that doesn't wait for a percentage
One thing holds regardless of where the SLA numbers eventually land: an unreachable call doesn't go to silence. It's forwarded to a number the restaurant has already set, the same way it would have been handled before Dohos was answering it. That behavior is a property of how the system is built, not a contractual term — which is exactly why it doesn't need a signed percentage to be real today. Detail is at reliability.
08Reporting suspected downtime
A restaurant that suspects an outage reports it through support. Once an availability target exists, a claim against it would be checked against the platform's own recorded events for that period rather than accepted purely on the restaurant's account of it — which protects a legitimate claim as much as it screens out a mistaken one.