Data requests

The two starting points below begin in different places, and the rest of this page walks through what actually happens once a request is in, stage by stage, rather than leaving it as a single “we'll look into it.”

01Where to start depends on who's asking

A restaurant with an active Dohos account manages its own export and deletion directly from its account's own data settings — no separate request needed, no case to open, because the account already has the access. Anyone else — a caller who placed an order, a customer who wants their own information addressed, someone asking on behalf of a restaurant that doesn't yet have an account — starts at Rights request or Contact legal instead. Getting this distinction right at the start saves a redirect later: an account holder who opens a case gets pointed back to their own settings, and someone without an account who tries the settings path won't find one to use.

02What happens once a request comes in

Every request becomes its own case, with its own reference, from the moment it's received — never folded into a general inbox where it could get lost against something else. The first message back confirms that, and is careful not to promise more than it can:

That last line is worth reading carefully, because it's easy to over-share when trying to be helpful. A request moves faster with the right context attached — which restaurant, roughly when, an order or call reference if one exists — not with more sensitive material than the request actually needs.

03Verifying it's really you

Before anything gets disclosed, corrected, or deleted, identity gets checked — proportionate to what's being asked for, never a blanket demand for a government ID or a password:

“Proportionate” does real work in that sentence. A request to see what's on file gets one level of verification; a request to delete everything tied to an account gets more, because getting that one wrong is harder to undo. If verification can't be completed to the level a specific, high-risk request actually needs, the honest answer isn't a guess in either direction:

That final sentence matters — a failed verification isn't treated as evidence either way about what Dohos actually holds. It's a statement about the request, not a finding about the underlying data, and it comes with a real path forward rather than a dead end.

04When the request concerns a restaurant's own data

A lot of what a caller's request touches — order history, a call transcript, delivery details — is information Dohos handles on a specific restaurant's instructions, not on its own. When that's the case, the request gets routed accordingly, and the person who submitted it is told exactly that:

Routing to the restaurant doesn't mean Dohos steps out of the picture entirely — the original receipt time is preserved, so nothing about the timeline resets just because the request moved, and Dohos keeps its own separate responsibility for whatever it holds for its own purposes rather than the restaurant's.

05How a request actually gets resolved

What “resolved” looks like depends on what was asked for. Four real outcomes cover most of what happens, and each is stated honestly rather than rounded up to sound more complete than it is. An access request comes back with what was actually found, and an honest account of anything that isn't included:

A deletion request comes back the same way — honest about what's actually gone, and just as honest about anything that isn't gone yet:

That last sentence is a real commitment, not a caveat added for cover — a deletion in an active system can complete before a backup copy has cycled out, and calling the whole thing “deleted” at that point would be inaccurate. A denial — full or partial — always comes with an actual reason and a real way to push back:

And closing a case is never the last word on a subject — closure describes that a specific request has been handled, not that every future question about the same data is now off the table:

06If the automated path can't handle it safely

Some data-rights actions — an export, a correction, a deletion — can't be completed through an automated channel when something about the request can't be safely verified that way. When that happens, Dohos doesn't force it through anyway, and it doesn't silently drop it either:

That's the safety valve behind everything above: an automated system that can't verify something safely doesn't guess its way through it. It stops, and it routes the request to a real case a person handles instead.

07If something doesn't go as expected

• A request comes back needing more information before it can even be routed. Normal for a request that arrives without enough context to identify which restaurant or which relationship it concerns — supplying the location and an approximate date, or a safe order or call reference if one exists, is usually what moves it forward.
• Verification fails and the request is time-sensitive. A failed verification isn't a dead end — it comes with a real next step, whether that's retrying with a different proportionate method or using the appeal path directly.
• The request needs more time than expected. A case that needs longer than usual for a specific, legitimate reason stays open rather than silently stalling — the original receipt date is preserved.
• A closed case turns out to have missed something, or new facts come up later. Closure doesn't waive the right to flag an error or submit a new request about new facts.

08What this page doesn't state

No specific number of days appears anywhere on this page — not for intake, not for verification, not for a final response. The process above is real and has real stages, but no deadline figure for any of them is settled for publication. That's a gap worth naming honestly rather than filling with a number that sounds reassuring but isn't sourced to anything real.