1. Definitions and the Operator

1.1 "Operator" means Deskadora Europe SASU, a French simplified joint-stock company with a sole shareholder, registered office 60 Rue François 1er, 75008 Paris, France, SIREN 993 470 319, registered with RCS Paris 993 470 319, share capital 1 000 EUR, VAT number FR27993470319, or any entity to which the Operator transfers these Terms under clause 35.

1.2 "We", "us" and "Deskadora" mean the Operator. Every reference to the contracting entity in these Terms, the DPA and any order form means the Operator for the time being.

1.3 "Venue" means the restaurant or hospitality business that creates an account or signs an order form. "Venue Administrator" means a person the Venue authorises to manage its account. "Staff User" means any other person the Venue authorises to use the platform. "Guest" means a diner or caller who books or enquires with a Venue.

1.4 "Platform" means the websites deskadora.com, partner.deskadora.com and app.deskadora.com, the booking widget, the staff app, the owner MCP connector, the API and related services operated by the Operator.

1.5 "DPA" means the Data Processing Agreement in Annex D, with Annexes I to IV. It forms part of these Terms.

1.6 "Order Form" means the Order Form shown in the Venue's Billing settings (https://partner.deskadora.com/settings/billing), and any other plan page, order form or admin-assigned settings, that record a Venue's plan, prices, usage prices, allowances, locations and any pilot.

2. Who the contract is with

2.1 These Terms are a business-to-business contract between the Operator and the Venue. They are not a consumer contract.

2.2 The Venue is responsible for its Venue Administrators and Staff Users and for everything done through its account.

2.3 Venue Administrators bind the Venue. A person who accepts these Terms for a Venue confirms that they have authority to do so.

2.4 Staff Users use the Platform under the Venue's account and the permissions the Venue grants. They do not have a separate contract with the Operator for the services, but must follow clause 23.

2.5 Guests are not parties to these Terms. Their use of the Platform is covered by separate guest terms.

3. Account and eligibility

3.1 The Platform is for businesses and their staff. Users must be at least 18 years old or of the age of majority in their country.

3.2 The Venue must give accurate and current information, including legal name, address, company number and VAT number, and must keep it up to date.

3.3 The Platform does not currently check a user's age at signup. The Venue is responsible for authorising only eligible people.

3.4 Each Venue Administrator must keep credentials confidential and tell us promptly of any suspected unauthorised access.

4. Acceptance and recording of acceptance

4.1 By ticking the acceptance box at signup, or by signing an Order Form that refers to these Terms, the Venue accepts these Terms, including the DPA, and confirms it has read the Privacy Policy.

4.2 At signup the Platform records, for each of Terms, DPA and Privacy Policy: the version, the language, the time, the IP address and source, and the browser user agent. The marketing preference is a separate box and is not a condition of signing up.

4.3 When the Operator publishes a new version, it may ask existing Venues to accept it again in the Platform.

4.4 Until the recording in clause 4.2 is live, acceptance is by use of the Platform after signup and by the Venue's continued use.

4.5 The Venue may not use features that process Guest personal data unless it has accepted these Terms.

5. The services

5.1 The Platform is a software-as-a-service tool for hospitality venues. Features differ by plan. The features in sections 6 to 17 are available as described there and as the Venue's plan and settings allow.

5.2 We may improve or change features. We will not remove a feature that a Venue has paid for without either notice under clause 33 or a credit of the fees for the affected period.

5.3 Voice and WhatsApp bookings need an administrator toggle or an active pilot, in addition to the plan.

6. QR menu (free tier)

6.1 The Venue can create menus and QR codes and publish them to Guests. On the Free plan, menu items, categories, languages and menus are not limited.

6.2 Each page view from a QR code records an anonymous scan event: venue, menu and QR code identifiers, language, device type, operating system and browser group, country and city, referrer, a random session identifier and the time. No IP address or full user agent is stored. The Venue sees these statistics.

6.3 The Platform may use artificial intelligence to suggest allergens, translate menu text and extract menus from uploaded files. Clauses 22.5 and 22.6 apply.

7. Reservations and booking widget

7.1 The Venue can take reservations through the Guest app, the embeddable booking widget, staff entry, WhatsApp, the voice assistant and connected POS systems, as set up by the Venue.

7.2 The Venue configures its booking rules, opening hours, party sizes, notification channels and automatic actions. Automatic actions include cancelling unpaid deposits, declining pending bookings, enforcing safety windows and cancelling waitlist entries after the estimated wait.

7.3 Reservation notifications go to Guests by email, WhatsApp or SMS, depending on the notification type and the Venue's settings. A failed WhatsApp delivery can fall back to SMS.

7.4 The booking widget shows the Venue's own terms and, before payment, the deposit, cancellation and no-show terms and the Guest terms. The Guest ticks separate boxes for each.

7.5 The Platform records each acceptance with the time, the versions, the deposit conditions shown and a fingerprint of the Venue's terms, and rejects a booking where acceptance is missing or out of date.

7.6 Bookings made through WhatsApp or by voice do not record a Guest acceptance of the Guest terms. The Venue should give its own terms to Guests booking that way.

7.7 The Operator may also send each Guest an email after a completed visit with a link to the Venue's own review page, where the Venue has set one up.

8. Guest CRM and automatic tagging

8.1 The Platform keeps a guest record per Venue with contact details, language, visit history, dietary preferences, notes, tags, marketing preference, and the day and month of birthday and anniversary where a Guest gives them.

8.2 The Platform applies system tags automatically from visit counts and dates (for example New Guest, Regular, Frequent, VIP, Lapsed, At Risk, Birthday Today).

8.3 On every reservation with special requests or notes, the Platform reads the free text with rules and with an AI model to fill dietary preferences, dates and tags such as Allergy, Wheelchair and High chair, and to translate the request into the Venue's language. There is no per-Guest or per-Venue switch for this.

8.4 Free-text and dietary fields can reveal health or religion. The Venue decides whether and on what legal basis it collects them and instructs the Operator to process them for the purposes in this section.

8.5 Staff can add notes and manual tags. The Venue must keep notes factual and avoid unnecessary sensitive details.

9. AI table assignment and guest scoring

9.1 The Platform calculates a guest score per Venue from that Venue's own counts of reservations, no-shows, cancellations and visits. Scores are never combined across Venues. Staff see the score and a no-show risk radar.

9.2 The score has no automatic effect on a Guest's booking, deposit or acceptance. It is an internal staff tool.

9.3 The Venue must not use the score as the sole basis for refusing a booking or requiring a deposit, and must tell the Operator before it intends to do so, so that the parties can review the legal position.

9.4 Where a Venue's location turns on automatic table assignment, an AI model receives the floor state only (tables, capacities, times, party sizes and statuses) and no Guest names or contact data. If the top suggestion reaches the Venue's confidence threshold, the system assigns the table. Otherwise it only suggests one. The effect on the Guest is limited to where they are seated.

9.5 The Venue is responsible for checking AI suggestions, briefings and tags before relying on them. AI output can be wrong.

10. Marketing campaigns

10.1 The Platform sends marketing campaigns by email only. SMS and WhatsApp marketing are not offered.

10.2 A campaign is sent only to guests whose record shows marketing consent, are not on the Venue's unsubscribe list, have a valid email address and are within a 7-day frequency cap.

10.3 The campaign wizard shows the Venue how many guests are excluded for lack of marketing consent.

10.4 Each campaign email carries a working unsubscribe link and the one-click unsubscribe header. Links are signed so that only the recipient can use them. Older unsigned links stay valid until the Operator switches the signature requirement on.

10.5 The Venue is the sender and responsible for the lawful basis of every message, including valid marketing consent where required, accurate sender identity, and honouring opt-outs. The Operator provides the tool.

10.6 Campaign emails record opens and link clicks per send, for the Venue's statistics and for attributing bookings made within 7 days after an open.

11. WhatsApp bookings

11.1 Venues on a plan that includes WhatsApp can take bookings through a Deskadora shared WhatsApp number, reached by a link or QR code that carries the Venue's page identifier.

11.2 Flow mode (the default) shows the Guest a booking form inside WhatsApp. No AI model is used.

11.3 Chat mode lets the Guest write freely. An AI model receives the Guest's free text and the last 20 turns of the conversation, the last 4 digits of the Guest's WhatsApp number and the results of booking tools. It does not receive the full phone number or any card data. The assistant introduces itself as an AI assistant. Chat bookings do not take a deposit.

11.4 A Venue can connect its own WhatsApp number through the WhatsApp Business messaging provider's embedded sign-up, including coexistence with the WhatsApp Business app. In coexistence, messages the Venue sends from its own phone are not stored by the Operator. The Venue's access token and keys are stored encrypted.

11.5 The Platform sends pre-approved utility message templates (for example confirmation, reminders, deposit request and cancellation) in the Guest's language. The Venue may not use the Platform to send marketing content through WhatsApp.

11.6 The Venue is responsible for the WhatsApp Business messaging provider's terms and policies, and for having a lawful basis and any opt-in required to message a Guest. The Platform does not yet interpret opt-out keywords such as STOP.

11.7 A Venue can disconnect WhatsApp from the Platform. Disconnecting removes the Venue's WhatsApp access tokens and stops messaging through that number.

11.8 The WhatsApp Business messaging provider processes WhatsApp messages under its own terms and may act as an independent controller for its own account data.

11.9 The Venue can read its WhatsApp conversations in the dashboard for 30 days; after that they are deleted.

12. AI voice assistant

12.1 Where a Venue turns on the voice assistant, it forwards calls from its public number to a telephone number provisioned by the Operator. An AI assistant answers, can check availability, create, change and cancel bookings, answer questions from the Venue's information and transfer the call to staff.

12.2 At the start of each 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, and that the caller can ask for a person.

12.3 Article 50 of Regulation (EU) 2024/1689 (the AI Act) requires that people who interact with an AI system are informed of it. The assistant gives that information at the start of each call (clause 12.2). The Venue must also display a notice on each of its public channels where it publishes the number that forwards to the assistant (for example its website, its map and search listings, its social media accounts and its printed material), stating that calls may be answered by an automated assistant and transcribed. Annex V gives the sentence in 12 languages. The Venue must handle any further notice that law requires of it as the party deploying the assistant.

12.4 The call is transcribed. Transcripts are stored per call with caller number, time, outcome and the linked reservation. Retention is in Annex II.

12.5 The voice agent does not itself store call audio. The Operator's real-time audio provider keeps traces, transcripts and audio of assistant calls in the European Union (Frankfurt) for 30 days and deletes them automatically. At the start of each call the assistant tells the caller that the call may be recorded for quality and monitoring purposes.

12.6 The Operator does not enable call recording at its telephony provider.

12.7 For a caller whose number matches a guest of the Venue, the assistant receives the guest's first and last name, email address, visit count, dietary preferences, birthday and anniversary and up to three upcoming bookings, and greets the caller by first name.

12.8 For a recognised caller the assistant receives only first name, a masked email address, visit count and upcoming bookings (reference, date, time, party size). It does not receive last name, full email, dietary flags, birthday or anniversary.

12.9 The caller is identified by the number the call comes from. The Platform does not verify identity further, and a caller from a recognised number can change an upcoming booking. The Venue accepts that risk or may leave caller recognition off by not forwarding calls.

12.10 When a caller asks for a person, the assistant announces the transfer and transfers the call to the Venue's transfer number. If no transfer number is set, the transfer is not available.

12.11 Calls are limited by rate limits per caller, venue and platform. A call that does not lead to a booking ends after 5 minutes.

12.12 Voice minutes and per-booking voice charges are billed under the Order Form.

13. Owner MCP connector

13.1 Venues on the Pro and Enterprise plans can let a Venue Administrator or manager with the right permission connect an AI client of their choice (for example Claude or ChatGPT) to read data from the Venue's account.

13.2 The connector is read-only. The server accepts only queries, tokens carry no write scope, and every call is limited to the Venue and locations the token covers.

13.3 Reservation, no-show, transaction and usage tools are available under the base read scope, which can include guest names and reservation notes. Guest list and profile tools need an additional guest scope the authoriser selects, and contact details need a further scope.

13.4 Access tokens last 1 hour and refresh tokens 30 days. If a Venue loses its plan or the user loses permission, access can continue until the current token expires.

13.5 The AI client and its provider are the Venue's own service. They are not sub-processors of the Operator. The Venue is responsible for the AI client's terms, for what it does with the data it reads and for deciding which users may connect it.

14. Staff app and push notifications

14.1 The Operator provides an iOS and Android staff app. It shows guest names, notes, reservations and tables to authorised staff.

14.2 The app sends push notifications for new, pending, cancelled and no-show bookings and guest arrivals. Notifications contain the guest's name, date, time and party size, and are delivered through push notification providers, including the device maker's push service. They can be visible on a locked screen.

14.3 The Venue decides which staff install the app and must require staff to protect their devices, for example with a screen lock.

15. Public venue pages and AI-search visibility

15.1 The Platform publishes a public page for each enabled location with a page identifier. It shows the Venue's name, address, hours, menu with prices and allergen information, contact details and a booking link, in structured data for search engines.

15.2 The Operator permits search engine and AI crawlers to read venue pages. The only way to remove a page is to disable the location.

15.3 The Venue grants the Operator a licence to publish the Venue's content on these pages, as set out in clause 25.3.

16. POS integrations

16.1 A Venue can connect a supported POS system (currently Zelty and Square). The Venue's API key is stored encrypted.

16.2 With a POS connected, the Platform reads closed tickets and line items, matches them to guests, and for Zelty imports customers as guest records and sends reservations back. An imported customer's marketing flag is copied into the guest's marketing consent.

16.3 The POS provider is the Venue's own vendor. The Operator transmits data on the Venue's instruction. The Venue must have a lawful basis for the import and for any marketing consent it copies.

17. Support access and admin impersonation

17.1 Operator staff can open a Venue's account as its Venue Administrator for support only after the Operator emails a one-time code to the Venue Administrator and the Venue Administrator gives the code to the Operator. The code expires after 10 minutes.

17.2 A support session lasts at most 30 minutes.

17.3 Actions that change data during a support session are logged with the Operator staff member's identity. Reads of data are not individually logged.

17.4 A support session can do anything the Venue Administrator can do. Operator staff use it only for the support request and must not use it for other purposes.

18. Plans and fees

18.1 The Free plan has no subscription fee. Paid plans, locations, add-ons, usage prices and messaging allowances are set out in the Order Form. We do not publish prices in these Terms.

18.2 Per-booking usage prices (for example for voice, WhatsApp and RCS (Rich Communication Services) bookings) are set per Venue in the Order Form and are charged in the Venue's plan currency. A usage fee is charged only when the reservation reaches completed status. No usage fee is charged for no-shows or cancellations.

18.3 Each location needs a location licence. A Venue's first location is included as the Order Form states. Extra locations are charged as the Order Form states.

18.4 Plans include monthly allowances for SMS and WhatsApp as the Order Form or plan page states. Use above an allowance, and any add-on credits, are charged as the Order Form or plan page states. Marketing emails are not subject to an allowance or an overage charge.

18.5 Voice bookings are billed per completed booking at the price in the Venue's plan; there is no per-minute charge.

18.6 A Venue can have a pilot for a period agreed in writing. During a pilot the Venue has Pro features, voice and WhatsApp can be turned on, and usage fees are not charged.

18.7 Invoices and plan prices are in EUR, RON or PLN, as the Venue's plan currency states. Where an amount is converted, the Operator uses its daily exchange rate.

18.8 We may change prices on 30 days' notice under clause 33. A price change takes effect at the next renewal after the notice. The Venue may leave without cost before it takes effect.

19. Billing and VAT

19.1 Paid plans renew automatically until cancelled. Subscription fees are charged by our payment processor at the interval the Order Form states.

19.2 Usage charges are invoiced monthly in arrears and collected automatically by card through our payment processor.

19.3 Prices are exclusive of VAT. VAT is added where the law requires.

19.4 The Operator checks the Venue's VAT number through a third-party service at signup and periodically. A valid number from another EU member state can lead to reverse-charge invoicing. The Venue must keep its VAT details correct.

19.5 Fees are non-refundable except where applicable law requires a refund.

19.6 The Venue is responsible for its own taxes. The Operator does not calculate or remit the Venue's taxes.

19.7 Upgrades apply immediately. Downgrades apply at the end of the billing period.

19.8 If a payment fails, the Operator retries it under Stripe's schedule and notifies the Venue. If the payment is still unpaid after the retries, the Operator moves the Venue to the Free plan: the Venue's data is kept and paid features stop. For other breaches of these Terms, the Operator may suspend paid features after notice under clause 30.

20. Trials, cancellation and downgrade

20.1 A Venue on the Free plan can start a 14-day free trial of a paid plan from the Platform billing page; no card is required.

20.2 If a card is on file when the trial ends, the paid plan continues and the card is charged; otherwise the Venue moves to the Free plan. If the first payment fails, we retry under clause 19.8 and, if it is not paid, move the Venue to the Free plan.

20.3 On the Free plan the Platform does not accept online bookings and some management features are unavailable; the Venue's data is kept. While a subscription is unpaid, staff changes may be blocked until the Venue pays; administrators can still manage the account.

20.4 The Venue Administrator can cancel a paid plan in the Platform. It ends at the end of the paid period. Reminders go out 3 days before and on the day.

20.5 When a subscription ends, the Venue moves to the Free plan. Its data is kept and some features are not available. No data is deleted.

21. Deposits and payments

21.1 Deposits are processed by Stripe. The Venue must have a Stripe connected account that has completed verification and is enabled for charges before it can take deposits.

21.2 Deposits are direct charges on the Venue's connected Stripe account. The funds settle in the Venue's Stripe balance.

21.2A The Operator's fee on deposits is set out in clause 21.5 only.

21.3 The Venue is the merchant of record for deposit payments.

21.4 Deskadora never receives, holds or controls deposit funds.

21.5 For each deposit that is captured, the Operator charges the Venue a fixed processing fee of 0.50 EUR. For a deposit in another currency the fee is 2.50 RON, 0.45 GBP, 0.50 CHF, 2.00 PLN, 12.00 CZK, 200 HUF, 5.00 SEK, 4.00 DKK or 6.00 NOK. For a deposit in any currency that is not listed, the Operator charges no fee. The fee is the same whatever the amount captured and wherever the card was issued, and it is never more than the amount captured: where less than the fee is captured, the fee is the amount captured. It applies to every deposit that is captured, including a deposit captured on the Guest's arrival and applied to the bill. It is taken as a Stripe application fee from the captured amount, at the time of capture. The Operator charges no fee on an authorisation hold, on a hold that is released, on a deposit that is not captured, or on a booking where the Guest is seated and no deposit is captured.

21.5A For each deposit the Platform shows the Venue, on the reservation, the gross amount captured, Stripe's fee, the Operator's fee in clause 21.5 and the net amount the Venue receives.

21.5B Stripe's own card processing fee on a captured deposit is not part of the fee in clause 21.5. Stripe charges it to the Venue separately, on the Venue's connected Stripe account, under the Venue's agreement with Stripe, and the Operator does not reimburse it.

21.6 Before saving a card, the Guest sees the deposit amount, that a hold is placed 4 days before the visit, and the Venue's cancellation and no-show terms.

21.7 The Platform places the hold 4 days before the visit and renews a hold that would otherwise lapse before the visit.

21.8 When a capture fails, the failure is logged but the Platform does not notify the Venue or the Guest. The Venue should check its Stripe account and the deposit status in the Platform.

21.9 When a Guest arrives, the deposit is applied to the bill by default or refunded or released, as the Venue sets in its arrival policy.

21.10 The Venue sets its cancellation policy. The default is no refund. The Venue can set a free-cancellation window and a partial refund percentage.

21.11 The Platform marks a booking as a no-show automatically after a delay the Venue sets (15 minutes by default) and applies the Venue's deposit policy without human review. Staff can later mark the Guest as arrived.

21.12 The consequence of a no-show is limited to the deposit. The Platform does not charge a separate no-show fee.

21.13 Refunds are issued from the Venue's Stripe account. The Operator provides only the technical interface and the Venue is responsible for refund decisions. Refund timing depends on Stripe and the card issuer.

21.14 Chargebacks and disputes on deposits are filed against the Venue's connected account. The Venue must respond through Stripe and keep enough balance to cover them. The Operator does not submit evidence or notify the Venue of a dispute; the Venue should watch its Stripe notifications.

21.14A The Venue reimburses the Operator for every chargeback, dispute amount and dispute fee that the Operator bears to Stripe on a deposit that the Venue captured, including where the Venue's Stripe balance is insufficient. The Operator may claim the amount by invoice or by set-off against sums it owes the Venue, with notice and supporting Stripe records. These reimbursements are pass-through recoveries of debts that the payment company charges to the Operator on the Venue's deposits. They are not damages and sit outside the cap in clause 28.4.

21.15 The Venue must comply with Stripe's terms, including identity verification (KYC). Stripe may ask for more documents, and incomplete verification can limit deposits, payouts or access.

21.16 Stripe is responsible for its own services, fees, policies and decisions. The Operator is not responsible for Stripe outages, policy changes or account decisions.

21.17 Subscription payments from the Venue to the Operator are taken by Stripe from the Venue's card.

22. Venue responsibilities

22.1 The Venue must provide accurate information about its business, opening hours, menus, prices and policies.

22.2 The Venue is the controller of its Guests' personal data. It must have a lawful basis for the data it collects through the Platform and give Guests the information the law requires.

22.3 The Venue must have valid consent for marketing communications to a guest before including that guest in a campaign, and must keep records of that consent.

22.4 The Venue must tell Guests and callers about the AI assistants, call transcription, WhatsApp handling and automatic features it switches on, as set out in clause 12.3.

22.5 Allergen information is the Venue's responsibility. The Platform can suggest allergens from ingredients using AI, and a suggestion can appear on the public menu as "May contain". The Venue must review and confirm every allergen entry and must not rely on a suggestion.

22.6 The Venue must check AI translations of its content. The Platform does not label them as machine translations for guests.

22.7 The Venue must comply with the hospitality, consumer protection, tax, employment and data protection laws that apply to it. Where the law requires it, the Venue provides its consumer-mediator details to guests.

22.8 The Venue is responsible for the deposit, cancellation and no-show terms it sets and must make sure they are lawful and shown to Guests.

22.9 The Venue must manage its staff accounts and permissions, remove access when someone leaves and keep its Stripe account in good standing.

23. Acceptable use

23.1 Users must not try to bypass security measures, access accounts or data without permission, or interfere with normal operation of the Platform.

23.2 Users must not use the Platform for unlawful purposes, to send unsolicited or deceptive messages, or to collect data without a lawful basis.

23.3 Users must not use automated means to extract data from the Platform beyond the interfaces we provide, or resell the Platform without our agreement.

23.4 Staff Users must use the Platform only for Venue tasks and respect the access limits their Venue Administrator sets.

24. Availability

24.1 We aim for strong service stability and target 99.5 per cent availability, excluding scheduled maintenance. This target is a service objective, not a guarantee. Missing it does not give a right to a refund, credit or compensation unless agreed in writing.

24.2 We give at least 48 hours' notice of planned maintenance when possible. Unplanned outages can occur.

25. Intellectual property and Venue content

25.1 The Operator and its licensors own the Platform and everything in it. The Venue gets a non-exclusive, non-transferable right to use it during the term for its own business.

25.2 The Venue keeps ownership of its content: menus, images, logos, descriptions, booking data and guest information.

25.3 The Venue grants the Operator a worldwide, non-exclusive licence for the term to host, copy, translate and display the Venue's content to operate the Platform, including publishing Venue pages, and to run AI features on it.

25.4 The Venue confirms it has the rights to the content it uploads and to the images and text on its pages.

25.5 The Venue may give us feedback. We may use it without payment or restriction.

26. Data ownership

26.1 As between the parties, the Venue owns its data. The Operator processes Guest and Venue-content data on the Venue's instructions as set out in the DPA.

26.2 The Operator may use anonymised and aggregated data to operate and improve the Platform. It will not use data that identifies a Venue or a Guest for that purpose.

26.3 The Operator is the controller of its own data: account and billing data, signup and security data, demo and website data. The Privacy Policy describes it.

27. Confidentiality

27.1 Each party must keep the other's non-public information confidential, use it only for these Terms, and protect it with reasonable care.

27.2 This does not apply to information that is public, was already known, or must be disclosed by law or to a competent authority.

27.3 The obligation continues for 3 years after the Terms end, and for as long as personal data is held.

28. Warranty disclaimer and liability

28.1 The Platform is provided "as is". We do not guarantee that it will be error-free, always available or fit for a particular purpose, to the extent the law allows.

28.2 To the extent the law allows, we are not liable for indirect or incidental loss, or for loss of income, profits or business.

28.3 We are not liable for problems caused by Stripe, messaging and telephony providers, AI model providers, POS vendors or other third parties.

28.4 Our total liability to the Venue in relation to these Terms is limited to the greater of (a) the subscription fees the Venue paid in the 12 months before the claim and (b) 1 000 EUR.

28.5 The limits in clauses 28.2 and 28.4 do not apply to liability for: (a) dol (intentional fault or fraud); (b) faute lourde (gross negligence); (c) dommage corporel (bodily injury); or (d) statutory indemnities. Nothing in these Terms limits liability that cannot be limited under French law.

28.6 The Venue is solely responsible for allergen information, consumer information, deposit terms and marketing consent as set out in clause 22.

28.7 Liability under the DPA is governed by this section 28. The cap in clause 28.4 allocates damages between the Venue and the Operator. It does not limit the rights of data subjects under Article 82 GDPR, and it does not limit any administrative fine imposed by a supervisory authority.

29. Indemnity

29.1 The Venue will indemnify the Operator against claims, losses and costs brought by third parties, including Guests and authorities, that arise from the Venue's breach of these Terms, its content, its lack of lawful basis or consent, or its infringement of others' rights.

29.2 The Operator must notify the Venue of a claim promptly, let the Venue handle it with reasonable cooperation, and not settle without the Venue's agreement, which is not to be unreasonably withheld.

30. Suspension and termination

30.1 We may suspend or close an account, after notice where reasonably possible, if the Terms are breached, fraud or harm is detected, KYC is not completed, Stripe disables the connected account, or fees are overdue.

30.2 The Venue can close its account at any time in the Platform or by writing to us. Closing the account does not cancel obligations already incurred.

30.3 Either party can end the Terms for material breach by the other that is not remedied within 30 days of notice.

30.4 Sections that by nature continue (including 25 to 29, 32, 36 and the DPA for as long as data is held) survive termination.

31. Inactivity dissolution

31.1 We treat a Venue as inactive if there has been no activity for 90 days. Activity means a login to the partner dashboard, a sign-in to the staff app, the creation or change of a reservation, a completed guest booking (through the booking widget, WhatsApp or the voice assistant), a call to the API with the Venue's credentials, or the creation or change of a menu or menu item. Other events are not activity.

31.2 We email every enabled Venue Administrator at 60 days and again at 83 days of inactivity. From day 60 we also show a banner in the partner dashboard that stays until activity resumes. We keep the delivery logs of these emails as evidence of notice for 5 years after the account is dissolved (Annex II, R22).

31.3 If activity has not resumed by day 90, the account is dissolved: its owner and staff are disabled, the account is marked deleted and an export of its data is emailed to the Venue Administrator.

31.4 Venues with an active pilot and demonstration venues are excluded.

31.5 Dissolution disables access and marks the account as deleted. It does not on its own delete the data.

31.6 After dissolution, the Venue has 30 days to ask us to restore the account and the data. During that time the data is not deleted.

31.7 After the 30-day grace period, the Operator deletes the Venue's data under the DPA, except records it must keep, and cancels any subscription at dissolution.

31.8 Dissolution is a closure of a dormant business account. It is not a decision about any Guest.

32. Data on termination

32.1 For the Venue Administrator, an export of the Venue's data is emailed when the Venue requests deletion, and at dissolution. It is a JSON file and includes guest data. The Venue should keep it safe.

32.2 At the end of the services the Operator deletes or returns the Venue's data as set out in the DPA, at the Venue's choice.

32.3 When a Venue asks for its data to be erased, one routine deletes the guests, reservations, voice data, campaign sends, device tokens, audit rows, menus and media, and the Operator emails a report of what was deleted, with counts only. A step that fails is reported as completed with errors.

32.4 Where a Venue's account is erased, some records stay as empty shells: the account row (legal name, address, company number, VAT number, payment processor identifiers), locations, anonymised staff rows and anchored reservations.

32.5 Backups, object-storage versions, queue payloads and provider copies are not individually addressable and are removed as they expire.

32.6 Financial records (deposits, reservation fees, financial transactions, subscriptions, invoices, billing details, usage aggregates) are kept for 10 years under French commercial law, minimised.

32.7 After the 10-year period, financial records are deleted or anonymised.

33. Changes to these Terms

33.1 We may update these Terms. For minor updates we announce the change on the Platform or by email.

33.2 For changes that affect the Venue's rights or obligations, we give at least 30 days' notice by email to the Venue Administrator before the change takes effect.

33.3 If the Venue does not agree with a material change, it may leave without cost before the effective date. If it keeps using the Platform after the effective date, it accepts the updated Terms.

34. Notices

34.1 We send notices by email to every enabled Venue Administrator on the account. Where these Terms say so (for example under clause 31) we also show a banner in the partner dashboard. We keep the delivery logs of notices. The Venue must keep the email addresses of its Venue Administrators current.

34.2 The Venue sends notices to [email protected] for data protection matters and to the contact address in clause 38 for everything else.

34.3 A notice sent by email is received on the next business day.

35. Assignment and transfer of the Operator

35.1 The Operator may transfer these Terms, the DPA and its rights and obligations to a member of its group, including Deskadora Europe SRL (Romania), by giving the Venue at least 30 days' written notice. The transferee takes over every reference to the Operator.

35.2 The Venue may terminate these Terms and the DPA without penalty, by written notice given at any time during the 30-day period in clause 35.1 and before the transfer takes effect.

35.3 The Venue may not assign these Terms without our written consent.

36. Governing law and courts

36.1 These Terms are governed by French law.

36.2 Before starting legal action the parties will try in good faith to resolve the dispute within 30 days.

36.3 If the dispute is not resolved, the courts of Paris have exclusive jurisdiction, including after a transfer under clause 35.

37. Severability

37.1 If a part of these Terms is invalid, the rest stays in force.

37.2 Failure to enforce a right is not a waiver of it.

38. Contact

38.1 The Operator: Deskadora Europe SASU, 60 Rue François 1er, 75008 Paris, France. Email: [email protected]. Publication director: Marius Hîncu, Président. Privacy contact: Marius Hîncu, [email protected].

---

Annex D: Data Processing Agreement (Article 28 GDPR)

This DPA is part of the Terms. Capitalised terms have the meaning given in the Terms.

D1. Parties and roles

D1.1 The Venue is the controller and the Operator is the processor for personal data of Guests and for the personal data in the Venue's content, which the Operator processes on the Venue's behalf through the Platform.

D1.2 The Operator is an independent controller for its own account data, billing data, security data, website and demonstration data, as the Privacy Policy describes. This DPA does not apply to that data.

D1.3 For product features designed and run by the Operator (system tags, AI tag detection, scoring and briefings), the Venue gives the Operator instructions to run them by turning them on or leaving them on.

D1.4 Each party is responsible for its own compliance with data protection law.

D2. Subject matter, duration, nature and purpose

D2.1 Subject matter: providing the Platform to the Venue as set out in the Terms.

D2.2 Duration: for the term of the Terms, until personal data is deleted or returned under clause D10.

D2.3 Nature: hosting, storage, retrieval, translation, tagging, notification, messaging, call handling, transcription, analysis and deletion of personal data.

D2.4 Purpose: to take and manage reservations, deposits and guest relationships for the Venue, to send reservation and (where consented) marketing messages, to answer calls and chats for the Venue, and to give the Venue management tools.

D3. Categories of data and data subjects

D3.1 Data subjects: the Venue's Guests and callers, people named in bookings, the Venue's staff, and people named in the Venue's menus and content.

D3.2 Categories of data: Annex I lists them by feature. They include identity and contact data, booking and visit data, notes and free text, preferences, marketing consent, payment references (not card numbers), phone numbers and call transcripts, and WhatsApp messages.

D3.3 Special-category risk: dietary preferences, allergies, accessibility needs and free-text requests can reveal health or religious belief. Call transcripts and WhatsApp messages can contain anything the person says or writes. The Venue is responsible for the lawful basis for collecting such data. The Operator processes it only to run the features the Venue uses.

D4. Instructions

D4.1 The Operator processes personal data only on the Venue's documented instructions. The Terms, this DPA, the Venue's settings in the Platform and its use of features are its instructions.

D4.2 The Operator tells the Venue if it thinks an instruction breaches data protection law.

D4.3 The Operator may process personal data where law requires it, and will tell the Venue first unless the law forbids it.

D4.4 The Operator does not use Guest personal data to train AI models. The language model provider's Commercial Terms of Service (effective 17 June 2025, section B) say that it "may not train models on Customer Content from Services"; it keeps inputs and outputs for 30 days under the Operator's organisation setting (zero retention was requested and declined). The speech recognition provider processes audio and transcripts in memory, with its Model Improvement Program opted out on every request, and keeps request metadata, under the data processing agreement signed on 6 October 2026. The speech synthesis provider's Privacy Policy (last revised 14 June 2024, section 3) lets it use content to train and enhance its models unless the customer opts out through its data-controls form; on 9 October 2026 the Operator disabled "Contribute to model training" for its organisation with that provider, the single control the provider offers, which covers the input text and output audio of text-to-speech and the input audio and output text of speech-to-text; this is not retroactive. That provider keeps personal data as long as the purpose requires and deletes it within 180 days after termination; zero data retention is not enabled.

D5. Confidentiality

D5.1 The Operator makes sure that people it authorises to process the data are bound by confidentiality.

D5.2 Access to Venue data is limited to Operator personnel who need it. Support access follows clause 17 of the Terms.

D6. Security

D6.1 The Operator applies the technical and organisational measures in Annex IV.

D7. Sub-processors

D7.1 The Venue gives the Operator general written authorisation to use sub-processors, on the terms of clause III.1 of Annex III. The Operator notifies changes by email to every enabled Venue Administrator.

D7.2 The Operator has a written agreement with each sub-processor that imposes data protection obligations no less protective than this DPA, and remains responsible to the Venue for them.

D7.3 POS providers the Venue connects are the Venue's own vendors, not sub-processors of the Operator. The AI client a Venue owner connects through the MCP connector is not a sub-processor either.

D8. International transfers

D8.1 The production servers, database and queue store are in Paris, France. File storage for uploads and media and database backups are in London, United Kingdom. Processing therefore takes place in the EU and the United Kingdom (adequacy decision), and with some providers in the United States (clause D8.3).

D8.2 Transfers from the EU to the United Kingdom rely on the UK adequacy decision.

D8.3 Some sub-processors process data in the United States under the EU-US Data Privacy Framework or the European Commission's standard contractual clauses, as stated on the sub-processors page: [link to the sub-processors page]. Each sub-processor is bound by its own data processing terms, and that page names them with their date and how they bind the Operator (incorporated in the provider's terms, accepted electronically or signed).

D8.4 The Operator will tell the Venue if a sub-processor's transfer tool changes.

D8.5 The real-time audio provider runs the project that serves EU venues in the European Union (Frankfurt). The speech recognition provider is reached through its EU endpoint, but its deployment is not dedicated, so EU residency is not a contractual commitment. The speech synthesis provider processes in the United States and offers no region setting, and the language model provider processes in the United States. The sub-processors page shows the position for each.

D9. Assistance with data subject requests

D9.1 The Operator gives the Venue tools to find, export, correct and delete a Guest's data, and helps the Venue answer data subject requests on reasonable request.

D9.2 A Guest has no self-service request route on the Platform. Requests go through the Venue. If a Guest contacts the Operator, the Operator refers them to the Venue where it can identify the Venue.

D9.3 Today the guest erasure routine, triggered by the Venue Administrator or the Operator, removes the guest's record and links, tags, marketing opt-ins and notes on reservations, but does not remove staff notes, translated requests, voice data, table session names, review rows and some deposit links.

D9.4 The guest erasure routine also removes staff notes, translated requests, the guest's voice data, table session names, reviews, campaign sends, POS links and audit rows. It notifies the data subject when an email address was supplied.

D9.5 After erasure these remain: financial records, minimised and kept for 10 years; the email in the unsubscribe suppression list, so the person is not mailed again; and copies in backups and at providers that cannot be individually addressed.

D9.6 Erasure at one Venue does not erase the same person's data at another Venue, because each Venue is a separate controller.

D10. Breach, return and deletion

D10.1 The Operator notifies the Venue without undue delay after becoming aware of a personal data breach affecting the Venue's data, and in any case within 48 hours, and gives the information the Venue needs to meet its own duties.

D10.2 The Operator tells the Venue of the nature of the breach, categories and number of people and records, likely consequences and measures taken, as far as known.

D10.3 At the end of the services the Venue can choose return or deletion. The Operator emails an export of the Venue's data and then deletes the data under clause D10.4.

D10.4 The Venue erasure routine deletes the Venue's guests, reservations, voice calls and transcripts, WhatsApp conversations, campaign data, device tokens, audit rows, menus and media, and sends a report of what was deleted (counts only).

D10.5 For inactivity dissolution, the Operator waits 30 days, then runs the same erasure routine.

D10.6 Financial records are kept for 10 years, minimised, because the law requires it.

D10.7 Today, a Venue's self-service deletion anonymises staff and the account row and removes some media, but does not delete guests, reservations or voice data.

D10.8 Database backups expire 14 days after they are made (Annex II, R19); the backups bucket is not versioned. Versioning is enabled on the uploads bucket and noncurrent versions are deleted after 30 days, so a deleted upload can be recovered for 30 days and is then gone. Provider copies are deleted when they expire.

D11. Audits

D11.1 The Operator makes available the information needed to show compliance with this DPA and allows audits, including inspections, by the Venue or an auditor the Venue names, on 30 days' notice, during business hours, no more than once a year unless a breach or an authority requires it.

D11.2 The Venue bears the cost of an audit and the auditor must be bound by confidentiality.

D11.3 The Operator may satisfy an audit request by providing a current report or certification if it covers the scope.

D12. Liability

D12.1 Liability under this DPA follows section 28 of the Terms. As clause 28.7 states, the cap allocates damages between the parties. It does not limit data subjects' rights under Article 82 GDPR or any administrative fine imposed by a supervisory authority.

D13. Order of precedence

D13.1 If the Terms and this DPA conflict on the processing of personal data, this DPA prevails.

---

Annex I: Description of processing by feature

Roles: Venue is controller, Operator is processor. Recipients are shown by category; the vendors are on the sub-processors page. Status tags show whether the field list is true today or after a named PR.

---

Annex II: Retention schedule

Periods are for personal data the Operator processes for the Venue unless noted. "Venue-controlled" means the Venue decides how long data stays, and the Operator keeps it until the Venue deletes it or the account is erased.

---

Annex III: Sub-processors

III.1 The Venue gives the Operator general written authorisation to use sub-processors to provide the Platform. 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]. The Operator gives 30 days' prior notice of any addition or replacement by email to every enabled Venue Administrator and by updating the sub-processors page. The Venue may object within that period on reasonable data protection grounds. If the parties cannot resolve the objection, the Venue's remedy is to terminate the affected service, and only that service, before the change takes effect, without penalty.

---

Annex IV: Security measures

S.1 Traffic between users and the Platform is encrypted in transit with TLS.

S.2 Integration secrets are stored encrypted with AES-256-GCM: WhatsApp access tokens, WhatsApp Flow keys and PINs, POS API keys and demonstration-call phone numbers.

S.3 Access to Venue data in the Platform is controlled by role. Venue permissions limit what each user sees.

S.4 Each Venue's data is separated by tenancy rules in the application. Every query is limited to the Venue and location the user or token is authorised for.

S.5 Security-relevant events are recorded in audit logs, including support sessions, guest data reads through the MCP connector with guest scopes, and changes made during impersonation.

S.6 Rate limits apply to sign-in, public booking calls, voice calls, demonstration calls and API use.

S.7 Sign-in sessions use short-lived access tokens and refresh tokens. Sessions can be revoked.

S.8 Bot protection protects sign-in, registration and contact forms.

S.9 The object storage buckets for uploads and for database backups are encrypted at rest with SSE-S3, and so is the root volume of the production server, which holds the database and the queue store (EBS encryption with an AWS managed key).

S.10 Public content (menu photos and logos) is public by design. Private uploads are denied anonymous access by bucket policy for the floor-plans/, avatars/ and menu-scans/ prefixes. Versioning is enabled on the uploads bucket (clause D10.8).

S.11 The Operator reviews these measures regularly and may change them if the level of protection is not reduced.

---

Annex V: Notice for the Venue's public channels

V.1 The Venue displays the following sentence, in the languages of its guests, on each public channel where it publishes the number that forwards to the voice assistant (clause 12.3).

V.2 The Venue may add its own wording to the sentence but may not remove the statements that the call may be answered by an automated assistant and that it is transcribed.