Privacy policy

1. Data Controller

The Data Controller is:

• Name: Michele Bogoni
• VAT ID: 04555040239
• Registered office: Via Novella, 5/E – 37032 Monteforte d'Alpone (VR), Italy
• Email: info@truereply.it

For any request regarding the processing of personal data, the user may contact the Data Controller at the email address above.

2. Categories of data collected

2.1 Data of registered users (TrueReply customers)

Upon registration and during use of the service, we collect:

• Identification and contact data: first name, last name, email address and phone number, provided at sign-up, at checkout or when requesting a personalized demo, and the VAT number, if the Customer provides it. Those using free access confirm them in the verification request, and an operator uses the phone number to contact them before unlocking the +39 number and outbound messages
• Authentication data: password (cryptographic hash via Firebase Authentication)
• Billing data: company name, address, VAT number, e-invoicing recipient code and phone number entered at checkout, processed and stored by Stripe Inc.; a copy is kept on the Customer’s profile to manage the account and invoicing. TrueReply neither stores nor has access to credit card data
• Support contact details: the name and phone number the Customer leaves with the in-dashboard support assistant when asking to be called back by a member of our team. They are stored on the Customer’s profile so that we do not have to ask for them again with every request, and they reach us only if the Customer provides them
• Usage data: number of conversations, messages, voice minutes consumed, chatbot configuration
• Uploaded content: documents, URLs, and texts uploaded to the chatbot knowledge base

2.2 Data of visitors of customers' websites (chatbot end users)

When a visitor interacts with a TrueReply chatbot installed on a customer's website, we collect:

• Chat messages: the content of the conversation with the chatbot
• Random per-browser visitor identifier: a random ID generated by the browser and stored locally (localStorage) to ensure session continuity
• Session identifier: a random UUID generated for each chat session
• Page URL: the web page the visitor is on at the time of the interaction
• Device type: mobile or desktop
• Contact data voluntarily provided: name, email, phone number, or other information the visitor chooses to share during the conversation (lead capture)
• Voice call data, inbound and outbound (if active): caller or recipient number, date, duration, talk-time, conversation transcript, outcome. Audio recording is processed only where active, that is for calls with the Provider's demonstration assistant (the demonstration number, the trial call requested from the website and the callback of the personalized demo), in which the assistant announces the recording at the start of the call, and, on tailor-made solutions, where provided for on the Controller's instructions; for customers' calls on the off-the-shelf solutions only transcripts and metadata are processed (see section 7)
• Outbound campaign data (if active): contact lists uploaded by the customer or selected by the customer from the contacts in its own contact records by status, consent attestations and their source, account-wide opt-out and suppression lists
• WhatsApp messages (if active): message content, media, and metadata such as sender and recipient numbers, date and time, delivery and read status
• Email correspondence of the connected mailbox (if active): when the customer connects their own mailbox to the service, we process, from the moment of connection, the messages that arrive in it and the messages that leave it, both those sent through the service and those the customer writes from their own mail program: sender and recipients, subject, date and time, technical message and thread identifiers, message body, and any attachments in PDF or image format. The data subjects of this processing are the customer's third-party correspondents, that is, anyone who writes to the connected mailbox or receives a message from it: they have no direct relationship with TrueReply, which neither contacts nor informs them directly. Informing them remains the responsibility of the customer, who is the Data Controller (see section 9); from the authenticated sender of a received message the service also derives a record in the customer's contact register (see below)
• Unified contact record: on behalf of the customer, the service links to a single contact the interactions that the same person has across different channels (website chat, WhatsApp, phone and email), using the normalized phone number and email address as keys; the customer may also enter a contact by hand, giving its contact details. The contact holds first and last name, contact details (up to five phone numbers and five email addresses, with an indication of how they were acquired), the company where available, the tags and variables configured by the customer, the state of each channel, the customer's choice of who answers that contact (the AI assistant, a member of its team indicated by name, or no one), a status for the contact chosen by the customer from five predefined values (new, to follow up, in progress, closed, not interested), and a free-text note that the customer may write on the contact; it does not hold conversation content; on the email channel the contact is created from the authenticated sender of a received message that passes the automatic filter, with their address and the name they gave in the message header
• Automation execution data: when the customer configures an automation, we record the event that triggers it (channel, session identifier, associated contact, and any lead data or message preview), the resulting execution with its outcome, the individual steps performed with a truncated summary of the parameters used and of the response received, and any waits for a reply from the data subject

2.3 Data collected on truereply.it

When browsing truereply.it, we collect data via:

• Google Analytics 4: anonymized browsing data (pages visited, session duration, traffic source, device type)
• Meta Pixel (Facebook): browsing data for remarketing and advertising conversion analysis
• Server-side conversion measurement (Meta Conversions API and equivalent Google measurement): for those who leave a contact (form, chat) or activate a plan, we transmit to Meta and Google identifiers in hashed form (email address, phone number) and any advertising click parameters (fbc/fbp), for the sole purpose of measuring and optimizing advertising campaigns. The legal basis is the consent given when submitting the contact or activating the plan, by accepting this privacy policy, which is separate from and independent of the cookie consent expressed through the banner
• Microsoft Clarity: anonymous session recordings, heatmaps, and page interaction data to improve user experience
• Brevo (Sendinblue): email address, in case of voluntary subscription to the newsletter

2.4 Data of partner agencies

When an agency applies to become a TrueReply partner, and for the whole duration of the relationship, we collect:

• Agency data: company name, VAT number, tax code if provided, registered office, certified email address (PEC) and name of the legal representative
• Contact person data: name, role and email address of the person who fills in the registration, who becomes the agency’s first operator upon approval
• Proof of acceptance of the contractual documents: version and fingerprint of the accepted documents, date and time, IP address and browser type (user agent), recorded by the server at submission
• Agency operators’ data: email address and dashboard login credentials (password as a cryptographic hash via Firebase Authentication) of those who operate on behalf of the agency, and any email address at which the agency receives notifications

3. Purpose and legal basis of processing

4. Methods of processing

Personal data are processed using IT and electronic tools, with logic strictly related to the purposes stated above and, in any case, in such a way as to ensure the security and confidentiality of the data.

Processing via artificial intelligence: messages sent by end users to the chatbot are processed by third-party AI models (OpenAI or Anthropic Claude for text chat, depending on the assistant and the function; Google Gemini for voice) to generate relevant answers. Messages are sent to AI providers exclusively for real-time processing and are not used to train models. Conversations are stored in a Firestore database to allow the customer to monitor interactions.

AI providers for text chat: the generation of chat replies on the website, on WhatsApp and, if active, on the email channel is entrusted, for the assistants that use it, to OpenAI Ireland Ltd. For data from the European Economic Area, OpenAI Ireland Ltd may transfer it to affiliates and providers located outside the European Economic Area, in particular in the United States, on the basis of the SCC or of an adequacy decision: the processing therefore also takes place in the United States. TrueReply turns off the storage of requests and responses on OpenAI's API service; OpenAI keeps for up to 30 days only the logs needed for abuse-prevention controls and does not use content sent through the API to train its models. Anthropic PBC remains a sub-processor for the other functions listed in section 5: summaries and classification of conversations, extraction of variables, reading of the documents and pages uploaded to the knowledge base, assistance in the dashboard, and the generation of chat replies for assistants not entrusted to OpenAI and for turns in which OpenAI is not used (for example those that contain attachments or those in which it is unavailable).

Processing via embeddings: documents uploaded to the knowledge base are transformed into numerical representations (embeddings) via Google (Vertex AI), in the EU region, to enable semantic search. Content is sent to Google exclusively for real-time processing, is not used to train its models, and is not subject to permanent retention.

Processing of WhatsApp messages: messages exchanged on the customer's WhatsApp Business number are processed by TrueReply as a Data Processor, exclusively to provide the AI assistance service, transiting through Meta's WhatsApp Business Platform. Content is processed by AI models to generate answers and stored in a database to allow the customer to monitor conversations.

Processing of email correspondence (if active): when the customer connects their own mailbox to the service, TrueReply reads, from the moment of connection, the messages that arrive in it and the messages that leave it, and makes them available to the customer in the reserved area, where the customer can ask the AI assistant for a reply proposal, review it and send it, reply writing the text personally, or send new emails on their own initiative, including attachments — sending always happens from the customer's mailbox and under the customer's identity. No reply is ever sent automatically. Reading sent mail also covers the messages the customer writes from their own mail program and those that start a new correspondence: it exists so that the customer sees the complete exchange and so that the reply proposal takes into account what has already been said. It does not cover outgoing messages that standard technical markers or the subject line identify as automatically sent (out-of-office replies, list and newsletter communications, calendar invitations, delivery failure notices), sends to more than ten visible recipients, or messages addressed to the addresses and domains the customer has excluded in the channel settings — which, on outgoing messages, are applied to the recipient. The mailbox history is not imported. Mail classified as junk by the mailbox provider is made available to the customer marked with its origin and can be excluded from processing in the channel settings; here too, no reply proposal is ever generated without the customer's request. The mailbox provider (the customer's email provider or corporate mail administrator) remains a supplier of the customer and not a sub-processor of TrueReply. Because a business mailbox receives correspondence of every kind, the processing is bounded by the following measures:

• Automatic filter before the artificial intelligence: before any processing by the AI models, a deterministic filter discards non-conversational messages (delivery failure notices, automatic replies and system messages, newsletters and list communications, notification-only addresses). Only the metadata of such messages is retained, that is sender, subject, and date: the content is not transmitted to any AI provider and no contact record is created from their sender
• Messages that do not require a reply: when the assistant recognizes that a message does not require a reply, only its metadata and the reason are retained, not the message body
• Limiting the senders and recipients processed: the customer can restrict processing to the domains they specify and exclude specific addresses and domains; by default, messages coming from the customer's own domain are excluded. On SENT messages the same lists apply to the recipient: by default, correspondence addressed to the customer's own domain does not enter the service, and an excluded address stays out in both directions
• AI processing: the content of the messages that pass the filter is processed by the AI providers listed in section 5 (OpenAI and Anthropic Claude, depending on the assistant and the content) solely upon the customer's request and in real time, to prepare the reply proposal, under the same conditions stated above for chat (real-time processing, no use for model training)
• Sending limits and transparency: the service sends only to the recipients defined by the customer (one primary recipient and, where the customer adds them, further recipients in Cc or Bcc, up to ten in total per message), has no bulk-sending capability, applies a daily sending limit per mailbox, and the assistant never initiates new email conversations on its own: new emails start only on the customer's initiative, with text written by the customer and towards the recipients they choose; by default the reply is addressed to the sender of the original message and any change of recipients is an express choice made by the customer during review; every draft reply is prepared with the indication — active by default and editable by the customer, since every send follows the customer's review — that it was prepared by an AI assistant. Messages whose sender is not authenticated by the standard technical checks of the protocol never result in any send: no automatic sending exists
• Attachments: only attachments in PDF or image format and within the size limits provided will be processed; other formats will be neither downloaded nor retained. The files processed will be stored in a dedicated archive, segregated per customer and not publicly accessible, with download allowed only through short-lived signed links issued after authentication. The content of permitted attachments may be read by the AI models in order to reply within the context of the conversation the attachment arrived in
• Certified email (PEC) mailboxes: excluded from the channel, the connection is refused by the service

Attachments and media on WhatsApp: on the WhatsApp channel the service downloads from Meta's servers the images (JPEG, PNG, WebP, GIF) and PDF documents received, within the size limits provided, and stores them with the conversation in a dedicated archive in the EU, segregated per customer and not publicly accessible, available only after authentication. The content of these files may be read by the AI models in order to reply in the turn in which they arrive. Voice notes are transcribed into text through Google (Vertex AI), with processing in the European Union: the transcribed text becomes the content of the message and the audio is not retained. Other media (videos, stickers, audio files that are not voice notes) and other formats are neither downloaded nor retained, and only a textual placeholder with the caption, where present, remains in the conversation. The website chatbot does not allow attachments to be sent.

Unified contact record: on behalf of the customer, the service links to a single contact the interactions that the same person has across different channels, using the normalized phone number and email address as keys. On the email channel, from the authenticated sender of a received message that passes the automatic filter and is not excluded by the customer, the service creates or updates a contact record with the address and the name the sender gave in the message header. A message is linked to an existing record only on the sender's address. When the address does not yet have a record, the service reads, by a fixed rule and without artificial intelligence models, the phone numbers the sender wrote in the text, signature included: it uses them only to flag to the customer, on the new record, a possible duplicate of a record that already holds them as a contact detail, and it neither stores them nor adds them to the new record. Neither a number nor a name written in the text links two records. The contact record is the customer's own register of contacts, has a purpose of its own, distinct from conversation content, and does not retain conversation text. The customer may enter a contact by hand, giving its contact details (a phone number or an email address, which no channel has verified) and optionally a name, and may indicate, for each contact, who answers: the AI assistant, a member of the customer's own team, whose name the customer chooses and keeps in a list, or no one. This is a management choice of the customer, who is the Controller, and not an objection by the data subject, which is recorded separately. When the customer indicates "no one" for a contact, the service, except on the website chat (described below), does not answer that person and does not record their communications on WhatsApp, by email or by phone: a phone call is forwarded to the number the customer has given (if the customer later removes that number, the call reaches the assistant as for any other person), and the content of a WhatsApp message or of an email is not kept (for a WhatsApp message a technical service record remains for 7 days, with the message identifier, the type and the date, without the content; for a discarded email only the sender's address, the subject and the date are kept, for 183 days). On the website chat the service can recognize the person only once they leave a contact detail: until then the assistant answers and the text of the conversation is kept like any other, together with the variables extracted from it, the conversation row in the Google Sheet the customer has connected (if any) and any appointment already booked on the customer's calendar, while the lead that carries that contact detail is not recorded. The service does not send that contact any messages, calls or emails on the customer's behalf either. When the customer indicates a member of its own team, on WhatsApp that contact's messages are recorded but the AI assistant does not reply (voice notes, images and PDFs received are still transcribed or read, to complete the record of the conversation), and promotional messages and campaigns to that contact are not sent, while service messages are. The exclusion lists the customer already had (numbers and addresses it had excluded) are transferred by the service into this choice: for each contact detail the service creates a record holding the contact detail only, set to "no one". The customer may also write on each contact a free-text note of up to 2,000 characters, which no AI assistant reads: the customer is its Controller and may record any information in it, including special categories of data, which is why the note is always protected by application-level field encryption, for all customers. The identifying fields of the contact record (first and last name, display name, company, contact details and WhatsApp identifiers) are stored without application-level field encryption, including for customers who have declared assistants intended for the processing of special categories of data. The same applies to the customer's choice of who answers and to the contact's status, one of five predefined values: the customer sets them (also through whoever acts on its behalf or, for the status, an automation it has configured), no AI assistant writes them, and the status is not read by any AI assistant. Infrastructure encryption at rest, transport protection and access controls remain in place. Conversation content, the contact's free-text note and other data covered by the special-category safeguards retain their existing application-level encryption.

Execution of automations configured by the customer: based on rules the customer configures, an event in the conversation (a message, a lead, a call outcome, an appointment, a request received on a webhook address dedicated to the flow, or a time schedule) can start the execution of an automation. Eight actions are available today: sending an internal alert to the customer and their staff, by email or on WhatsApp, to the account holder or to up to five contact details the customer writes into the rule (never a contact detail derived from the conversation or from a third party's payload); sending an email to the customer's end recipient, for instance an appointment reminder, which is sent from TrueReply's mail infrastructure with the customer's business name and their address as the reply-to, subject to daily per-account limits; sending a WhatsApp message based on a Meta-approved template; appending a row to the Google Sheet connected by the customer; updating the extracted variables and tags of the ongoing conversation; setting or clearing the status of a contact; an HTTP call to a public endpoint the customer configures; and an automated voice call to a phone number designated by the customer's rules, conducted by the customer's voice assistant from the number assigned to their account. The internal alert and the email to the end recipient transit through the SMTP provider listed in section 5, the WhatsApp message through Meta's WhatsApp Business Platform, the spreadsheet row through Google's services, the HTTP call reaches the endpoint chosen by the customer, and the voice call transits through the telephony provider listed in section 5; updating the conversation's variables and setting a contact's status entail no transmission outside the platform. TrueReply performs these actions as a documented instruction of the customer as Controller and determines neither their content nor their recipient. For each execution we retain the triggering event, the steps performed with a truncated summary of parameters and outcome, and any waits for a reply, for the periods stated in section 7. The customer may also configure, for each of its assistants, HTTPS addresses of its own systems (webhooks) to which the service sends, signed, the events the customer chooses, including a change in a contact's status, never with the free-text note. TrueReply sends them as a documented instruction of the customer and does not determine the recipient. The automations the customer configures may also start when the status of a contact changes and read it in a condition or in a message; a change made by an automation is recorded as such (identifier of the automation and of the run), and the service never assigns a status to a contact on its own initiative. When a contact's status is "not interested", the service does not start automated promotional messages or campaigns for that contact: it is a choice of the customer, who is the Controller, and not an objection by the data subject, which is recorded separately. This processing concerns the identity of the contact, the state of the channels and the status of the contact: it does not produce automated decisions producing legal effects or similarly significantly affecting the data subject within the meaning of Art. 22 GDPR.

Processing of outbound calls: outbound AI voice calls on behalf of the customer are delivered with compliance safeguards that the customer cannot disable: AI disclosure as the first sentence of every call, permitted time windows, use of the customer's real +39 number as caller ID (without spoofing), opt-out handling with an account-wide suppression list, and consent attestation at the time each list is imported or contacts are added to a campaign from the customer's contact records by status.

AI classification and summarization: the transcribed text of calls and conversations may be processed by artificial intelligence models (Anthropic Claude) to classify opt-out requests, to extract variables and to generate summaries, solely for the purpose of providing the service.

5. Data processors and recipients

To provide the service, the Controller relies on the following sub-processors:

For Customers who have entrusted the management of their account to a TrueReply partner agency, the agency is also a sub-processor: its operators access, on behalf of TrueReply and within the limits of the Customer’s instructions, the dashboard of the Customer’s account (assistant configuration, knowledge, conversations, contacts, channels, campaigns and automations), under an agreement pursuant to Art. 28 GDPR that imposes on the agency obligations equivalent to TrueReply’s. The agency has no access to the functions concerning the existence of the account, the exercise of data subject rights and payments, and the relevant operations it performs remain in the log of operations (audit).

6. Data transfers outside the EU

Some of the sub-processors listed above are based in the United States. Data transfers to such parties take place on the basis of the Standard Contractual Clauses (SCC) approved by the European Commission pursuant to Art. 46.2.c GDPR, as well as the EU-US Data Privacy Framework where applicable.

The main database (Firestore) is hosted in the EU region (eur3 – europe-west) and data resides there permanently. Transmission to AI providers occurs exclusively for the real-time processing of requests and does not entail the permanent retention of data by such providers. Anthropic is based in the United States and the transfer takes place on the basis of the SCC. OpenAI Ireland Ltd is established in the European Union and transfers data to affiliates and providers located outside the European Economic Area, in particular in the United States, on the basis of the SCC or of an adequacy decision, under the data processing agreement concluded with OpenAI: for the generation of replies entrusted to OpenAI the processing therefore also takes place in the United States, and OpenAI keeps for up to 30 days only the logs needed for abuse-prevention controls.

7. Data retention period

• Account data: retained for the entire duration of the contractual relationship and deleted 30 days after it ends or after an account deletion request. Only the data required for tax and accounting obligations (invoices and payment data) is retained for 10 years, as required by law. The records of the acceptance of the Terms and Conditions and of the specific approval of their clauses (date, version of the documents and form through which they were given) remain in the log of relevant operations for its retention period, even after the account is deleted, for the defence of legal claims (Art. 17(3)(e) GDPR)
• Chatbot conversations, including text chats, WhatsApp messages, email-channel conversations, and voice-call transcripts/metadata: retained for a maximum of 6 months from the last activity, after which they are automatically deleted. The customer (Controller) can connect their own Google Sheet to keep the full history without time limits in their own file. They are in any case removed upon account deletion
• Email messages discarded by the automatic filter: retained for the same period of 6 months as metadata only (sender, subject, date, and reason for discarding), without the message body. Messages that pass the filter are instead retained with their content within the conversation, for the same period of 6 months, because that is where the Customer reads and replies to them
• Attachments of email correspondence and of WhatsApp conversations (if active): they will be retained in the dedicated archive for a maximum of 6 months, aligned with the conversation they belong to, and removed together with it or upon account deletion
• Access credentials of the connected email mailbox (if active): retained encrypted for as long as the connection remains active; deleted immediately upon disconnection of the mailbox and upon account deletion
• Lead capture data: retained for the duration of the customer's subscription and accessible through the dashboard or Google Sheets
• Call audio recordings: audio recording is active only for calls with the Provider's demonstration assistant (the demonstration number, the trial call requested from the website and the callback of the personalized demo) and is automatically deleted within a maximum of 90 days. For customers' calls (inbound and outbound) on the off-the-shelf solutions TrueReply processes and retains only transcripts and metadata, not the audio recording; on tailor-made solutions audio recording may be provided for on the Controller's instructions, with the retention period set out in the relevant agreement
• Outbound campaign contact lists: retained for the duration of the customer's subscription and removed upon account deletion. This also applies to rows copied from the customer's contact records: they are a copy of the contact's number, name and variables, independent of the contact record, and when the individual contact is deleted from the contact records the corresponding list row is redacted. Consent attestations (art. 130) are retained as proof of the legal basis, for as long as necessary to demonstrate its lawfulness
• Opt-out and suppression lists: the voice-call suppression list is retained for the duration of the customer's subscription and is removed upon account deletion. The WhatsApp channel suppression list, which collects the opt-outs expressed by data subjects, is instead retained with no expiry and survives the deletion of the customer's account: retaining it ensures that a person who has asked not to be contacted again is not contacted again, not even following the closure of that account (Art. 130 of the Italian Privacy Code). The phone number is not retained in clear text: the list only records a non-reversible cryptographic digest of the contact detail, sufficient to recognise it if anyone attempted to contact that person again and unsuitable for recovering the number. The same conditions and the same reason apply to the email channel suppression list, which is retained with no expiry and collects those who asked not to receive further messages by replying to the customer's connected mailbox, by using the unsubscribe link included in every email sent by the automations, or whose address turned out to be permanently non-existent; here too the address is not retained in clear text but only as a non-reversible cryptographic digest
• Register of WhatsApp threads authorized by an advertisement: where an assistant is configured to answer only the WhatsApp conversations opened through a Click-to-WhatsApp advertisement, the service records every thread so authorized. This register is not an opt-out list: it is written for every authorized conversation, even where no opt-out has ever been expressed, and it serves to establish which conversations the assistant is authorized to answer and to give effect to any subsequent opt-out. It contains the data subject's phone number, the advertisement click identifier, and the headline and the URL of the advertisement the conversation originated from. It has no automatic expiry, but it is removed upon account deletion: before removal, any opt-outs expressed on those threads are carried over to the WhatsApp suppression list described in the previous point, so that deleting the register cannot cause the wish not to be contacted again to be lost. As of the date of this privacy policy, this configuration cannot be enabled by customers and is in use only on TrueReply's own WhatsApp number
• Unified contact record: it has no automatic expiry and remains available for as long as the customer's account exists, the customer being its Controller; it is deleted upon account deletion. The same applies to the customer's choice of who answers each contact, which stays on the contact record, and to the list of names of the people in its team, which follows the account. This is a deliberate choice: the contact record is the customer's own register of contacts, with a purpose of its own, distinct from conversation content, which remains subject to the 6-month limit (this also applies to a record created from a received email: the email conversation is deleted 6 months after the last activity, while the record with the sender's name and address remains). The register of proactive messages received by an individual contact is deleted together with the contact it refers to, as are the free-text note and the status possibly set on it, which have no expiry of their own: the customer may clear the note and remove the status at any time, and the service keeps no history of their versions. The customer may also delete an individual contact at any time, from the Contacts page of the dashboard, in order to act upon a data subject's request: the deletion removes the contact, the contact details identifying them, the choice of who answers, the free-text note and the status possibly set on it and the register of messages received, and removes the link to the contact record from the conversations and automation executions that referred to it (conversations remain subject to their own 6-month term: from the dashboard the customer can delete an individual email thread, whose received messages are moved to the Trash of the connected mailbox while the copies held in the sent mail stay in the mailbox, whereas conversations on the other channels, namely website chat, WhatsApp and phone calls, cannot be deleted individually and are deleted automatically when that term expires; to act upon a data subject's erasure request before that term, the customer asks TrueReply, which carries it out without undue delay)
• Automation execution data: the events that trigger them are retained for 30 days; executions, their steps, and waits for a reply for 90 days. The flow definitions configured by the customer and their versions have no automatic expiry and remain for as long as the customer keeps the account: deleting them from the dashboard archives them, retaining their versions as evidence of the configuration applied. Upon account deletion the definitions, their versions, the executions with their steps, the waits for a reply and the secrets registered for automations calling third-party APIs are removed by the automatic deletion procedure; the events that trigger the automations do not fall within it and delete themselves within 30 days by virtue of their own expiry
• Data of partner agencies and proof of acceptance of the contractual documents: retained for the whole duration of the relationship with the agency and, after it ends or if the registration is not approved, for the period needed to demonstrate the application and the acceptance and to protect the Data Controller’s rights. When an operator is removed, their access as an operator of the agency is revoked immediately; their email address remains linked to their user account for the same period, and the operations they performed remain in the log of relevant operations (audit) for 24 months
• Log of relevant operations (audit): 24 months. It records the operator who performed the operation, their IP address, the action, the date and time, and details specific to each operation. It also records every transmission of data to the outside performed by the automations configured by the customer, with the destination and the outcome only and never the content transmitted: the address of the system called and the method of the HTTP call, without path, query parameters, headers, or request body; the Google Sheet and the destination tab, without the values of the row written; the recipient of the email notification. The recipients of WhatsApp sends and of email notifications appear in masked form; other data appear in full, in particular the phone number manually added to an opt-out list, the phone numbers the customer activates, deactivates, sets as call forwarding or uses as caller ID in campaigns, and the description of the consent source declared when importing campaign lists. The log survives account deletion because it is the evidence of compliance
• Browsing data (GA4, Clarity, Meta Pixel): according to the retention policies of the respective providers (typically 14–26 months)
• Newsletter data (Brevo): until consent is revoked by the data subject
• Widget session data (localStorage): 30 minutes of inactivity (session); the visitor ID persists until the user manually clears browser data

Data deleted, whether at the expiry of the periods above or upon request, may remain in the service's backup copies, used only to restore the service after a failure, for a maximum of 14 days.

8. Rights of the data subject

Pursuant to Articles 15–22 of the GDPR, the data subject has the right to:

• Access: obtain confirmation of the existence of personal data concerning them and to receive it in an intelligible form
• Rectification: obtain the correction of inaccurate data or the integration of incomplete data
• Erasure: obtain the erasure of their personal data in the cases provided for by the GDPR
• Restriction: obtain the restriction of processing in the cases provided for by the GDPR
• Portability: receive their data in a structured, commonly used, and machine-readable format
• Objection: object to the processing of their data for reasons related to their particular situation
• Withdrawal of consent: withdraw at any time any consent given, without affecting the lawfulness of processing based on consent prior to withdrawal

To exercise their rights, the data subject may send a request to info@truereply.it. The Controller will respond within 30 days of receipt of the request. TrueReply account holders can also exercise, on a self-service basis from the dashboard (Settings section), the right to data portability and account deletion, with a 30-day grace period before permanent erasure, and, from the Contacts page, the export and deletion of an individual contact. The self-service export produces a structured JSON file covering account data, the configuration of the assistants and their conversations (up to 5,000 per assistant, with an explicit indication of any truncation) and the unified contact record (up to 5,000 contacts, with the same truncation indication, in intelligible form). It does not cover the flow definitions and automation execution data, outbound campaigns with their lists and attestations, the opt-out lists, and the log of relevant operations: these data are provided upon written request to info@truereply.it, within the statutory time limits. Integration credentials and secrets are never included in the export.

The data subject also has the right to lodge a complaint with the Italian Data Protection Authority (www.garanteprivacy.it).

9. TrueReply's role in the processing of end users' data

TrueReply acts as a Data Processor on behalf of its customers (Data Controllers) with respect to the data of end users interacting with the chatbots, the inbound and outbound voice assistant, the WhatsApp channel and, where activated, the email channel, as well as with respect to the unified contact record and to the execution of the automations configured by the customer, including the transmission of data to the third-party systems the customer designates. The customer who installs the TrueReply chatbot on their website is responsible for informing their visitors about the processing of personal data via the chatbot, in compliance with the GDPR.

Likewise, the customer who connects their own mailbox to the service remains the Data Controller of the correspondence received in it and of the correspondence sent from it, and is required to inform their correspondents, pursuant to Articles 13 and 14 GDPR, that incoming messages and messages sent from the mailbox are processed with the assistance of an artificial intelligence assistant and of an external data processor. That duty to inform extends to the recipients of the messages sent from the mailbox. TrueReply neither contacts nor informs such correspondents directly.

Likewise, the customer who sets up the members of their own team to receive appointments, or who enters their names among the people who answer contacts, remains the Data Controller of their data and is required to inform them, pursuant to Articles 13 and 14 GDPR, that such data are processed by an external data processor and, for appointments, with the assistance of an artificial intelligence assistant. TrueReply does not inform such people directly.

The relationship between the customer (Controller) and TrueReply (Processor) is governed by the Data Processing Addendum pursuant to Art. 28 GDPR, available at /dpa, which forms an integral part of the Terms and Conditions. When the customer has entrusted the management of their account to a partner agency, the agency acts in it as a sub-processor of TrueReply (section 5).

10. Google User Data (Google API Services)

TrueReply integrates with Google Calendar via the Google API Services, after the user's explicit consent through an OAuth 2.0 flow. This section describes which data we receive, how we use it, how we protect it, and how the user can revoke access at any time.

10.1 Scopes requested

We only request the minimum scope strictly necessary for the functionality. We do not request the full calendar scope nor calendar.settings, and we do not operate on calendars other than those the customer has configured for the assistant (described above), except for the verification-only reads described in section 10.2.

10.2 How we use Google data

• Availability lookup (freebusy.query): when a person asks the customer's assistant for an appointment, TrueReply queries in real time the availability of the assistant's calendar or, if the customer has set up team members, of the calendars of the members who offer the requested service and of the calendars the customer indicates as their other commitments (for example leave or another agenda), to compute open slots consistent with the customer's configured working hours. From the availability request we receive busy intervals only, with no titles and no attendees, and we do not persist them. If the customer has set that a location hosts only one appointment at a time, we also read from the other team members' calendars, for the relevant window only, the times, status, free/busy indication and type of the events and the calendar owner's response, with no titles, no descriptions and no identity of the attendees, and we do not persist them.
• Event creation (events.insert): upon appointment confirmation, TrueReply creates the event on the customer's calendar or, with team members, on the calendar of the member chosen. The event's content (title, description, attendees) is derived exclusively from what the person provided and from the text template the customer configured; when the customer has a service catalog, the event also states the service booked. If the person left an email address, it is added as an attendee and Google delivers its own invitation to them; if they did not — since September 2, 2026 an email address is no longer mandatory to book, because it is the customer who decides which details the assistant must collect — the event is created with no attendees and no email is sent by anyone.
• Hashed identifiers on the event: at creation we write a few technical markers into the event, among its private properties (extendedProperties.private) and, with the same keys, among its shared properties (extendedProperties.shared): a flag stating that the event was created by our assistant, the assistant's identifier (in the shared properties in pseudonymized form), the cryptographic fingerprint of the email address and phone number used to book (HMAC-SHA-256 with a dedicated secret key, truncated to 128 bits) and, when the customer has set up team members or services, the internal identifier of the member and of the service, not their name. Contact details are never written in clear text into these properties. They serve one purpose only: finding the appointment of the person who asks to move or cancel it without having to read the event's title or description, which are texts composed by the customer and may contain anything. The shared properties exist because Google keeps them when the event is moved to another calendar, while private ones are not; they are visible to the event's attendees, through the Google API and exports and not in the Google Calendar interface. The fingerprint is not reversible and, being computed with a key that never leaves our system, no one outside it can compute it for a known contact detail.
• Appointment lookup (events.list): when a person asks to move or cancel, we search for their appointment on the assistant's calendar or, with team members, on each member's calendar, and only in the future window within the booking horizon the customer configured, in two ways: by fingerprint of the contact details among the event's markers, private and shared (events created by the assistant from September 2, 2026 onwards) and, for appointments created before that date that carry no fingerprint, with a search restricted to the attendee's email address. Of each event returned we retain, for the duration of the request only, a minimal projection: identifier, start and end, who organizes it, the attendees' addresses and the markers. In the search to move or cancel, the title, description, location and conferencing data of the events we read never enter the processing: they are not copied, not recorded, and never sent to any artificial-intelligence model.
• Appointment moved by the customer (events.get, events.list): for assistants that have more than one calendar, or that changed one recently: if the customer has moved an appointment to another calendar (for example by changing the event's calendar in Google Calendar) and, when the person asks to move or cancel it, the event is not where we expect it, we look for it, read-only, by identifier and, if the channel has proven the person's contact detail, by the event's markers, on the other calendars the customer has configured for that assistant and, for a limited period (up to seven days after the last appointment that could be booked there), on those the customer has removed. If we find it and Google did not carry the private markers over with the move, we rewrite them on the event right before moving or cancelling it; rewriting the markers sends no notifications.
• Slot re-check (events.list): before a reschedule we re-read the events of the relevant window together with their identifiers, so that the appointment being moved can be excluded from the count: without that it would overlap itself, and every short reschedule would be impossible.
• Event re-read (events.get): immediately before a reschedule or a cancellation, to verify that the event still exists, has not already been cancelled, and is actually organized by the calendar on which we manage it.
• Reschedule (events.patch): we modify the start and end date and time and, if the customer has configured locations for appointments, the event's location, which follows the new time slot. Every other part of the event — attendees, reminders, video-conferencing link, private and shared properties — is left exactly as it is, except for the markers that the customer's move to another calendar caused the event to lose, which we rewrite as described above. Google notifies the reschedule to attendees who have an email address.
• Cancellation (events.delete): the event is deleted from the calendar and Google notifies the cancellation to attendees who have an email address.
• Identity verification beforehand: the assistant does not move or cancel an appointment for whoever asks. Before any modification it is our server that verifies the appointment belongs to the person speaking: because it was booked in that same conversation, because the channel has already proven the contact detail (caller ID, WhatsApp sender verified by Meta), or because the person states the details they booked with and the server compares them against the event. The comparison is performed by the server and not by the artificial-intelligence model, which merely reports what the person says; the negative outcome is always identical and never reveals whether an appointment exists nor which detail does not match.
• Verification of the team members' calendars (calendarList.get, freebusy.query): when the customer saves or changes the team members, we ask Google whether each booking calendar is accessible to the connected account with permission to edit events and whether the availability of the calendars indicated can be read, so that the customer is told right away about a missing share. We read the access role, the video calls the calendar allows (if the member's hours include any) and a one-hour test interval, not the content of any event, and we do not keep the result.
• Activating the team members (events.list, events.move): when the customer activates the team members on an assistant that already received appointments on the main calendar, in order to move those appointments to the right member's calendar we read the future events of that calendar and propose the assignment to the customer: for each event created by the assistant we show the date, time, duration and the title in masked form (the first word in full and the initials of the others; initials only for assistants declared as intended for special categories of data), only to the customer or to whoever operates the account on their behalf and without keeping it; other events are only counted. Following the assignment the customer indicates, we then move each appointment to the member's calendar (events.move) without notifying the attendees, rewriting the markers on the event. A member's calendar may belong to another Google account and be shared with the connected one: from then on the event lives in that calendar, which is the destination the customer chose.
• Verification before an automated action (events.get, calendarList.list): if the customer has configured an automation tied to an appointment, for example the reminder sent before the appointment time, before each action of the automation and, during long waits, every half hour, we re-read the event on the assistant's calendar and on the other calendars the customer has configured for that assistant or recently removed from it, to know whether the appointment has been cancelled or moved: if it is cancelled the automation stops, if it is moved the automation realigns to the new time. If the event appears cancelled we also look for it, by identifier, on the other calendars where the connected Google account can write, asking Google only for the event's status and time, because an event moved to a calendar other than the assistant's leaves a cancelled event on the original calendar; if we find it, the automation follows its new time. The verification only reads and changes nothing; if Google does not respond, the automation proceeds.

We do not use Google data for advertising purposes, we do not sell it, we do not share it with third parties, and we do not use it to train machine-learning models.

10.3 Google data retention and protection

• OAuth refresh tokens are encrypted at rest via envelope encryption: AES-256-GCM with a random Data Encryption Key per token, itself wrapped with Google Cloud KMS (keyring truereply-secrets, key oauth-tokens, 90-day rotation). Only our backend Cloud Function holds the IAM permission to decrypt the DEK.
• Access tokens are cached only for their validity window (typically one hour) and never persisted longer than necessary.
• All Google data in transit travels over TLS 1.2+ (HTTPS) only.
• What we keep from the calendar, and why. We do not keep a copy of the customer's agenda, but it is not true that nothing about the appointments remains with us. On the conversation in which the appointment was booked we retain the Google event identifier, the start and end time, the appointment's state (confirmed, rescheduled, cancelled), the previous times in case of a reschedule, and an indication of how the identity of whoever requested the change was proven (from the same conversation, from the channel, or through verification of the contact details) — never the contact detail itself. The event title is recorded there too, except on assistants the customer declared as intended for the processing of special categories of data, for which it is omitted. When the customer has set up team members or services, the same record also holds the team member the appointment was booked with, the service booked (for assistants the customer has declared as intended for special categories of data the service name is omitted and only an internal identifier remains), a fingerprint of the name of whoever booked, computed with a key of our system, which is not the name and is used to decide whether two simultaneous bookings are for different people, a fingerprint of the calendar on which the appointment was booked or moved, and the times the assistant tried to book that another booking had just taken. These are the minimum data the assistant needs in order to know, in the later turns of the same conversation, what it has already booked: without them it would offer back as "busy" the very slot it just created, or create a second appointment instead of moving the first. They follow the retention of the conversation they belong to (section 7: at most 6 months from the last activity) and are deleted together with it.
• What we do not keep. The free/busy availability and the event lists read to compute slots, to find an appointment, to re-check a time, to verify an appointment before an automated action or to propose to the customer the assignment of appointments when activating the team members are not persisted in any database: they live in memory for the duration of the single request only.
• Configuration of team members and calendars. The data of the team members the customer enters (name, any other names, description, services offered, working hours and locations) and the identifiers of their calendars, which for a collaborator are often an email address, are part of the assistant's configuration: they remain as long as it exists and are deleted with it, including when the account is deleted. The identifier of a calendar the customer removes from an assistant stays in a technical list, used read-only to find the appointments left on that calendar, until seven days after the last appointment that could be booked there; after that it is no longer used and in any case it is deleted with the assistant.
• So that identity verification cannot become a way to discover whether a given person has an appointment with a customer, we keep three counters of failed attempts: one per conversation, one per assistant per day, and one per contact detail declared during verification. They contain numbers only — no contact detail, neither in the content nor in the document identifier, where a contact detail appears only as a non-reversible cryptographic fingerprint — and they delete themselves after 24 hours, except the per-assistant one which is deleted after 7 days.
• Access to Google data is restricted to TrueReply's backend Cloud Function (europe-west1). The voice service (Cloud Run) never holds tokens nor decrypts them: it calls authenticated internal endpoints that return only the aggregated operation result.

10.4 Limited Use disclosure

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

10.5 Revocation and deletion

The user can revoke access to their Google data at any time:

• from the TrueReply dashboard: Integrations → Google Calendar → Disconnect (revokes the refresh token on Google's side and deletes the calendarConnector record from Firestore).
• directly from Google: myaccount.google.com/permissions.

Upon disconnection, the encrypted refresh token is removed from our Firestore within seconds. Residual access tokens expire automatically within one hour.

10.6 Contact for Google data

Questions about Google data handling: info@truereply.it.

11. Security measures

The Controller adopts technical and organizational measures appropriate to ensure a level of security commensurate with the risk, including:

• Encryption of data in transit (HTTPS/TLS) and at rest (Firebase/Google Cloud encryption)
• Authentication via Firebase Authentication with cryptographic hashing of passwords
• Payment processing via Stripe (PCI DSS Level 1 certified), with no transit or storage of card data on TrueReply servers
• Tenant data isolation: each customer accesses only their own data through Firestore security rules
• Application-level encryption, via envelope encryption with a dedicated Google Cloud KMS key, of the highest-impact secrets entrusted by the customer for the operation of integrations: the Google Calendar OAuth refresh token, the WhatsApp Business access token, and the secrets the customer registers for automations towards third-party APIs. The cleartext value of such secrets is never returned by any interface of the service; automation secrets are additionally bound to the hosts the customer authorizes at registration time
• Field-level encryption of conversation content and of automation execution data (execution context, truncated summary of each step's parameters and outcome, error message), on a separate Google Cloud KMS key, for the assistants the customer has declared as intended for the processing of special categories of data; the same encryption protects, for all customers, the free-text note that the customer may write on a contact
• Controls on the destinations of the HTTP calls the customer configures in automations: internal, private, and reserved network addresses are blocked, and the connection is made only to the verified IP address
• Rate limiting on public endpoints to protect against abuse
• Widget in Shadow DOM for isolation from the hosting page context

12. Changes to this policy

The Controller reserves the right to make changes to this policy at any time. Changes will be published on this page with an indication of the last update date. Users are encouraged to consult this page periodically.

13. Contact

For any questions regarding this policy or the processing of personal data, you can contact the Controller by writing to: info@truereply.it