Privacy Policy

Who we are

FrontFoot ("we", "us", "our") is operated by FrontFoot Software Limited, a company incorporated in England and Wales (company number 17214755), registered with the Information Commissioner's Office (ICO registration number CSN2902685), whose registered office is at 71-75 Shelton Street, Covent Garden, London, United Kingdom, WC2H 9JQ. You can reach us at [email protected].

This policy explains what personal data we collect, why we collect it, and your rights over it. It applies to all users of the FrontFoot web application at app.getfrontfoot.ai, the FrontFoot Gmail add-on, the FrontFoot Chrome extension for Gmail, the FrontFoot Outlook add-in, the FrontFoot Zendesk add-on, and the FrontFoot ServiceNow add-on.

Summary

Google API Services: limited use disclosure

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

The Gmail add-on requests the following OAuth scopes:

• gmail.addons.execute — required by Google to run the add-on within Gmail.
• gmail.addons.current.message.readonly — an add-on framework scope (not a Gmail API scope) that lets Google's add-on infrastructure include the open email's sender, subject, and body in the event payload it sends to the FrontFoot add-on when you interact with it. This is how the add-on identifies which email you are currently viewing.
• gmail.readonly — used to read the full email thread of the message you are viewing so the AI has the conversation context for a relevant draft, and to sync any reply the CSM has already sent back into the FrontFoot conversation history.
• gmail.compose — used to create the AI-generated reply as a Gmail draft threaded with the open conversation, and to delete any previous FrontFoot-created draft for the same thread when a new one is created. The add-on opens the new draft in a Gmail compose window for you to review and send manually.
• userinfo.email — used to read your Google account email address from the identity token included in add-on events, so the add-on can associate your FrontFoot token with your Google identity and avoid asking you to re-enter your token each time you open an email.

If your organisation has separately enabled the FrontFoot email-automation feature and connected a shared mailbox, the following additional OAuth scopes are requested at the time the tenant administrator authorises that connection:

• gmail.readonly — used to receive push notifications of new inbound messages via Gmail's watch API and to read the content of each new message. FrontFoot uses Gmail Push Notifications (Google Cloud Pub/Sub) to detect new messages; it does not poll the inbox or modify any labels.
• gmail.send — used to send the AI-generated reply from the connected shared mailbox.
• userinfo.email — used during the OAuth handshake to confirm which Gmail mailbox the tenant administrator authorised, so the connection is stored against the correct organisation.

We do not access attachments, your address book, calendar, or any mailbox folders or labels other than the email thread currently open in front of you (Gmail add-on and Chrome extension) or new inbound messages in the shared mailbox you have connected (email-automation).

In line with the Limited Use requirements, FrontFoot:

• Uses Google user data only to provide or improve the user-facing features of FrontFoot — drafting reply emails, threading conversations, and syncing the CSM's actually-sent reply back into the FrontFoot conversation history. Google user data is not used for any other purpose.
• Limits transfer of Google user data to other applications only as necessary to provide or improve those user-facing features (the AI providers and any CRM provider your organisation has configured — see "Who we share data with"), to comply with applicable law, or as part of a merger, acquisition, or sale of assets with users' explicit consent.
• Does not use Google user data for serving advertisements, including retargeting, personalised, or interest-based advertising.
• Does not allow humans to read Google user data unless: (a) we have obtained explicit consent from users to read specific data — see "Staff access to customer content" below; (b) it is necessary for security purposes such as investigating abuse; (c) it is necessary to comply with applicable law; or (d) the data has been aggregated and is used for internal operations in accordance with applicable law.
• Does not use Google user data to develop, improve, or train generalised AI or machine learning models.

Outlook add-in: permissions

The FrontFoot Outlook add-in runs inside Outlook (desktop and web) and declares the following permission in its manifest:

• ReadWriteItem — an Outlook add-in manifest permission that allows the add-in to read the currently open email's sender address, subject, and body via the Office.js API. FrontFoot uses this to identify which conversation the CSM is viewing and to provide the AI with the email content needed to draft a reply. The add-in does not write to the mailbox and does not create Outlook drafts via API.

The Outlook add-in authenticates the CSM using FrontFoot's own token system (via a popup sign-in to FrontFoot). When Outlook makes a Microsoft Graph access token available to the add-in, FrontFoot uses it transiently to read messages in the current Outlook conversation so drafts can reflect customer-visible thread history. The Graph token is not stored by FrontFoot. If Graph history cannot be loaded, FrontFoot falls back to the currently open message only.

Microsoft Graph API: scopes

FrontFoot's email-automation feature also supports Microsoft 365 mailboxes via Microsoft Graph. If your organisation connects a Microsoft 365 shared mailbox, the following OAuth scopes are requested when the tenant administrator authorises the connection:

• Mail.ReadWrite — used to poll the connected shared mailbox for new inbound customer emails, read each new message, and mark it as read after processing so it is not handled twice.
• Mail.Send — used to send the AI-generated reply from the connected shared mailbox.
• offline_access — required by Microsoft to issue a refresh token so FrontFoot can maintain the connection without prompting the tenant administrator to re-authorise on every poll cycle.
• User.Read — used during the OAuth handshake to confirm which Microsoft 365 mailbox the tenant administrator authorised, so the connection is stored against the correct organisation.

We do not access attachments, calendar, OneDrive, Teams data, the address book, or any mailbox folders other than new inbound messages in the shared mailbox you have connected.

The same data-handling commitments apply as for Google data: Microsoft user data is used only to provide the FrontFoot service; is not used for advertising; is not used to train, develop, or improve generalised AI or machine learning models; and is not transferred to third parties except as necessary to provide the service or as required by law.

Microsoft Dynamics 365 API: scopes

FrontFoot's CRM lookup feature supports Microsoft Dynamics 365 via the Dataverse Web API. If your organisation connects a Dynamics 365 environment, the following OAuth scopes are requested when the tenant administrator authorises the connection:

• user_impersonation — grants FrontFoot delegated access to your Dynamics 365 environment to perform read-only contact and account lookups on behalf of the authorising administrator. FrontFoot uses this scope only to look up contact and account records by email address; it never creates, updates, or deletes records.
• offline_access — required by Microsoft to issue a refresh token so FrontFoot can maintain the connection without prompting the tenant administrator to re-authorise on each lookup.

We do not access any Dynamics 365 data beyond the specific contact and account fields your organisation has configured for CRM lookup. We do not access opportunities, activities, notes, or any other Dynamics entities.

The same data-handling commitments apply as for other Microsoft data: Dynamics 365 data is used only to provide the FrontFoot service; is not used for advertising; is not used to train, develop, or improve generalised AI or machine learning models; and is not transferred to third parties except as necessary to provide the service or as required by law.

What data we collect and why

Account and identity data

When you sign up or log in, we collect your name and work email address via Clerk (our authentication provider). This is necessary to create and maintain your account.

Customer email content

FrontFoot processes customer email content in these contexts:

1. Gmail add-on and Chrome extension: when a CSM opens a customer email in Gmail and uses FrontFoot to draft a reply, FrontFoot reads the open email's sender, subject, body, and customer-visible thread history. In the add-on this arrives through Google's add-on event payload and Gmail API. In the Chrome extension, the current open message is read from the Gmail page and, when Google access is available, the Gmail API is used to read the full thread history. This data is sent to the configured AI provider to draft a response, and is stored as part of the conversation thread in your organisation's FrontFoot account so subsequent drafts on the same conversation have prior-turn context.
2. Outlook add-in — when a CSM opens a customer email in Outlook and uses FrontFoot to draft a reply, the add-in reads the open email's sender, subject, and body via the Office.js API. When Graph access is available, FrontFoot also reads and stores customer-visible messages in the current Outlook conversation so future drafts have prior-turn context. This data is sent to the configured AI provider and stored as part of the conversation thread in the same way as the Gmail add-on.
3. Zendesk add-on: when a CSM opens a customer ticket in Zendesk and uses FrontFoot to draft a reply, the add-on reads the ticket subject, description, customer contact details, and public ticket comments. Private comments and internal notes are not imported into FrontFoot. Public ticket content is sent to the configured AI provider and stored as part of the conversation thread.
4. ServiceNow add-on: when a CSM opens a customer case in ServiceNow and uses FrontFoot to draft a reply, the add-on reads the case subject, description, and customer contact details. This data is sent to the configured AI provider and stored as part of the conversation thread.
5. Email-automation — when your organisation has connected a shared mailbox, FrontFoot polls that mailbox approximately once per minute. Each new inbound email's sender, subject, and body is read once per poll cycle, sent to the configured AI provider, and stored as part of the conversation thread. The original email is marked as read in the connected mailbox after processing so it is not handled twice.
6. Web application — when a CSM pastes a customer email into the FrontFoot web app, the text they paste, along with any subject, customer name, or email address they enter, is sent to the configured AI provider and stored as part of the conversation thread.

In these contexts, customer email and ticket content is stored in your organisation's FrontFoot account, scoped by tenant, until soft-deleted by a CSM or hard-purged by a tenant administrator (see "Data retention" below). Customer email and ticket content is never used to train, develop, or improve any AI or machine learning model.

CRM contact context (optional)

If your organisation has enabled CRM lookup (HubSpot, Salesforce, or Microsoft Dynamics 365), the customer's email address from an inbound message is sent to the configured CRM and the matching contact and company fields are returned and used to enrich the AI's context. The fields returned are stored on the conversation thread alongside the email content.

CRM write-back (optional)

If your organisation has enabled CRM write-back, a CSM may choose to log a decision note to your CRM after a thread reaches a terminal outcome (resolved, churned, or stalemate). The note is written as a completed Task in your CRM, attached to the contact linked to the thread. The note contains: the thread outcome, any concession type and detail, the CSM's name, the thread subject, and an AI-generated decision note summarising the customer's ask, the recommended response, and the rationale. The CSM reviews and edits the note before confirming the write; no write happens without a deliberate confirmation step. FrontFoot retains a record of the CRM task ID and the timestamp of the write; it does not retain a copy of the note body after writing. The note is subject to your CRM provider's own data handling and retention policies once written.

Marketing website analytics

The FrontFoot marketing website (getfrontfoot.ai and its subpages) uses Google Analytics 4 (GA4) via Google Tag Manager to measure website traffic and understand how visitors find and navigate the site. GA4 collects standard web analytics data including page views, session duration, referral source, browser type, and anonymised IP address. This data is processed by Google LLC (US) under the EU–US Data Privacy Framework and EU Standard Contractual Clauses / UK IDTA. Google Analytics cookies are only set if you accept analytics via the cookie banner shown on your first visit to the marketing website; if you decline, no GA4 cookies are set and no analytics data is collected. GA4 data is used solely for marketing website analysis and is not linked to your FrontFoot account or any in-app data.

Usage analytics

We collect product usage data via PostHog to understand how FrontFoot is used and to improve it. This includes:

• Product events — page views, feature usage events, session duration. Events do not contain email content, customer names, or any free-text content from your customer messages.
• Session recordings of the FrontFoot user interface — recordings of the FrontFoot web application UI as a user interacts with it, used to investigate UX issues and feature adoption. Customer-supplied text (customer email addresses, names, message content, draft text, CRM field values) is suppressed from session recordings via a per-element opt-out applied to every UI element that displays such content. Session recordings capture interaction patterns (clicks, scrolling, navigation) and structural UI state, not customer email content.

How we use your data

• To provide the service: authenticating you, generating draft replies, storing your organisation's conversation threads.
• To communicate with you: account notifications, support responses, and (with your consent) product updates.
• To improve the product: aggregated, anonymised usage analytics only.

Who we share data with

We use the following sub-processors to provide the service. Each is contractually bound to process data only as instructed and to maintain appropriate security standards.

• Anthropic Claude: AI model provider. Email content sent for draft generation is processed under Anthropic's API terms. Anthropic does not use API-submitted data to train its models.
• Clerk: authentication and user management.
• Render: cloud infrastructure — web hosting and managed PostgreSQL database.
• Cloudflare: network edge provider. All HTTPS traffic to FrontFoot passes through Cloudflare, which provides TLS termination, DDoS mitigation, WAF, and CDN. Cloudflare processes IP addresses and request traffic as part of this role.
• Google Workspace (Gmail API) and Microsoft 365 (Microsoft Graph API): email read/send for organisations that have connected a Gmail or Microsoft 365 mailbox to FrontFoot's email automation feature.
• HubSpot, Salesforce, Microsoft Dynamics 365: CRM contact lookup and optional CRM write-back, each configurable per organisation. If your organisation enables CRM lookup, the customer email address from an inbound message is sent to your configured CRM to resolve the matching contact record; CRM contact lookup is read-only. Separately, if your organisation enables CRM write-back, FrontFoot writes a completed activity (Task) record back to the contact in your CRM after a thread reaches a terminal outcome — see the "CRM write-back (optional)" section above for the record's contents and the CSM review step.
• PostHog: product analytics and session recording. Receives anonymised usage events and session recordings of the FrontFoot UI. Session recordings suppress customer-supplied content via per-element opt-out (ph-no-capture) — no email content, customer names, or message text is captured.
• Sentry: error monitoring. Receives server-side error reports including stack traces, request paths, and internal identifiers (tenant ID, request ID) to help diagnose and fix production issues. No customer email content, names, or message bodies are included in error reports.

We do not sell personal data. We do not share personal data with advertising networks, data brokers, or any third party not listed above.

International data transfers

FrontFoot is operated from the United Kingdom. Several of the sub-processors listed above are located outside the UK and European Economic Area (EEA) — including Anthropic and Clerk. Render (cloud infrastructure) is hosted in the EU (Frankfurt, Germany) and PostHog (product analytics) uses an EU-hosted instance; no international transfer mechanism is required for data processed by either. Where personal data is transferred internationally to provide the service, we rely on one or more of the following lawful transfer mechanisms:

• UK adequacy decisions issued by the UK government, where an adequacy determination is in force for the recipient country.
• UK International Data Transfer Agreement (IDTA), or the EU Standard Contractual Clauses with the UK Addendum, executed with the relevant sub-processor.
• EU-US Data Privacy Framework (and its UK extension), where the sub-processor is self-certified under the Framework.

Each sub-processor is contractually required to apply technical and organisational measures equivalent to those required under UK GDPR. A copy of the relevant transfer mechanism for any sub-processor is available on request to [email protected].

Staff access to customer content

By default, no FrontFoot staff member is authorised to access customer email content, CSM drafts, public support-ticket comments, imported Outlook conversation history, or thread data stored in your organisation's account. As with all hosted SaaS services, FrontFoot retains infrastructure-level access to the underlying database as operator of the platform; that access is governed by the confidentiality commitments in this policy and our DPA, and is limited to what is necessary to operate, maintain, and secure the service.

If a tenant administrator at your organisation explicitly opts in, they can grant a named FrontFoot staff member time-bounded, scope-limited access to read content for a specified purpose (for example, debugging an incident or supporting an onboarding session). Each grant is:

• Created and managed by the tenant administrator only — FrontFoot staff are not permitted to create or modify grants for their own accounts.
• Time-bounded — the grant expires at a date set by the administrator.
• Revocable — the tenant administrator can revoke the grant at any time, with immediate effect.
• Audit-logged — every read by FrontFoot staff during the grant window is logged with timestamp, scope, and accessor, and is visible to the tenant administrator in real time. The log is append-only and persists after the grant expires.

Within your own organisation, access is governed by Clerk roles: a CSM (member) can read only their own threads; a tenant administrator can manage configuration and user access. Inviting and managing CSMs within your organisation is your responsibility.

Data retention

We will not retain customer email content or other personal data for longer than is reasonably necessary to provide the service. Account data, conversation threads, and message data are stored for the duration of your organisation's subscription. Conversation threads can be soft-deleted by a CSM at any time, and a tenant administrator can hard-purge an organisation's data at any time. On account closure, we hard-purge your organisation's data within 30 days of receiving a written request to [email protected]. When a CSM opens an email and the Gmail add-on, Chrome extension, or Outlook add-in loads, FrontFoot reads the email's sender, subject, body, and available customer-visible thread history to display the drafting surface and classify the email. If the CSM does not choose to track that conversation in FrontFoot, that data is not stored. Email or ticket content is only stored once a CSM tracks the conversation, or when an already-tracked conversation receives a new customer-visible reply that must be saved so a draft can be generated on request.

Expired tenant accounts are automatically purged — including all conversation threads, messages, and associated data — within 30 days of account closure via a daily automated job. There is no configurable per-thread automated retention schedule; thread deletion is manual (CSM soft-delete or tenant administrator hard-purge on request).

Security

All data is encrypted in transit using TLS 1.2 or higher. Stored data is protected at rest by Render's managed disk encryption. In addition, sensitive credentials — API keys and OAuth refresh tokens for AI, email, and CRM providers — are encrypted at the application layer using AES-256-GCM with per-organisation HKDF-derived keys before being written to the database. Plaintext credentials are never returned by any API endpoint and are never written to logs. FrontFoot, as the service operator, holds the application-layer encryption key; credentials are protected against external breach and are isolated per organisation, but FrontFoot retains the technical ability to decrypt them as part of platform operations. This is standard for hosted SaaS services and is governed by our DPA.

Tenant data isolation is enforced at two layers simultaneously. At the database layer, PostgreSQL row-level security policies on all tenant-scoped tables prevent cross-tenant access; the application's runtime database role holds no direct table grants and must switch to a tenant-scoped role per transaction, so a missing application-layer check produces a database-level permission error rather than a silent bypass. At the application layer, every tenant-scoped query is additionally parameterised with the authenticated organisation's identifier and includes an explicit tenant filter. The integration test suite (which runs on every change in CI) explicitly verifies that one organisation cannot read or modify another organisation's threads, messages, or configuration via any endpoint. Cross-tenant operations are restricted to a small enumerated set of platform-level paths, enforced by the database role model rather than by application convention alone.

Your rights

If you are located in the UK or EEA, you have rights under UK GDPR / GDPR including the right to access, rectify, erase, and export your personal data, and to object to or restrict processing. To exercise any of these rights, contact us at [email protected]. We will respond within 30 days.

You may also revoke the FrontFoot add-on's access to your Google account at any time via your Google Account permissions.

Cookies

We use three categories of cookie:

• Strictly necessary cookies — session and authentication cookies set by Clerk to keep you signed in to the FrontFoot app. These are required for the service to operate and do not require your consent.
• App analytics cookies — a first-party cookie (ph_*) set by PostHog, scoped to our domain, used to understand how the product is used. This cookie is only set if you accept analytics via the consent banner shown on your first visit to the app.
• Marketing website analytics cookies — cookies set by Google Analytics 4 (_ga, _ga_*) on the marketing website (getfrontfoot.ai). These are only set if you accept analytics via the cookie banner shown on your first visit to the marketing website. They are not set in the FrontFoot app.

When you first visit the FrontFoot marketing website, a banner gives you the choice to accept or decline Google Analytics cookies. When you first use the FrontFoot app, a separate banner covers PostHog analytics. Your preferences are stored in your browser's local storage and respected on every subsequent visit. We do not use advertising cookies or share cookie data with third parties for advertising purposes.

Children

FrontFoot is a business-to-business service intended for use by adults in a professional context. The service is not directed at children. We do not knowingly collect personal data from children, and if we become aware that we hold data from a child without appropriate parental consent we will delete it promptly.

Changes to this policy

We may update this policy from time to time. We will notify active users of material changes by email and update the "last updated" date above. Continued use after the effective date constitutes acceptance.

Contact

For privacy questions or to exercise your rights: [email protected]