dohosGet started
PLATE Nº 085 · DOCUMENT

Caller data

TARGET-STATE DRAFT — NOT APPROVED OR EFFECTIVE
STATUSTarget-state draft
LAST REVIEWEDNone yet — no review has run
CONTACTvia /contact/legal
DRAFT NOTICEThis page explains what is and is not captured about a person who calls a restaurant that uses Dohos, and corrects an internal drafting error that would have described a standard call record as something it is not. It describes the target design for every call, not a report on a specific call, restaurant, or time period.

01A caller is not an account

Calling a restaurant that uses Dohos doesn't create a Dohos account, a login, or a profile a caller can sign into. There's no consumer portal, and nothing gets built that follows a caller from one restaurant to a different one they happen to also call — each restaurant relationship stays separate. What exists instead is a record tied to that specific call, at that specific restaurant, for that specific order or question.

02What's captured during an ordinary call

For an order: whatever identity information the fulfillment method actually requires — a name for pickup, or a confirmed name, delivery address, and callback number for delivery — plus the caller ID number when it's available, and the structured order itself once one exists. For a question that doesn't turn into an order — asking about hours, or whether a specific item is available — there may be no order record at all, just the fact that the call happened and what it was about.

Beyond that, a text transcript of the completed call is generated and kept, and — separately, only where a restaurant has turned it on and disclosed it — the audio recording itself.

03The transcript, specifically

CORRECTEDThis page corrects a drafting error that appeared in an earlier internal version of Dohos's data policy, which described a call's text transcript as something that exists only if a restaurant opts into it — the same way a recording does. That's backwards for the transcript specifically. A completed call produces a text transcript as standard practice, visible only to staff whose role permits it and only for the retention window described at retention. The recording — the actual audio — is the one that needs a restaurant to separately turn it on.

That transcript is treated as uncertain, derived text, not an infallible record — speech recognition can mishear a word, and the transcript preserves what the system understood, which is why the structured order itself, confirmed back to the caller before submission, is what actually governs the transaction, not the transcript text.

04Recording, separately

Audio recording is off by default, independently of the transcript, and turns on only when a specific restaurant has enabled it and disclosed it. Where it's on, that's stated to the caller at the start of the call, consistent with the applicable state recording rules — recording never happens silently, and a call is never described as recorded when it isn't, or left ambiguous when it is.

05What never gets captured, on purpose

A caller's card number, security code, or any other payment credential is never supposed to enter a transcript, a recording, or any ordinary log — and that's actively enforced during a call, not just a policy statement. Before speech that looks like payment-card information reaches storage, a log, or a model, the system is designed to detect it, stop capturing it, and redirect to the secure payment step instead of continuing to listen. If digits were spoken, they're never repeated back.

Also never captured: a Voiceprint or any other biometric identification of who's speaking, an inference about a caller's emotional state, health, or any other protected characteristic, and any assumption about a caller's age or identity drawn from how they sound rather than from what they actually said.

06What doesn't get built from this

None of what's captured during a call is used to build a cross-restaurant profile of a caller, to advertise to them, or to train a general model — see AI training for the direct answer on that last point specifically. A caller who receives a text order confirmation has opted into that one specific transactional message, described at the communications-consent disclosure — that consent doesn't extend to marketing, and marketing requires its own separate basis.

07If you want to know more about a specific call

This page describes the general design. For a question about what was actually captured on one specific call — yours — submitting a rights request is the way to ask, whether you're the caller or the restaurant that received the call.