Privacy Policy

Ten Degrees — booking and guest messaging platform for restaurants

Last updated: 30 September 2026

1. Who we are

TEN DEGREES TECHNOLOGIES S.R.L., Piazza della Repubblica 32, 20124 Milan (MI), Italy. VAT and tax code 14609980967, Milan Register of Companies, REA MI-2795122.

References in this policy to "Ten Degrees", "we" and "us" are to that company. Enquiries relating to this policy may be sent to [email protected].

We have not appointed a Data Protection Officer and are not required to do so under Article 37 GDPR. The address above is our contact point for all privacy enquiries and requests.

2. Our role: controller and processor

Our role under the GDPR depends on the data concerned.

We are the data controller, and this policy is our notice to you, in respect of:

• restaurant owners and staff who create an account, sign in and connect their channels;
• persons who contact us directly;
• persons whose data we process in order to operate and bill the service.

We are a data processor, acting on the restaurant's documented instructions, in respect of:

• guests who message a restaurant through WhatsApp, Instagram or Facebook Messenger;
• guests who book a table, including through a public booking page we host;
• guests who call a restaurant on a line we answer on its behalf.

In the second case the restaurant is the data controller. It is required to provide its own privacy notice, and requests should be addressed to it. Requests that reach us first are forwarded to the restaurant in accordance with section 9.

3. Data processed and purposes

3.1 Restaurant owners and staff (controller)

Connection of a Meta channel. Through Facebook Login for Business we receive an access token for the Facebook Page, Instagram professional account or WhatsApp Business Account being connected, together with that asset's identifier and display name. We also receive the basic Facebook profile of the person connecting the channel, comprising their name, profile picture and the email address held on that account, which we use to identify who performed the connection and to contact them in relation to it. We neither receive nor request friend lists, photographs, posts or any other activity on Meta beyond the connection and operation of these channels. Access tokens are encrypted at rest and are not returned by our API to any browser or client.

3.2 Guests of a restaurant (processor)

This data is not used by Ten Degrees for advertising or profiling on its own account, is not sold, and is not combined across restaurants. Any marketing or profiling use is decided by the restaurant as controller, on the guest's consent, within the purposes shown to the guest.

3.3 Booking statistics

Where booking statistics are enabled for a restaurant, its public booking page records how each guest arrived, so that the restaurant can see which channels and campaigns bring its bookings. The restaurant is the controller of this data and we process it on its behalf, as set out in section 2.

For each arrival on the booking page, and with each booking, the following is recorded whatever the guest's answer to the question below:

• the restaurant's campaign link the guest followed, if any, and the campaign tags carried by the address of the page (utm_source, utm_medium, utm_campaign, utm_content, utm_term);
• the address of the page on which the guest arrived, without its parameters;
• the domain of the site the guest came from;
• a coarse device type: mobile, tablet or desktop;
• the guest's answer to the question below.

No IP address is recorded for this purpose. A campaign link opened by a link preview, a crawler or an email security scanner that identifies itself as such is not counted, and nothing is recorded for it. The booking keeps the channel and campaign it is credited to, and the steps of the booking taken during that visit are linked to its arrival under a code that belongs to that visit alone.

On the standalone booking page of a restaurant taking part in this, a card asks the guest, answered by two buttons of equal weight, whether to allow statistics cookies; the booking works whatever the answer, and the card also carries a link to this notice. Only with the guest's permission does the booking page keep anything in the guest's browser for this purpose, and then only for that restaurant:

• the links the guest arrived from, so that a booking made on a later visit can be credited to the link that brought the guest; each link counts for fourteen days, and once none counts any more they are deleted the next time the booking page is opened;
• for the session of the browser tab, the arrival and a random navigation code in the tab's own history, so that reloading the page, or returning to it with the Back button, counts as one arrival rather than a new one each time.

Answering removes what the browser kept if the guest changes their answer. The answer itself stays in the browser, for that restaurant, for six months, after which the card asks again; a control next to the card lets the guest change it sooner. Where the booking page is embedded in the restaurant's own website, no card is shown: the permission is the one that website passes on from its own consent tool, and until it passes one the permission is treated as not given. The website is also told when a booking is made or confirmed, with its status, the party size and a random event code but no contact details; what it does with that notice is decided by the restaurant.

How long these records are kept is set out in section 8.

4. Marketing and consent

4.1 Who decides

Where a restaurant sends marketing to its guests, the restaurant is the data controller for that sending. We act as its processor under Article 28 GDPR, on its documented instructions, and we send nothing to a guest on our own account. Requests about a marketing message, and about the consent behind it, should be addressed to the restaurant, as set out in section 2.

4.2 Consent, asked separately for each channel

A restaurant may send marketing to a guest only where the guest has consented to it, and consent is asked separately for each channel: WhatsApp, email and SMS. Consent given for one channel is never read as consent for another, and a box is never ticked in advance.

Marketing consent is not required for the messages a booking itself needs, such as a confirmation, a reminder or a cancellation. Those messages continue whether or not a guest accepts marketing, and a withdrawal of marketing consent does not stop them.

4.3 Profiling, a consent of its own

Choosing what to send a guest from what the restaurant knows of them, such as their previous visits, what they ordered or what they spent, is profiling. It requires a second consent, asked separately from the consent to receive marketing and refusable on its own. A guest who accepts marketing but not profiling receives the same messages as every other guest on that channel.

Marketing emails contain no tracking pixels: we do not record whether an individual recipient opens an email.

4.4 Withdrawing consent

Consent may be withdrawn at any time, and withdrawing it is as easy as giving it:

• every marketing email carries a link to unsubscribe;
• marketing on WhatsApp stops on replying STOP to one of those messages;
• the page on which a guest manages a booking also holds their preferences, where each channel and the profiling consent can be switched off one at a time.

A withdrawal applies to the restaurant whose message it answers and takes effect on that restaurant's next sending. It leaves the messages described in 4.2 untouched.

4.5 Email to a restaurant's own customers

Italian law allows a restaurant to send email about its own similar services to a person whose address it obtained in the course of a sale, without asking for a further consent, provided that the person was given the opportunity to refuse when the address was collected and is given it again in every message (Article 130(4) of Legislative Decree 196/2003). Where a restaurant relies on this, the refusal is offered in the manner described in 4.4. It is available for email alone, never for WhatsApp or SMS, on which consent is always required.

4.6 Retention of the choices made

A guest's marketing preferences, and the record of each consent, refusal and withdrawal with the date on which it was made, are held in the restaurant's account and kept for as long as the restaurant's own retention policy provides, as described in section 8. The restaurant decides that period, as it decides the purposes.

5. Automated and AI-assisted features

The features below use artificial intelligence models supplied by third parties. Each is used only where the restaurant has switched it on or a member of its staff chooses to use it, and no content is sent to a model provider otherwise. Requests reach the providers by one of two routes:

• OpenAI, L.L.C., xAI Corp., Eleven Labs Inc. and TypeSafe AI, Inc., all in the United States, are connected directly. Text requests to OpenAI are sent with OpenAI's storage of the exchange switched off.
• Every other request passes through OpenRouter, Inc. (United States), a routing service that hands each request to the model provider we have designated for that feature and does not itself keep the content. For every request other than transcription we further instruct it to use only provider endpoints that do not retain the content once the request is complete and do not use it for training.

When OpenAI's model fails to answer a request of the reservation agent, including the checks of the restaurant's house rules described below, the staff assistant or the voice assistant, and for a short while after such a failure, those requests are sent instead, through OpenRouter, to Google's Gemini model on Google Cloud Vertex AI (Google LLC, United States), which answers in its place.

Suggested replies for staff. The text of a conversation is sent to Z.AI in order to draft a reply. Telephone numbers and email addresses are removed before transmission. A reply to a review is drafted by Z.AI as well, from the review as it is, as set out in section 11. No suggestion is sent to a guest automatically; a member of staff reviews it and decides whether to send it.

Assistant on a booking page. A question submitted on a restaurant's public booking page is sent to Z.AI, with telephone numbers and email addresses removed, and the answer is displayed to the guest without prior review by staff. The assistant answers questions and directs the guest to a booking action. It cannot create, amend or cancel a booking.

Reservation agent on messaging channels. Where a restaurant has enabled it, a private message sent to the restaurant on WhatsApp, Instagram or Facebook Messenger may be answered by an automated agent rather than by a member of staff. The text of the conversation is sent to OpenAI in order to understand the request and compose the reply. Because the agent collects the details needed for a booking, telephone numbers and email addresses in the conversation are not removed before transmission. Where the guest is already on the restaurant's records, the agent also receives a short card drawn from them: the guest's name, the date and party size of their last booking, the number of visits, the preferences the guest has stated, and whether the restaurant has marked the guest as a VIP or asked that their bookings not be taken. When the guest's message raises a dietary need, the card also carries the allergies and accessibility needs the guest has agreed the restaurant may keep. A guest may send a voice message, in which case the audio is sent to Deep Infra Inc. or Groq LLC (United States) for transcription; the audio is not stored, and the transcript is kept in encrypted form like any other message in the conversation. The reply is sent to the guest without prior review by staff, and the agent may create, amend or cancel a booking, or add the guest to a waiting list, once the guest has confirmed the details it reads back. Where one of the restaurant's house rules applies to the booking and whether it refuses the booking depends on what the guest has said, the model that writes the replies does not decide: the conversation, as it is, is checked against that rule by TypeSafe, where the restaurant has switched on enhanced AI assistance and TypeSafe makes this decision, and otherwise by OpenAI's model in a separate request that writes nothing to the guest. A booking the rule refuses is not made. The agent identifies itself as an automated assistant in its first reply, hands the conversation to staff when a request is outside its scope or the guest asks for a person, and stops when a member of staff replies. The restaurant may switch it off for any of its locations at any time.

Voice assistant. Where a restaurant has enabled it, an incoming call may be answered by an automated assistant rather than by a person. The call is carried in real time to the voice provider we have selected for the restaurant's line: xAI; OpenAI, whose voice model conducts the call and consults OpenAI's text model for the booking steps; or Eleven Labs, which turns the caller's speech into text and the replies into speech while OpenAI's text model conducts the conversation. During the call the assistant may create, amend or cancel a booking, or transfer the call to a member of staff. When a caller asks for a booking, a change to one or a place on a waiting list and one of the restaurant's house rules applies in the same way, the transcript of the call so far, with the caller's words and the assistant's, is checked against that rule as a conversation on a messaging channel is, by TypeSafe or by OpenAI's model, whatever voice provider the line uses; that transcript is sent as it is, contact details included. Where the caller's number belongs to a guest on the restaurant's records, the assistant receives the guest's first name, the number of visits, the preferences the guest has stated and the restaurant's VIP and do-not-book markings, but never allergies or accessibility needs. Personal details cannot be removed from speech before transmission. No recording of the call is retained, and Eleven Labs is instructed to delete the audio and the transcript of the calls it handles. When a call ends, its transcript, with telephone numbers and email addresses removed, is sent to xAI to write a summary. We retain a written transcript and a summary, both encrypted, together with the last four digits of the caller's number.

Staff assistant. Staff may operate the platform through an assistant in the dashboard. The staff member's messages and any images they attach, and the account data the assistant reads in order to carry out a request, which may include guests' booking and contact details, are sent to OpenAI. A staff member may dictate a message as a voice note, in which case the audio is sent to Deep Infra Inc. or Groq LLC (United States) for transcription; the audio is not stored, and the transcript is kept in encrypted form like any other message. Where a staff member asks the assistant to create or edit an image, or generates one in the marketing, gift card or experience tools, the request and any reference image are sent to OpenAI.

Guided setup. The owner or a manager may set up a restaurant by answering the questions of a guided setup, in writing or by dictation. Dictated audio is sent to xAI for transcription and is not stored; the text is shown to the person dictating before anything is saved. The answers are sent to OpenAI, through the staff assistant's model, to be turned into draft settings, which are saved only once the owner or manager approves them.

Floor plan from photographs. Where a restaurant has enabled it, a member of staff may upload photographs or drawings of the dining room so that a draft floor plan is prepared from them. The images, with any description the staff member adds, are sent to Z.AI, and staff review the draft before it is used.

Enhanced AI assistance. Where a restaurant has switched it on, the messages the reservation agent receives, the replies it drafts, the rating and text of each new review without the reviewer's name, and the searches the staff assistant makes among the restaurant's settings are also sent to TypeSafe, and so is the transcript of a call when TypeSafe checks a house rule, as described above. Its model returns scores, used to judge whether a conversation needs a member of staff, whether a drafted reply is accurate, whether a guest's reply confirms the booking read back to them, whether a house rule refuses a booking, whether a review reports a problem that should raise an alert and which of the restaurant's settings a search refers to; it writes no text for guests or staff.

The providers named in this section act as our suppliers and process this content under their API terms, as set out in sections 6 and 7. We do not use it to construct a profile of any individual or for advertising purposes.

6. Sub-processors

The following sub-processors process personal data on our behalf. Personal data is not disclosed to any other recipient, except that, for a booking made through Reserve with Google, we tell Google when it is changed, cancelled or marked as a no-show, as set out in 3.2.

7. Transfers outside the EEA

Data is stored in the European Union. Certain providers listed in section 6, and Google as the recipient of the Reserve with Google updates described in 3.2, are established in the United States or Singapore, and the following processing reaches them:

• Telnyx receives the telephone number and message text of an SMS, and carries the audio of a voice call;
• Postmark receives the email address and content of email sent on the restaurant's behalf, and of the Ten Degrees News newsletter;
• OpenRouter receives the text, images and audio submitted to the AI features it routes, described in section 5, and passes each request to the model provider designated for it: Z.AI receives conversation text and booking-page questions with telephone numbers and email addresses removed, the reviewer's display name and the rating and text of a review it drafts a reply to, and the images and descriptions submitted for a floor plan; Google receives, when OpenAI's model fails to answer, the same content OpenAI would have received for the reservation agent and its house-rule checks, the staff assistant or the voice assistant; Deep Infra or Groq receive the audio of staff voice notes and of guests' voice messages for transcription;
• OpenAI receives directly the conversations handled by the reservation agent on messaging channels, including any contact details the guest provides and the guest's card described in section 5; the conversation, or the transcript of a call so far, as it is, for a house-rule check that TypeSafe does not make; the staff assistant's messages and images together with the account data read on its behalf, and the answers given in the guided setup; the audio of calls on lines that use OpenAI and the text of calls on lines that use OpenAI or Eleven Labs; and image generation and editing requests, with any reference image;
• xAI receives directly the audio of calls on lines that use xAI, the transcript of each call, with telephone numbers and email addresses removed, for its summary, and the audio of dictation in the guided setup;
• Eleven Labs receives directly the audio of calls on lines that use it;
• TypeSafe receives directly, where the restaurant has switched on enhanced AI assistance, the messages the reservation agent receives and the replies it drafts, the transcript of a call so far, as it is, when it checks a house rule, the rating and text of new reviews without the reviewer's name, and the staff assistant's settings searches;
• Google receives, for bookings made through Reserve with Google, the updates described in 3.2, namely each booking's status, start time, duration and party size when it is changed, cancelled or marked as a no-show; the daily update of each eligible restaurant's details and free times that we send to Reserve with Google contains no guest data;
• Supabase stores data in Ireland, but as a United States company its personnel may access that data for support purposes;
• Cloudflare handles requests in transit. Requests originating in Europe are normally served by its European edge, but it is a United States company operating a global network.

Each transfer is governed by a data processing agreement incorporating the European Commission's Standard Contractual Clauses, or by the provider's certification under the EU-U.S. Data Privacy Framework where it holds one. The model providers reached through OpenRouter are engaged by OpenRouter as its sub-processors under its data processing agreement with us. Details are available on request at the address in section 1.

8. Retention

Access tokens are deleted when the restaurant disconnects the channel, and cease to be usable when Meta expires them.

Raw webhook events received from Meta are stored in encrypted form and retained for the duration of the restaurant's account, for delivery reliability and audit purposes. They are deleted when the account closes.

Conversations, bookings, guest records and call transcripts are retained for the duration of the restaurant's account, the restaurant being responsible for determining how long it requires its own guest history. A restaurant may request a shorter period for its guest records and messages, which we then apply by deletion or anonymisation.

Where booking statistics are enabled, the record of each campaign link followed and of each arrival on the booking page is deleted by a daily job once it is older than thirteen months (396 days), unless a legal hold applies to it. A booking keeps the channel and campaign it was credited to for as long as the booking itself is kept.

On closure of an account we delete or return the restaurant's data.

Data is deleted earlier on request, in accordance with section 9.

Account and billing records are retained for ten years, the period prescribed for accounting records by Article 2220 of the Italian Civil Code.

9. Your rights

Under the GDPR you may request access to your data, its correction or erasure, restriction of processing and data portability, and you may object to processing based on legitimate interest.

Where we act as controller, as set out in section 2, requests should be sent to [email protected]. We respond within one month.

Where we act as processor, the restaurant decides, and requests should be addressed to it. Where a request reaches us instead, we forward it promptly and confirm to you that we have done so. We are not permitted to act on that data on our own initiative.

Complaints may be lodged with the Garante per la protezione dei dati personali, Piazza Venezia 11, 00187 Rome, gpdp.it, or with the supervisory authority of the EU country of residence.

10. Deleting data received through Meta

Persons who connected a channel through a Meta account, being restaurant owners and their staff, may request deletion in Facebook Settings, under Apps and Websites, by selecting Ten Degrees Automation and then Remove.

Facebook transmits the request to us automatically. We verify that it originates from Meta, delete the conversations associated with the identifier, and only then mark the request complete. A confirmation code and a status URL are provided, at which the progress of the request may be checked. The status page reports deletion as complete only once those conversations have been deleted.

Guests who messaged a restaurant through WhatsApp, Instagram or Messenger have not installed our application and will not find it in their Facebook settings. Such requests should be addressed to the restaurant concerned, which is the data controller for those messages and for any booking made with it. Where such a request reaches us instead, we forward it promptly and confirm that we have done so.

Requests may also be sent directly to [email protected].

11. Google user data

This section sets out how we access, use, store and share data received from Google through the Google Business Profile APIs. It applies where a restaurant connects its Business Profile to the reviews inbox in the dashboard: an owner or manager signs in with the Google account that manages the profile and grants one permission, https://www.googleapis.com/auth/business.manage.

What we access. When a profile is connected we read the names of the Business Profile accounts and locations that the Google account manages, so that the person connecting can choose the one that is their restaurant. From then on we read that location's reviews, namely the reviewer's display name, the star rating, the text of the review and the dates it was written and last changed, together with the owner's reply to each where there is one, the state of Google's moderation of that reply, and the location's overall rating and number of reviews. We read nothing else from the Google account.

How we use it. Only to provide the reviews inbox to the restaurant that connected the profile: to show its own reviews to its owners and managers in the dashboard, to alert them to a review that needs attention, to draft replies, and to publish to Google the reply a member of staff approves. Nothing is published automatically. Every reply reaches Google because a person pressed publish, or confirmed it to the staff assistant described in section 5.

Drafts and checks. To draft a reply, the reviewer's display name, the rating and the text of the review are sent through OpenRouter to Z.AI, the provider designated for suggested replies in section 6, only to produce the suggestion. Where the restaurant has also switched on Enhanced AI assistance, the rating and text of each newly received review, without the reviewer's name, are sent to TypeSafe only to classify the review for the inbox, such as whether it reports a problem that should raise an alert. When a member of staff asks the staff assistant about reviews, the rating, text and reply of the reviews it reads are sent with that request as described in section 5; the reviewer's name is not sent as such, though a reply or a draft may address the reviewer by name.

Storage and retention. The reviewer's name, the text of each review, its replies and drafts, and the authorization Google issues for the connection are stored encrypted at rest, apart from two things kept in clear and deleted together with the review: the reviewer's first name and initial shown to staff in notifications, and, where TypeSafe checked the review, up to its first 300 characters kept with the result of that check. A review is deleted 30 days after we last read it from Google, and every Google review of a location, its overall rating and the stored authorization are deleted as soon as the restaurant disconnects Google.

What we do not do. We do not sell Google user data, use it for advertising, or use it to develop, improve or train generalised artificial intelligence or machine-learning models. We transfer it to no one other than the providers named in this section and in section 6, which process it on our behalf to provide the inbox.

Revoking access. A restaurant can disconnect Google at any time in Reviews → Review sources → Disconnect, which deletes the reviews, the overall rating and the authorization at once, or revoke our access from its Google Account at https://myaccount.google.com/connections, after which nothing more is read and the reviews already stored are deleted within 30 days.

Ten Degrees' use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

12. Security

Access tokens, message bodies and call transcripts are encrypted at rest using authenticated encryption. A short excerpt of each message is stored in clear text for display in the conversation list; telephone numbers and email addresses are removed from that excerpt. Inbound webhooks from Meta are verified against Meta's cryptographic signature before acceptance. Each restaurant's data is isolated within the database by row-level security, which applies independently of the application layer. Access to production systems is restricted and logged, and administrative actions are recorded in an audit log.

13. Changes to this policy

Amendments are published at this address and the date above is updated. Where an amendment materially affects the processing of personal data, account holders are notified before it takes effect.

14. Website contact form

When you fill in the "Talk to us" form we collect your name, restaurant, city, phone, email and the optional message, together with the request date and the page it was sent from. We use them only to call you back and prepare a quote. The data stays in our systems in the EU for 24 months from the request and is then deleted; we do not use it for marketing without your consent and we do not share it with third parties beyond the providers we need to deliver your request to our team.

15. Contact

TEN DEGREES TECHNOLOGIES S.R.L. Piazza della Repubblica 32, 20124 Milan (MI), Italy [email protected]