Ask
Features Pricing WordPress Security Docs
Sign in Start free

Contents

  • Who this is about
  • What we hold about customers
  • What the widget collects
  • Why we hold it
  • Model providers
  • Retention
  • Rights, and who answers them
  • How it is protected
  • Changes

  • Privacy policy
  • Data processing
  • Terms of service
  • Imprint

Last updated 2026-08-09 - version 1.0

Privacy policy

Who this is about

Two different groups of people show up in Ask, and they have different relationships with us.

  • Customers - the people and organisations with an Ask account. For their account data we are the controller.
  • Visitors - the people who talk to a customer's bot on the customer's own site. For that conversation data the customer is the controller and we are their processor, acting on their instructions. Their data processing agreement governs it.

Our own identification details are on the imprint.

What we hold about customers

  • Account: work email address, a password hash if you use one, the name you give, and which workspaces you belong to. If you sign in through your own identity provider, the identifier it gives us instead of a password.
  • Workspace: organisation name, website address, the content you put in, your instructions and their version history, your routing and appearance settings.
  • Billing: plan, credits granted and spent per period, and the identifiers our payment processor gives us. Card details never reach our servers.
  • Operational: sign-in events, job runs, audit records of sensitive actions such as revealing a masked contact detail, and error logs.

What the widget collects

The widget is deliberately narrow about this, because everything it collects is something a customer then has to account for.

  • The conversation: the messages a visitor sends, the answers the bot gives, and which content the answer used.
  • Contact details a visitor deliberately leaves through a form in the widget - typically an email address when they ask for a follow-up. These are stored as structured fields on the case.
  • Personal details that turn up inside the conversation text are tagged at the point of capture, masked by default wherever a transcript is shown, and never surfaced in analytics. Revealing one is a deliberate, audited action by a member of the customer's staff.
  • Technical data needed to run the conversation and stop abuse: a conversation token, coarse rate-limiting counters, and the site the widget was loaded on.

The widget does not track visitors across sites, does not carry advertising or analytics tags, and sets no cookies for that purpose. Its code is public, so this is checkable rather than merely stated.

Why we hold it

Account and workspace data, to give you the service you signed up for. Billing data, because we have to account for what was charged. Operational records, to keep the thing running and to investigate abuse. Conversation data, because our customer asked us to process it on their behalf - we do not use it for our own purposes, and we do not sell any of it to anyone.

Model providers

Answers are produced by third-party model providers, reached through an aggregation service that selects a provider per request. The full set an answer might reach is listed, dated, in the sub-processor annex. We make no regional guarantee about where an answer is produced, and no guarantee about what a provider does with what it receives - neither is verified end to end yet. When regional pinning is running and checked, this section will say so and the annex will show it.

Retention

  • Transcripts expire on the schedule the customer sets for their workspace.
  • Cases can outlive the transcript they came from, by the customer's choice: the case is their record of what went wrong and stays useful without the visitor's words.
  • Account and billing records are kept while the account exists, and afterwards only as long as we are required to keep them for accounting purposes.
  • Deleting a visitor removes the transcripts, cases, captured contact fields, embeddings, summaries and audit arguments attributable to them. What was charged survives with the attribution stripped, so the billing record stays consistent without pointing at a person.
  • Deleting a workspace is irreversible and takes its content with it.

Rights, and who answers them

If you are a visitor who talked to a bot, the site that ran that bot is the controller: your request goes to them, and we help them carry it out. If you are an Ask customer, come to us directly - access, export, correction and deletion are all available from inside the account area, and the contact page has a route for privacy enquiries that does not go through sales.

How it is protected

Every row belonging to a workspace carries its workspace, and the database enforces that on every query rather than trusting the application to remember, including for our own maintenance roles. A widget only answers on domains its owner has verified. Passwords are hashed with current parameters. The security page is the longer version, including the parts that are limitations.

Changes

Material changes are dated here and shown in the version history below. The sub-processor annex changes on its own cadence and can be subscribed to separately, because it moves more often than this page does.

Version history

VersionDateWhat changed
1.02026-08-09First published.

Product

  • Features
  • Cases and the inbox
  • Instructions and replay
  • Content
  • Channels
  • Pricing

Install

  • WordPress plugin
  • Documentation
  • Start free
  • Sign in

Trust

  • Security and privacy
  • Sub-processors
  • Contact

Legal

  • Privacy policy
  • Terms of service
  • Data processing
  • Imprint

Ask - answers from your own material, with the failures and the leads landing in one inbox.