Privacy Policy

In short. Deskadora provides booking, menu and messaging tools to restaurants. For most of the personal data on the platform (a diner's booking details, a caller's call, a WhatsApp message to a restaurant) the restaurant decides why and how the data is used and we process it on its behalf. For our website, demos, restaurant accounts, billing and security we decide ourselves. This page says which is which, what we collect, which AI providers see what, how long we keep it and how you use your rights.

1. Who we are and our roles

1.1 "Operator", "we", "us" and "Deskadora" mean Deskadora Europe SASU, 60 Rue François 1er, 75008 Paris, France, SIREN 993 470 319, RCS Paris 993 470 319, share capital 1 000 EUR, VAT number FR27993470319, or any company to which the Operator's rights and obligations are transferred under clause 20.

1.2 We are the controller for the personal data of: visitors to deskadora.com; prospects, including people who use our demo restaurant builder or receive our demo call; restaurant account holders and their staff; billing, invoicing and tax data; security and fraud prevention; support correspondence; and the diner-side technical data that we collect ourselves on our own domains (see 1.5).

1.3 We are the processor for guest data collected by restaurants through the platform: booking details, guest records and notes, deposits, calls to a restaurant's AI voice assistant, WhatsApp bookings and the restaurant's messages to its guests. We act on the restaurant's documented instructions under the data processing agreement in our Terms.

1.4 The restaurant is the controller of its guest data. If you are a diner and want to see, correct, delete or object to the use of your data, contact the restaurant first. You may also write to us at [email protected] and we will pass your request to the restaurant or act on its instruction, as clause 14 explains.

1.5 Deskadora itself collects some diner-side technical data on its own domains and products: privacy-consent choices, analytics and advertising identifiers (only with consent), error monitoring and first-party menu-visit counts. We treat ourselves as controller of that data.

1.6 This policy does not cover employment or recruitment data, which are governed by separate notices.

2. Contact and privacy contact

2.1 Contact for privacy questions and requests: Deskadora Europe SASU, 60 Rue François 1er, 75008 Paris, France; [email protected].

2.2 Privacy contact: Marius Hîncu, [email protected].

3. What we collect, by audience

3.1 Visitors to our website. When you visit deskadora.com we receive your IP address, browser and device details, the pages you request, your language, and your cookie choices. Our security provider protects the site and our bot protection checks forms. With your analytics and marketing consent we also receive analytics and advertising identifiers (clause 7). If you write to us through a form we receive what you type.

3.2 Prospects and demo users. The demo restaurant builder (deskadora.com/try) stores what you type about your restaurant (name, address, menu, description) in a draft that is deleted after 24 hours unless you claim it by registering, and sends the restaurant description to our AI provider for translation. If you give your email address we keep it as a sales lead, and we send it to our advertising measurement provider only if you have given marketing consent.

3.3 Demo call. If you ask for a demo call, we collect the phone number you give (stored encrypted, with its last four digits, country and language), a hashed form of your IP address, your user agent, the call status and the time you ticked the consent box. An AI voice assistant calls that number once for about two minutes. The call is transcribed and the transcript is stored with the call record. Call audio is processed live by our telephony and speech providers (clause 5.10).

3.4 Restaurant account holders and staff. We collect names, work email addresses, phone numbers, roles, login and session data (session events with IP address and user agent, device identifiers), push notification tokens for the staff app, and the actions staff take in the platform (audit logs). On the staff app, error monitoring runs without a consent banner; it records errors, device and app information. Push notifications sent to staff devices contain the guest's name, date, time, party size and table, which pass through our push notification providers, including the device maker's push service for iPhones.

3.5 Billing and company data. Company name and address, VAT number, billing email, invoices and payment status. Venue and representative identity and bank details for onboarding go directly to our payment processor. We validate a venue's VAT number with an external VAT validation service and store only the result. Card data is entered with our payment processor and is not stored by us.

3.6 Policy acceptance records. When a venue signs up, we record its acceptance of the Terms (including the data processing agreement) and this Privacy Policy: version, language, time, IP address, source and user agent.

3.7 Guests and diners (where we are processor). When a diner books through a restaurant's page, widget, WhatsApp or phone line, the restaurant receives and we store: first and last name, email, phone number, date, time and party size; optional special requests, dietary preferences, birthday and anniversary (month and day only); the restaurant's own notes and tags; booking reference; and deposit status. Card data is entered with our payment processor. If the restaurant connects its point-of-sale system, guest records and order history may also be imported from it.

3.8 Guest acceptance records. For each booking we record the guest's tick of the Guest Terms and this Privacy Policy, the versions, the time and, for deposit bookings, a snapshot of the deposit terms shown.

3.9 Diner menu visits. When a diner opens a restaurant's menu page we count the visit for the restaurant's analytics: QR code, restaurant, language, device type, operating system and browser category, country and city derived from network headers, referrer, and a random identifier kept for the browser tab. No IP address and no full user agent is stored. This counting is not controlled by the cookie banner.

3.10 Callers to a restaurant's AI assistant. We collect the caller's phone number (from the telephone network, in full), the caller's speech (processed live as audio, and kept as a text transcript), the assistant's replies, the outcome of the call, and any booking made. If the number matches a guest record at that restaurant, we load that guest's details (see 5.12 and 5.13).

3.11 WhatsApp users. We receive your WhatsApp number and the messages you send to a restaurant's number or to our shared number, and what you enter in a booking Flow. Messages to and from the restaurant are stored for 30 days and then deleted; the restaurant can read them in its dashboard. Conversation state is deleted 24 hours after the last message (clause 6).

3.12 Owner connectors (MCP). A restaurant employee on a Pro or Enterprise plan can connect an AI assistant of their choice to read the restaurant's data. We record the connection (client registration, tokens, the scopes granted) and the data returned to it. With the basic read scope the connector can see guest names, visit counts, reservation notes, special requests and staff notes; two further opt-in scopes add guest profiles and then contact details. We log reads of guest lists, profiles and contacts. The connector is read-only. The assistant provider the owner chooses is the owner's own service and not our sub-processor.

3.13 Data from third parties. Payment status and identity-check results from our payment processor; messaging identifiers and delivery status from the WhatsApp Business messaging provider, our telephony and messaging provider and email providers; VAT validation results; guest and order data from a restaurant's point-of-sale provider (Zelty or Square) when the restaurant connects it; address suggestions from our address search and maps provider.

4. Purposes, legal bases and retention

4.1 The table below shows each category of data, why we use it, the legal basis, and how long we keep it. Where we are processor, the legal basis is the restaurant's, and the entry shows what we do for it. "R" numbers refer to the retention table in clause 12, which uses the numbering of the retention schedule in Annex II of the Restaurant Terms (R23 to R31 are rows that schedule does not have). The right-hand column says whether the row is true today or depends on a release.

4.2 We do not sell personal data. We do not use guests' personal data for our own marketing.

4.3 We use aggregated and anonymised usage information to run and improve the service.

4.4 Special-category data. Dietary preferences (vegetarian, vegan, gluten-free, halal, kosher, other), allergy and accessibility notes, and free-text special requests can reveal health or religious belief. A spoken request to the voice assistant can do the same. We process such data only on the basis of the guest's explicit consent (Article 9(2)(a)), given in a separate step that is not ticked for the guest in the booking widget and the WhatsApp booking flow, and by spoken confirmation on a call, for the restaurant's use in serving the guest. Without that consent the request is not saved and no dietary tag is suggested from it. The guest can withdraw consent by telling the restaurant.

4.5 The booking form invites guests to enter dietary and accessibility information under "Help us personalise your experience", in a step that can be skipped. That information is saved only after the guest gives the explicit consent described in clause 4.4, in a separate step that is not ticked for them.

4.6 Our tools also derive such data from what guests write. A rules-based step fills dietary preference flags (vegan, vegetarian, gluten-free or coeliac, halal, kosher) and, if empty, birthday and anniversary from the free text. An AI step classifies the free text into fixed tags, including Allergy, Peanut allergy and Wheelchair, to help staff. There is currently no switch to turn this off for one guest. A guest can ask the restaurant to correct or remove a tag or note.

4.7 Staff see these tags and flags in their guest records. We do not use them to refuse a booking or to change a price.

5. AI processing

5.1 We use a language model provider, in the United States, as a processor for the AI features described below. The features send only the fields listed. We do not set a region on our requests. The provider keeps the inputs and outputs of our requests for 30 days under its terms for our account. We asked for zero data retention on 2 October 2026 and the provider declined, so the 30-day retention applies.

5.2 Menu allergen suggestions. We send the dish name, description and ingredients. No guest data. Suggested allergens are shown to diners as "may contain", and confirmed allergens as "contains".

5.3 Translation of menus and venue text. We send the text the restaurant wrote (names, descriptions, ingredients, venue description, venue terms). For campaign emails we send the subject and body with the guest-name placeholder left unfilled, never a guest's name. For the demo restaurant builder we send the restaurant description you typed.

5.4 Menu extraction. When a restaurant uploads a menu as a document, photo or text, we send that document (as a temporary link valid for 15 minutes, or directly) so that menu rows can be created.

5.5 Table assignment. We send floor information only: restaurant location name, requested time, occupancy, party size and duration, tables (identifier, name, capacity, area, status), other reservations in a three-hour window (identifier, table, party size, times, status) and walk-ins. No names, contact details, notes, tags, dietary data or guest score.

5.6 Tag detection and translation of special requests. We send the guest's free-text special requests and the restaurant's notes on the booking. These texts may contain a name or health information if the guest wrote it.

5.7 Staff guest briefings. We send, to produce a short briefing for staff: party size, date, visit count, loyalty tier, last visit, birthday and anniversary (month and day), tags, dietary preferences, the restaurant's internal and staff notes, special requests, up to three recent point-of-sale orders (items and totals) and upcoming reservations. We do not include the guest's name, email or phone number as fields. Free-text notes can contain anything the restaurant or the guest typed. Briefings are cached for 7 days.

5.8 Daily insights. We send aggregated figures only.

5.9 WhatsApp chat assistant. When a restaurant has chosen chat mode, for each message we send: a system prompt with the restaurant name, date, time, language, whether a human phone number exists and the last four digits of your WhatsApp number; up to the last 20 turns of what you wrote and the assistant replied (anything you type, including a name, email or allergy); and the results of its tools (availability, hours, menu, prices, allergens, and your own upcoming booking with date, time, party size and reference). We do not send your full phone number or any card data. In Flow mode, no AI model is used.

5.10 Voice assistant: what is processed. Caller audio goes live to our telephony providers and, for transcription, our speech recognition providers (including a separate provider for Romanian where enabled), and the assistant's reply text goes to our speech synthesis providers. Our language model provider receives text only: the live transcript (what you say, verbatim, so names, dictated email addresses and health statements can be included), the assistant's replies, the full caller phone number in the system prompt header, the restaurant name, date and time, the restaurant's booking rules and any text the restaurant added to the assistant's instructions, and tool results (availability, booking reference, confirmation text with date, time and party size). Questions to the venue-information tool go to our language model provider as the question text, with the restaurant's hours, menu and policies.

5.11 Voice assistant: what is not processed. The assistant takes no card data. We do not set any identifier for you in the language model requests.

5.12 Voice assistant: recognised callers, today. If your number matches a guest record at that restaurant, the language model prompt includes your first and last name, your email address in full, your visit count, your dietary preferences and your upcoming bookings (reference, date, time, party size).

5.13 Voice assistant: recognised callers, after the change. For recognised callers the model receives only the first name, a masked form of the email address, the visit count and upcoming bookings (reference, date, time, party size). It does not receive the last name, full email, dietary information, birthday or anniversary. The full caller number remains in the prompt header. The assistant asks about dietary needs on each call and uses only what the caller says.

5.14 Automated decisions about guests. The guest score and the table assignment are staff tools and produce no legal or similarly significant effect: the score is a display for staff based on that restaurant's own counts of bookings, no-shows and cancellations and does not affect any booking, deposit or acceptance; table assignment only chooses where a party sits, using no guest identity. One rules-based process does apply a restaurant's own deposit rule automatically: after the restaurant's configured time following the booking start (15 minutes by default), the system marks an unarrived guest as a no-show and, where the restaurant's rule says so, captures the deposit without review by a person first. This is an automated decision that may have a similarly significant effect on the guest. It is necessary for the booking contract between the guest and the restaurant (Article 22(2)(a)), under the deposit terms the guest accepted when booking. The guest has the safeguards in Article 22(3): the right to human review by the restaurant, the right to express their point of view and the right to contest the decision, by contacting the restaurant or [email protected], which passes the request to the restaurant.

5.15 AI-suggested allergens. Allergens suggested by AI are indicative. They may be wrong or incomplete. Always tell the restaurant about your allergy and confirm with staff before you order.

5.16 AI disclosure in chat. The WhatsApp assistant says at the start of a conversation that it is the AI assistant of the restaurant.

5.17 AI disclosure on calls. At the start of every call the assistant says, in the caller's language, that it is an AI assistant, that the call is transcribed to handle the booking and for quality, that the call may be recorded for quality and monitoring purposes, and that the caller can ask for a person.

5.18 Recording. Calls are transcribed in real time. Deskadora and our telephony provider do not store the audio; our real-time audio provider keeps traces, transcripts and audio of assistant calls for 30 days, as clause 5.19 states. We keep a text transcript (clause 12, rows R2, R3, R6-R8).

5.19 Recording settings at the telephony and real-time providers. Our telephony provider's numbers are set not to record calls. Our real-time audio provider has agent observability switched on for the project that serves EU venues, which is pinned to the European Union (Frankfurt): traces, transcripts and audio of assistant calls are kept there for 30 days on every plan and deleted automatically. Redaction of personal data (name, contact details, demographics, credentials, network data, financial data, location and identifiers) applies to new sessions since 9 October 2026, is best effort and detects personal data in English only. Our own transcripts are kept for the periods in clause 12 (rows R2 and R3).

5.20 Recognising callers by number. The assistant recognises returning callers by the number they call from. A number can be shared or spoofed and is not proof of identity. A caller who knows a booking's reference, or calls from the number on the booking, can change that booking.

5.21 Staff call transfer. If a caller asks for a person, the assistant announces the transfer and connects the call to the restaurant's number through our telephony provider.

6. WhatsApp

6.1 Two ways to reach a restaurant. Through Deskadora's shared WhatsApp number (the restaurant is identified by a link or QR code) or, if the restaurant has connected it, through the restaurant's own number via the WhatsApp Business messaging provider's embedded sign-up.

6.2 Flow mode (default). A text to the number returns a booking form (a WhatsApp Flow). What you enter (date, party size, time, name, email, optional notes and optional marketing opt-in) is exchanged over an encrypted channel with our server. The phone number comes from your WhatsApp identity. No AI model is used.

6.3 Chat mode. Conversations with the AI assistant are described in clause 5.9. Chat bookings are recorded without a deposit and without marketing consent.

6.4 What is stored. Messages to and from the restaurant (chat mode turns and Flow submissions, in both directions) are stored in our database for 30 days and then deleted; the restaurant can read them in its dashboard. Conversation state (what the assistant needs to continue, including message text and your number) is held in memory and deleted 24 hours after the last message. Our usage record keeps the template name, language, the last four digits of the recipient number, country, status and cost. Jobs waiting in our processing queue can hold message text and phone numbers until newer jobs push them out; there is no time limit.

6.5 Booking messages. Confirmations, reminders, cancellations, no-show notices and deposit links are sent as WhatsApp utility messages (with SMS or email as the restaurant configures) to the phone number given for the booking. These messages are not marketing.

6.6 Stopping messages. We do not yet have a STOP keyword or a WhatsApp-specific opt-in. To stop booking messages by WhatsApp, tell the restaurant or write to [email protected].

6.7 The messaging provider's role. The WhatsApp Business messaging provider acts as our processor for message content and as an independent controller for its own account and messaging data under its terms.

6.8 When a restaurant uses its own number, messages the restaurant sends from its own phone are not stored by us.

6.9 Disconnecting. A restaurant administrator can disconnect WhatsApp in settings. Disconnecting removes the stored access token, the Flow key and the number registration data.

7. Cookies and similar technologies

7.1 Our Cookie Policy lists each cookie and storage item: https://deskadora.com/en/cookies.

7.2 We ask for your consent to analytics and to marketing separately, in a banner. On the website its buttons read "Accept all", "Decline" and "Settings"; in the partner dashboard and the guest app they read "Accept", "Reject" and "Cookie settings". Strictly necessary items (security, login, language, consent choices, bot protection) do not need consent.

7.3 Nothing for analytics or marketing is loaded before you consent: our analytics tag, analytics service, advertising pixel and browser session replay (error-only and masked, after analytics consent) are not loaded, and browser error-monitoring session tracking and traces are off until you consent. This applies on the website, the restaurant dashboard, the guest app and the booking widget.

7.4 You can change your choice at any time with the cookie settings in the page footer. Withdrawing consent stops those tools from loading on later pages. Cookies already stored stay until they expire or you delete them in your browser.

7.5 Your choice is stored in a cookie for each site separately (deskadora.com, partner.deskadora.com and app.deskadora.com), so a choice on one site is not seen by the others.

7.6 The staff mobile app uses error monitoring from the first start without a consent banner, and does not use advertising identifiers or analytics SDKs.

7.7 Counting menu visits (clause 3.9) and the security cookies and checks described in the Cookie Policy are not controlled by the banner.

8. Marketing

8.1 Restaurants send marketing by email only. We do not send marketing by SMS or WhatsApp, and WhatsApp messages from the platform are booking-related utility messages.

8.2 A restaurant's marketing campaign goes only to guests who ticked the separate, unticked marketing box and are therefore recorded as having agreed to receive marketing. Every campaign email states why you receive it.

8.3 Every campaign email has a working unsubscribe link and a one-click unsubscribe header. Unsubscribe links are signed so that nobody else can unsubscribe your address.

8.4 Unsigned legacy unsubscribe links, still accepted until the setting is changed, will be rejected once it is.

8.5 An unsubscribe applies to the restaurant that sent the email. We keep your email address on that restaurant's suppression list so that we honour it.

8.6 Campaign emails contain an open-tracking pixel and tracked links. We store counts and times per message, not your IP address or user agent. This tracking is always on in campaign emails.

8.7 About one hour after a completed visit, a guest can receive a one-time email with a link to the restaurant's page on a review platform, if the restaurant has set one. This is not a marketing campaign.

8.8 We use our advertising measurement provider's server-side conversion interface and its pixel to measure our own advertising for restaurant sign-ups and demo leads, and the pixel runs on restaurant booking pages. We do not use the conversion interface for guests or campaign recipients.

8.9 Our sign-up lead events to our advertising measurement provider (hashed email, phone, names, city, postcode and country, plus IP address, user agent and browser identifiers) are sent only if you gave marketing consent in the cookie banner.

8.10 The subscription-renewal event to our advertising measurement provider is switched off for all restaurants.

9. Recipients and sub-processors

9.1 We do not sell personal data. We share it only with the recipients in this clause.

9.2 We use sub-processors in these categories: hosting and storage; payment processing; telephony and messaging; speech recognition and synthesis; language models; email delivery; push notifications; analytics and security (including bot protection and advertising measurement); and address search and maps. Each is bound by a written data processing agreement consistent with Article 28 of the GDPR, and acts only on our instructions except where it is an independent controller for its own purposes. The current list of sub-processors, with the service, data categories, processing location and transfer safeguard for each, is at [link to the sub-processors page].

9.3 Self-hosted by Deskadora on our hosting provider's Paris host (not third parties): MySQL, Redis, Strapi (policy pages, blog) and its Postgres, the Grafana, Loki and Prometheus monitoring stack (14-day log retention). A geolocation database is stored locally; no personal data is sent to its publisher.

9.4 The AI assistant a restaurant owner connects through the owner connector (for example Claude or ChatGPT) is not our sub-processor. It is the owner's own service.

9.5 Guest data is also available to the restaurant concerned and its staff, and, where the restaurant connects a point-of-sale system, to that provider.

9.6 We also disclose personal data where the law requires it, to our professional advisers under a duty of confidentiality, and to a successor Operator under clause 20. Our payment processor also acts as independent controller for fraud prevention and regulatory duties.

9.7 If we add or replace a sub-processor, we update this list. We also notify every enabled Venue Administrator (as defined in the Restaurant Terms) by email at least 30 days before the change takes effect. A restaurant may object under the data processing agreement in the Terms.

10. International transfers

10.1 Our production hosting (servers, database and queue store) is in Paris, France. Our main file storage for uploads and media and our database backups are in the United Kingdom (London). We therefore process data in the EU and the United Kingdom (adequacy decision), and some providers process data in the United States (clause 10.3).

10.2 Transfers from the EU to the United Kingdom rely on the European Commission's adequacy decision for the United Kingdom.

10.3 Some providers process data in the United States under the EU-US Data Privacy Framework or the European Commission's Standard Contractual Clauses; the current list is at [link to the sub-processors page].

10.4 For individuals in the United Kingdom, where UK GDPR applies, we rely on the UK adequacy regulations for the European Union, on the UK Extension to the EU-US Data Privacy Framework where the provider is certified, and on the UK Addendum or the UK International Data Transfer Agreement where the provider's terms include one.

10.5 You can ask for a copy of the safeguards for a given transfer at [email protected].

11. Security

11.1 We protect data with access controls by role, field-level encryption (AES-256-GCM) for WhatsApp tokens, point-of-sale credentials and demo-call phone numbers, TLS for data in transit, monitoring and security logging, and bot protection on login and forms.

11.2 Our file storage (uploads and media) and the database dumps we keep in object storage are encrypted at rest with SSE-S3, and the volume of our production server that holds the database is encrypted at rest with EBS encryption.

11.3 A Deskadora support agent can open a restaurant's dashboard only after the restaurant's administrator is emailed a one-time code and gives it to us. The session lasts at most 30 minutes. Actions that change data are logged. Reading data in such a session is not logged.

11.4 The staff mobile app protects access with a PIN of its own.

11.5 No method of transmission or storage is completely secure. We review our controls regularly.

12. Retention

12.1 The table shows how long we keep each kind of data. Where a period is "not set", we say so and keep the data only as long as needed for the purpose in clause 4.

13. Personal data breaches

13.1 If a personal data breach occurs we investigate and contain it, document it, notify the CNIL within 72 hours where Article 33 of the GDPR requires it, and tell affected people without undue delay where there is a high risk to them (Article 34).

13.2 Where the breach affects guest data we process for a restaurant, we tell the restaurant without undue delay so that it can meet its own duties.

14. Your rights and how to use them

14.1 You have the rights of access, rectification, erasure, restriction, portability, objection to processing based on legitimate interest, and withdrawal of consent at any time without affecting earlier processing.

14.2 If you are a diner, contact the restaurant first, because it decides how your data is used. You can also write to [email protected] from the email address or phone number you used. We will tell you who the restaurant is and pass the request on, or act on the restaurant's instruction.

14.3 If you are a restaurant owner or staff member, or a visitor or prospect, write to [email protected]. We decide those requests ourselves.

14.4 We reply within one month. Where a request is complex or numerous we may extend by up to two further months and will tell you within the first month.

14.5 We may ask you to confirm your identity before acting on a request.

14.6 Withdrawing marketing consent is free: use the unsubscribe link, the cookie settings or write to us.

15. How erasure works

15.1 We erase personal data on a valid request, except where the law requires us to keep it. What happens depends on who asks.

15.2 A restaurant account. When a restaurant closes its account, or when an inactive account is purged, a single erasure routine deletes the restaurant's guest records, reservation personal data (notes, special requests, staff notes), voice calls and transcripts, campaign content and sends, the point-of-sale links and data, menus and media, audit log entries, push tokens, staff device sessions and leads linked to the restaurant, and anonymises staff, location and restaurant records. It disconnects WhatsApp and removes its tokens, and cancels the subscription.

15.3 What is kept, and why. The routine keeps, for up to 10 years, the accounting records the law requires: deposits, reservation fees, financial transactions, subscriptions, invoices, billing details (company name, address, VAT number), and usage totals, with personal data removed or minimised. It keeps empty shell records (restaurant, locations, staff, and only those reservations a kept record points to) with legal name, address, company number, VAT number and payment processor identifiers on the restaurant record, so that the accounting records stay consistent.

15.4 Report. When erasure finishes, the restaurant receives an email with a report of counts, and a status of "completed" or "completed with errors", in which case we retry.

15.5 Timing. Self-service closure runs as soon as it is requested.

15.6 A guest's data, today. A restaurant (or we, on its instruction) can erase a guest's record. This deletes the guest record and its tags, clears the guest's link, notes and special requests on their reservations, and deletes their marketing opt-in record and stored picture. It does not yet clear staff notes, translated special requests, voice data, table session names, reviews, campaign sends, POS links or audit log entries.

15.7 A guest's data, after the change. The routine also clears those items and, where the request gave us an email address, tells the data subject when it is done.

15.8 There is no self-service form for guests to request erasure on our site. Guests ask the restaurant or write to [email protected].

15.9 What we cannot reach. Copies in database backups, object-storage versions and queue payloads, and provider-held copies at our payment, telephony and messaging, speech, language model, analytics and security providers, are not removed by our routine. They expire under our backup and queue rules and each provider's own retention.

16. Automated decisions

16.1 We take no decision about guests with legal or similar effect based on profiling or AI, except the automatic no-show deposit capture described in clause 5.14. The safeguard of Article 22(3) for that decision is this: the guest can write to [email protected], a person reviews the decision, and we reply within one month.

16.2 Plan change after cancellation. When a restaurant's subscription is cancelled and no replacement subscription exists, the account is automatically moved to the Free plan. Data is kept and access to paid features is limited.

16.3 Inactivity. If a restaurant account shows no activity for 60 days, we warn every enabled administrator by email and show a banner in the partner dashboard, and we email again at 83 days, seven days before dissolution. At 90 days the account is dissolved: it is disabled and an export is emailed. Activity means dashboard logins, staff app sign-ins, reservation changes, completed guest bookings (widget, WhatsApp, voice), API calls and menu changes. Pilot and demo accounts are excluded. We keep the delivery logs of these emails as evidence of notice for 5 years after the account is dissolved.

16.4 After dissolution the subscription is cancelled and, after a 30-day grace period, the account's data is erased as in clause 15.

16.5 Today, dissolution disables the account and keeps all data.

16.6 You can ask for human review of any of these decisions, state your point of view and contest them at [email protected].

17. Children

17.1 Our services are business tools for people aged 18 or over, as in our Terms. Guests booking a table must be 18 or over. We do not knowingly collect data from anyone under 18 and will delete it if we learn we have.

18. Supervisory authorities

18.1 You may complain to the CNIL (France), our lead supervisory authority: https://www.cnil.fr.

18.2 If you live in the United Kingdom you may complain to the ICO: https://ico.org.uk. Otherwise you may complain to the supervisory authority of your country (for France, the CNIL, which is also our lead authority).

18.3 If the Operator is transferred to Deskadora Europe SRL (Romania), the lead supervisory authority becomes the Romanian ANSPDCP (Autoritatea Națională de Supraveghere a Prelucrării Datelor cu Caracter Personal), and we will name it here from the date of the transfer.

19. Changes to this policy

19.1 We publish each version with its version number and effective date.

19.2 For material changes we email each restaurant's administrators before the change takes effect, at least 30 days before. Diners, managers and employees are told by the notice on this page.

19.3 The email is triggered by publishing the change in our policy system, in English first.

19.4 When a restaurant signs up, its acceptance is recorded (clause 3.6). Existing restaurants can be asked to accept a new version in the dashboard.

20. Transfer of the Operator

20.1 We may transfer our rights and obligations under this policy and the Terms, including as controller and processor, to another company, in particular Deskadora Europe SRL (Romania).

20.2 We will notify restaurants by email to their administrators and on this page before the transfer takes effect.

20.3 From the transfer date, "Operator", "we", "us" and "Deskadora" in this policy mean the transferee, the contact details and company identifiers in clauses 1 and 2 are replaced by its details, and the sub-processor agreements and transfer safeguards continue to apply. Your rights are unaffected.