Privacy & accessibility
A person's relationship with Dohos itself, rather than with any specific order or call. A caller has a stake in what's kept about them the moment they're on the phone, whether or not they ever order anything — and anyone has a stake in actually being able to use the site, the console, the tablet, or the voice channel itself.
The three articles here don't share a single shape. One is about a fact that already exists and simply needs to be stated correctly and precisely, once. The other two are about a process — something a person sets in motion, that then moves through real stages before it's resolved. Reading the three as one undifferentiated group risks missing that difference.
Who's asking also varies more here than in most other topics in this section. A question about what's kept from a call can come from the caller themselves, mid-call or afterward. A data request can come from a restaurant's own account holder, or from a caller who has no account with Dohos at all. An accessibility report can come from a caller, from a restaurant's own staff, or from anyone encountering the public site directly. None of the three articles assumes a single kind of person is asking.
Recording and transcripts is the one place in this section that states its exact mechanism precisely, and every other mention of the topic anywhere else in this section points back to it rather than repeating it — getting this specific distinction wrong is one of the easier honest mistakes to make, which is exactly why it has its own dedicated explanation instead of a passing mention here.
The other two are processes, not facts, and share a shape worth knowing in advance: neither resolves in one step, and neither is something Dohos can honestly claim is finished the instant it's reported. A data request has to be verified before anything is disclosed or changed, precisely so that someone else's data can't be pulled by claiming to be the wrong person — a short delay while identity gets confirmed, proportionately, is a protection rather than friction for its own sake. A reported barrier has to actually be confirmed and fixed, not just acknowledged, before anyone can honestly say it's resolved.
Neither privacy nor accessibility here depends on a transaction ever happening. Someone can ask what's kept about a call they made without ever having placed an order on it. Someone can report that the site or the voice channel was hard to use without ever having gotten far enough to order anything at all. That's the real thread connecting the three articles above, and it's also the reason this topic exists separately from Orders & menu, Payments, or Calls — those three assume something transactional is underway; this one doesn't need to.
None of the three articles is something Dohos resolves alone, in secret, and simply announces as done. A transcript's handling is stated openly rather than left ambiguous. A data request moves through a process specifically because a person other than Dohos — the requester — has a stake in how it's verified and resolved. A reported barrier gets confirmed as fixed through actual retesting, not just a claim that it's been addressed. That same discipline is why neither process-shaped article promises a specific deadline anywhere in its own text — a stage that's genuinely still in progress is described as in progress, not attached to a date invented to sound more reassuring.
A caller who's simply hard to understand mid-call, and the accommodation offered in that specific moment, belongs under Calls instead — a live, in-the-moment communication difficulty during an active conversation, a different situation from reporting a standing barrier to using the site or the console at all. The two are easy to conflate, but a mid-call accommodation is resolved by the conversation continuing differently, while a reported barrier is resolved by something about the product actually changing.
This topic also isn't where a restaurant manages its own account's data directly — export, deletion, or account-level settings for an active account are handled from within the account itself, distinct from the request process described here, which exists for everyone else. And it isn't the place for a broader claim about how secure Dohos is in general, or what certifications it holds — that's a separate, much larger topic living outside this help section, in the pages built specifically to answer a security or procurement reviewer's questions in full.
None of the three articles above is written to persuade anyone that Dohos handles data or accessibility especially well — each simply states what actually happens, including the parts that take real time or require real verification. If one still doesn't settle it, write to support — a real person reads it. Name the location, what you were doing, and any order or call reference you have.