Support

01How to reach Dohos

A restaurant with an active account opens a request from inside the console at in-console support, which carries the account and location context automatically rather than asking a restaurant to re-explain who they are. Anyone reaching out before or outside an active account uses contact support instead.

02Verifying who's asking

Support checks who's asking, proportionate to what's being asked for. Knowing an email address, an order number, or a restaurant's name isn't by itself enough to get account data disclosed, a payment or communications setting changed, or data exported or deleted — that requires actually confirming the person has the authority to ask. The one exception is an active security threat: emergency containment can happen before verification is complete, but restoring access or disclosing anything afterward still goes through the normal check.

03How a request is prioritized

A request is sorted into one of four priorities based on how much of the service is affected and whether there's a safe way to keep operating in the meantime — the same structure described on the SLA page, applied here to how a request actually gets worked rather than to how a contractual percentage gets calculated. A currently-open location that can't take orders is handled differently from a configuration question that can wait until after service.

• Critical — the service is down or unsafe for a location right now, with no workaround
• High — a real capability is degraded, and any workaround is limited or burdensome
• Medium — something non-critical is impaired, but a reasonable workaround exists
• Low — a question, a cosmetic issue, or a feature request

04What Dohos does with a request

Once a request comes in, it's meant to be triaged, owned by a specific person, and actively escalated rather than left to sit — and whoever owns it is expected to be clear about which part of a problem is actually Dohos's to fix, versus the restaurant's own equipment, a payment provider, or a phone carrier. A case isn't meant to be closed just because a provider's own ticket is open or their dashboard looks healthy; it closes when the restaurant's actual problem is verified fixed, checked from the restaurant's side of it, not just the provider's.

Evidence a restaurant sends in — logs, screenshots, a description of what happened — is handled the same way any other account data is: minimized, protected, and not repurposed beyond solving the ticket.

05What helps a request move faster

A request is faster to work when it names the affected location and capability, roughly when it happened, and any order or call ID already in hand — support shouldn't need to ask a restaurant to re-prove something it can already see in its own systems. A restaurant isn't expected to diagnose root cause before reporting; that's Dohos's job once notified.

• The affected location and capability
• Roughly when it happened
• Any order or call ID already available
• What was actually seen, not just "it's broken"

06Escalating a request that isn't moving

A request can be escalated through its own existing thread rather than by starting a new one, which keeps the history attached instead of scattering it across multiple tickets. The clock on a request is only meant to pause when Dohos has genuinely asked the restaurant for something and is waiting on it — not as a way to make a slow response look faster than it was, and not through repeated, minor information requests used to stall.

07Language and accessibility

Support, legal notices, incident updates, and remedies are meant to reach a restaurant through an accessible method — an authorized person isn't meant to lose a right, or a response, solely because they can't use one particular channel. Exactly which languages support is staffed in, and what hours that staffing actually covers in each time zone, hasn't been published yet; it's the same schedule gap named above, not a separate unstated one.

Related documents

• Service level agreement — the contractual side of the same support-hours and response-time gap, from the schedule itself.
• Incident response — what happens when a request turns out to be a security or availability incident rather than an ordinary support case.
• Contact support — where to start a request before or outside an active account.
• Contact security — where a suspected security issue goes instead.
• Availability overview — where this page sits alongside the other three.
• Vendor packet — this page's underlying schedule alongside the rest of the procurement bundle.