Availability
How Dohos is designed to keep a restaurant's phone answered, what's already true about that design today, and what a formal uptime commitment will state once one is approved.
This wing summarizes four documents that are each still a target-state draft: the uptime commitment, the continuity and disaster-recovery plan, the incident response plan, and the support model. None of the specific figures a reviewer typically needs from a reliability page — an availability percentage, a support schedule, a response-time target — has been approved yet. Where a number is missing below, every one of the four detail pages behind this one names that same gap directly, in its own words, rather than leaving it unstated.
Two things about how Dohos handles a call hold today, independent of any percentage still being finalized. First, an inbound call is never met with silence: if the voice platform can't take it, the call is forwarded to a number the restaurant has already set — its own line, a manager's phone, wherever calls went before Dohos was in the loop. Fallback routing covers the mechanics; the point for a reviewer is that the failure mode is a call reaching a person, not a call reaching nothing.
Second, a fallback event isn't silent to the restaurant either. It's recorded in the console the same way any other event is, so an owner or manager can see when Dohos couldn't take a call and why — not discover it later from a customer complaint about a call that never came through.
A vendor review usually wants a number here — an availability percentage, a support response window, a credit if either is missed. Dohos doesn't have one to publish yet. The schedule that will eventually state these figures exists as a complete draft, with every clause a signed version would need, but the specific numbers at the end of that structure are the one thing left blank, on purpose, until they can be measured and approved rather than estimated.
- An availability percentage
- Response, restoration, and resolution time targets, by priority
- A staffed support schedule and channel list
- A service-credit formula and cap
- A threshold that defines repeated or chronic failure
Two different questions get answered separately across this wing, deliberately. One is what Dohos is built to do — the fallback behavior above, the tenant isolation described in the security pages, the way an issue gets prioritized during an incident. The other is what Dohos has contractually committed to, with a number attached and a remedy if that number is missed. The first kind of answer can be given today, in full, because it describes a decision already made in the product. The second can't be rushed — a credible commitment needs a measured baseline behind it, not an estimate dressed up as a promise.
Business continuity
Fallback design and degraded-mode behavior.
OPEN →PLATE Nº 072Incident response
Detection, comms, and postmortems.
OPEN →PLATE Nº 073SLA
Service-level commitments — method defined, numbers pending approval.
OPEN →PLATE Nº 074Support
Channels and how requests are handled.
OPEN →Once an availability target, a support schedule, and a credit formula clear internal review, they replace the placeholders on the SLA and support pages directly — not as a new announcement here. This overview will read almost identically on that day, minus the gaps.
A restaurant that suspects Dohos is down or degraded reaches support the same way as any other request, flagged for the faster path described on the support page. Current state is published at status.