dohosGet started
PLATE Nº 088 · DOCUMENT

Retention

TARGET-STATE DRAFT — NOT APPROVED OR EFFECTIVE
STATUSTarget-state draft
LAST REVIEWEDNone yet — no review has run
CONTACTvia /contact/legal
DRAFT NOTICEThis page explains how long different kinds of call and order data are meant to be kept, and corrects an internal drafting error that would have understated what Dohos retains by default. Exact day-count schedules below are targets pending sign-off from counsel, tax, and security reviewers, not published commitments a restaurant can rely on for its own compliance obligations yet.

01What "keeping a recording" can mean

CORRECTEDAn earlier internal draft of this policy said a completed call leaves no transcript behind unless a restaurant separately turns a "transcript capability" on. That's wrong, and this page corrects it. A text transcript of a completed call is the default — not an opt-in add-on. What is genuinely opt-in, gated by its own separate consent, is the raw audio recording. Treating those two as one setting was the error; they are two different mechanisms with two different switches.

Every retention period below is assigned object by object, not as one blanket "we keep data for X" rule — a transcript, a recording, an order, and a payment record each have a different reason for existing and a different justified lifetime, and collapsing them into one number would either overstate what's kept or understate it.

02Call transcripts

A text transcript of each completed call is generated and kept as part of standard service delivery, for a defined default period, then removed on a schedule rather than kept indefinitely by default. Access to it is limited to staff whose role at the restaurant actually needs it — not open to the whole team by default.

A restaurant can shorten that default window for its own account. It's a target-state design decision on which day count is right, still pending sign-off from the reviewers who'd actually approve a specific number, but the mechanism — a role-gated, time-bound transcript, deletable early on request — isn't in question.

03Call audio

Raw audio recording is a separate, explicitly disclosed capability a restaurant turns on for itself — off by default, and independently gated from the transcript described above. Where a restaurant has enabled it, the caller is told at the start of the call, consistent with the disclosure practice described at state recording law.

Where recording is on, the retained audio follows its own schedule, which does not have to match the transcript's — a restaurant can, for instance, keep transcripts for its normal operational window while retaining recordings only for the shorter period an active dispute or quality review actually needs.

04Orders and payment evidence

Order records — what was ordered, at what price, fulfilled how — are kept for a restaurant's own operational and accounting history, and aren't deleted on the same short, rolling cycle as call artifacts. A restaurant generally needs its order history far longer than it needs a specific call's transcript, and the schedule reflects that.

Payment evidence is kept even more narrowly: the minimum non-secret record needed to reconcile a transaction, support a refund, or respond to a dispute — never the actual card number, security code, or other payment credential, which is never stored in the first place regardless of retention period. See why card data never enters Dohos systems for how that boundary works mechanically.

05Backups

A backup exists only to support recovery if something breaks — not as a second, quieter copy for analytics or anything else. Backups are encrypted, restricted from ordinary access, and tested periodically to confirm a restore actually works, not just that a backup file exists.

When something is deleted from the live system — a transcript past its window, an audio recording a restaurant turned off — that deletion has to survive a later restore from backup, not get quietly reintroduced. That's enforced through a deletion marker kept outside the recoverable backup content itself, so a restore reapplies prior deletions instead of undoing them.

07What a deletion request actually goes through

A deletion — whether it's a schedule running its course or an early request — moves through a sequence of states, not a single instant flip from "exists" to "gone":

DELETION REQUEST STATES
  1. requested
  2. validated
  3. blocked-by-hold
  4. queued
  5. executing
  6. completed per system
  7. verified
  8. closed

"Blocked-by-hold" is a real, expected state, not a failure — it means a legal hold covers that specific data, and the request will complete once the hold releases. A request isn't marked complete until deletion is verified across every system it touched, including any vendor that was holding a copy, not just the primary database.

08Asking for something sooner

A restaurant or a caller can ask for something to be deleted before its scheduled date. How to actually submit that request covers the process end to end, including what happens when a legal hold or another retained-record exception applies to part of what was asked for.