01Where you start depends on who you are
A restaurant with an active account manages its own export and deletion controls directly, from its account's data settings — that's the fastest route for anything about the restaurant's own account, menu, or configuration data.
A person who called a restaurant that uses Dohos isn't a Dohos account holder and doesn't have that kind of settings page — for that person, a request goes through the intake process this page describes, starting at /contact/legal, the real contact route this goes to today.
02What you can ask for
Depending on which law actually applies to the request, the underlying rights typically include:
- confirming whether data about you is processed at all
- getting access to it
- correcting something that's wrong
- deleting it
- getting a portable copy in a usable format
- opting out of a sale or of targeted advertising — categories Dohos's baseline design doesn't do in the first place, but the opt-out right still applies
- withdrawing a consent you previously gave, such as consent to call recording
- appealing a decision you disagree with
Not every one of these applies to every request — which ones do depends on the jurisdiction and the relationship, and that gets sorted out as part of triage, described next, rather than assumed up front.
03What happens after you submit
A submitted request becomes a single case with its own identifier — not a message that can get lost in a general inbox. From there, someone specifically responsible for privacy requests determines whether it's really a privacy request, a support issue, or something else entirely; who the person making it actually is and what their relationship to Dohos or to a specific restaurant is; and which jurisdiction's rules, deadlines, and exceptions apply to it.
Where the request concerns a restaurant's own customer relationship rather than data Dohos controls directly, it gets routed to that restaurant promptly — the clock on when it was originally received doesn't reset just because it changed hands, and a restaurant's silence doesn't make the underlying obligation disappear.
04Verifying who's asking
Verification is sized to the actual risk of getting it wrong, not applied at one fixed level regardless of what's being asked for. A request to correct a phone number needs less proof than a request to hand over a call transcript. What verification never asks for: a full government ID, a password, a biometric sample, or a new Voiceprint created just to prove identity — the process is designed not to create new sensitive data in the course of protecting existing data.
An authorized agent acting for someone else can submit a request too, but the agent's own authority to act gets checked, and for anything high-risk, direct confirmation from the actual individual may still be required — an order number or a phone number alone isn't treated as proof that someone has authority to act for another person.
05Where the search actually looks
Finding everything responsive to a request means checking every system that's actually in scope, not just the obvious one. That includes account and order records, support tickets, consent and suppression records, and — this is worth being specific about — the standard call-transcript store, which is part of the ordinary search scope the same way order records are, not something that only gets searched if a restaurant separately approved keeping it. A separately enabled audio-recording store, where one exists for a specific restaurant, is searched too, but its existence is the conditional part — the transcript store's existence is not.
Whoever owns a given system has to actually run the search and report back what they found — "no results" without a description of what was actually searched isn't accepted as a complete answer.
06What can be refused, and why
A request can be denied or partially denied only where a specific, identifiable legal exception applies — an active legal hold, a security risk, a conflict with someone else's rights — never on a generic, unexplained "security" or "business reasons" basis. Where something is denied, the response is required to say what was done, what wasn't, and why, to the extent the law allows explaining it.
No denial or partial denial is made by an automated system alone — a person accountable for the decision reviews it.
07Appealing a decision
Where an appeal right applies, it goes to a reviewer who wasn't the one who made the original decision, wherever that's practically possible. The reviewer looks again at jurisdiction, identity verification, whether the search was actually complete, and whether the exception that was applied actually fits the facts — not just a rubber stamp on the first answer.
An appeal outcome — whether it confirms, changes, or reverses the original decision — feeds back into how future requests are handled, rather than disappearing once that one case closes.