Privacy Policy

Version 2026-11-01 · Last updated: 1 November 2026

This Privacy Policy explains how Overdesk ("Overdesk", "we", "us") handles personal data. Overdesk is a software-as-a-service product available internationally. If anything here is unclear, email privacy@overdesk.io.

1. Two kinds of data, two roles

Overdesk handles two distinct categories of personal data, and our role differs for each:

• Account data: information about you, our customer, and the people on your team who use Overdesk (name, email, and similar). For this data we are the data controller.
• Support content: the helpdesk conversations we process on your behalf to draft replies, including any personal data about your end customers contained in those conversations. For this data you are the controller and Overdesk is a processor acting on your instructions (GDPR Article 28). We process it only on your documented instructions and for the purposes described in this policy. If you require a separate data processing agreement, contact privacy@overdesk.io.

Visitors to our websites, overdesk.io and docs.overdesk.io, are covered separately in Section 7.

2. Account data we collect

• Identity & contact: your name and email address.
• Technical: IP address and browser user-agent, captured at signup, login, and when you accept these terms, used for security and to evidence acceptance of the terms then in force.
• How you found us: when you sign up, the campaign tags on the link you followed, the page of our website you started on, the site that sent you there, and the button you clicked. We keep it with your workspace record to learn which pages bring us customers, and never use it for advertising.
• Sign-up notices: when anyone starts signing up, our team gets an email with the name, email address and workspace name typed into the form, how they found us, and whether the sign-up email was sent. This happens even if the sign-up is never finished.
• Usage: operational logs and token/usage counts for billing and abuse prevention. Our application logs record identifiers and event types, not the body of your support conversations.
• Billing: handled by Stripe. We store a Stripe customer reference; we do not store your card number.
• Connected accounts: when someone on your team connects a system to Overdesk, we store a label identifying the account they connected, so the dashboard can show which one is in use. Depending on the system that is a workspace name, a site address, or the email address of the account that authorised the connection. Connecting Google Docs asks Google for that address specifically, so we can show whose account the documents are read through.

3. Legal bases (GDPR / UK GDPR)

We process account data on these bases:

• Performance of a contract: to create your workspace, authenticate you, and provide the service.
• Legitimate interests: to secure the service, prevent abuse, keep operational and billing logs, and learn which of our pages bring us customers, balanced against your rights.
• Legal obligation: to keep billing/tax records and respond to lawful requests.
• Consent: only where we specifically ask (e.g. optional communications); you can withdraw it at any time without affecting the service.

Visit counts on our websites rest on our legitimate interest, as Section 7 explains.

Accepting these terms is a record of contract formation, not a GDPR consent to processing. For support content we act only on your documented instructions as your processor; your lawful basis as controller applies.

4. How support content is processed, and how we minimise personal data

To draft a reply, Overdesk sends the relevant conversation text to a large language model, along with the pictures and log files attached to that conversation and the readable text of any page your customer linked to. Before any prompt leaves our system we run a pseudonymisation pass over the text:

• Tokenised before the model sees them: email addresses, phone numbers, international (written with a + country code or a leading 0) and North American (a bare run of digits with no spaces or symbols, and a number split by slashes, can reach the model as written), payment-card numbers, IBANs, cryptocurrency addresses, social-security numbers, MAC addresses, PO boxes, and street addresses introduced by an explicit lead-in ("lives at …", "address: …") are replaced with deterministic placeholder tokens.
• The name of everyone on the customer's side who wrote one of the messages we send to a model is masked, using the structured fields from your helpdesk. That covers writing a draft and every other use of a model that reads those messages, including the assistant answering a question about a report you already have: it reads a copy of that report archived with the names already replaced, and declines to read one archived before we kept that copy. Two records are left as written, for different reasons. A name your helpdesk holds as only one or two letters is left because substituting something that short would corrupt ordinary words elsewhere in the ticket. A name that is really a mailbox or a company is left because it names no person: when a message arrives from a support or billing email address, most help desks file the contact under that word. Your own agents' names are not, which is explained on the Security & Data Handling page.
• Restored only in the draft your agent reviews: the real values are put back into the suggested reply after the model responds, so your team sees a usable draft while the model received placeholders in place of the contact details it found in the text.
• Pictures are sent as they are, and only when we draft. The pass above reads text, and it cannot read inside an image. When a customer attaches or pastes a screenshot, that screenshot reaches the model exactly as they sent it, including anything legible in it: an email address in a browser tab, a licence key in a console, a face. We do this deliberately, because a screenshot with the evidence obscured is a screenshot that cannot answer the question, and a reply written from an unreadable picture is worse for your customer than no reply at all. Up to four pictures per draft, each under four megabytes, and only in the formats the model reads. A picture is sent to the model only while a reply is being drafted. Classifying a ticket, your reports and analyses, and questions asked of Ask Overdesk are handed the message text as your help desk stores it, and never a picture. Where a customer pasted one into a message rather than attaching it, whatever your help desk leaves behind in that text travels with it, which on the help desks we have measured is a web address and not the picture. Log files and other text attachments do go through the pass, like any other text. You can switch the pictures off yourself, on the Customize AI page in your dashboard, and drafts are then written from the words alone. That switch covers pictures only: log files and other text attachments carry on being read, and carry on going through the pass above like any other text.
• A PDF is read the way a picture is, and the same switch turns it off. When a customer attaches a PDF (an invoice, a receipt, an order confirmation, an exported report), the model is handed the file itself, because it reads each page as an image. Everything said about pictures above therefore applies to a PDF, and applies harder: an invoice ordinarily carries a name, a postal address and an amount, and all of it reaches the model exactly as the customer sent it. One document per draft, up to ten pages and four megabytes, and only while a reply is being drafted. A document longer than ten pages is not sent at all, and neither is one that is password-protected, nor one whose length we cannot read. Because a page is read as a picture, the pictures switch on the Customize AI page turns documents off as well: a team that has asked us not to send pictures is not sent PDFs either. There is no separate switch, so that setting cannot be on for one and off for the other.
• Pages your customers link to are opened and read, and only when we draft. When a customer's message links to a page, Overdesk opens that address while the draft is being written and gives the model the readable text it finds there, so the reply can answer what the page says rather than guess from the address. When the page is a WordPress site, the model is also told the WordPress, plugin and theme versions the page's code shows. Up to three pages per draft, nothing is stored, and the text goes through the pseudonymisation pass above like any other text. Three things about this are worth stating plainly. Overdesk makes a request to a third-party website, chosen by your customer rather than by you or by us, so that website learns somebody has opened the address; the request carries none of your help desk credentials and none of your account details, but the address itself travels, and if your customer pasted a link with something personal in it then that is part of the address. The text that comes back is written by whoever controls that address rather than by your team, and the model is told so. And a link to a picture is read as a picture, under the pictures rules above. Only links in your customers' own messages are read, never links your team wrote. You can switch this off yourself, on the Customize AI page in your dashboard, and drafts are then written from the conversation alone with no address ever opened.
• We may try the issue on a private test copy of WordPress, and only when we draft. Once your team lists its products on the Sandbox settings page, Overdesk can start a private copy of WordPress with those products installed, plus any public WordPress.org plugin or theme the customer mentions, and try what the customer describes before the reply is written. It runs on a separate machine we operate at Fly.io, with no access to the internet or to any other system, and the machine is destroyed when the reply is done. The model decides what to do on it, and everything it types there carries the placeholders above rather than the contact details they replaced, so the test site never receives those; a screenshot of the test site is shown to the model like a picture. A record of what was done on it, pseudonymised like the rest of the conversation, is kept with the reply for 180 days. A zip file of your own product that your team adds is kept until your team removes it or the workspace is deleted, and is used only on your own test sites. You can switch testing off on the same page.

Honest limits. This pass is pattern-based and best-effort, and we publish exactly where it stops: see the Security & Data Handling page for the full detail.

• It will not catch personal data with no recognisable pattern. In particular, names of other people written in free text are not detected (we do not run a named-entity model). The people on your customer's side who wrote the messages we send to a model are masked, because your helpdesk supplies each of those names as a structured field; a name mentioned in passing has no field to read.
• URLs, IP addresses, postcodes, and street addresses written without a lead-in are deliberately left intact, both on the way to the model and in the copy we store. Each of those patterns collides with ordinary support text: a five-digit postcode pattern also matches the ticket number "#12345", an IP pattern also matches the version number "4.6.3.1", and a URL pattern also matches "wp-config.php". Redacting them would corrupt the very conversation the model has to read, and it corrupts a stored article just as badly, because a stored article is quoted back to the model as the source of its answer. One consequence worth stating plainly: a password-reset or invite link pasted into a ticket reaches the model intact, and is kept intact in the copy we store. A credential carried inside such a link is replaced when it is long enough to match our API-key and licence-key patterns, or when the query parameter holding it names itself a credential; some are neither. Treat a link pasted into a ticket as retained.
• It does not redact anything you place inside custom prompt instructions that you configure yourself.

Do not rely on this pass as a substitute for your own judgement about what belongs in a support conversation.

Bring your own key. Language-model requests are made using your own Anthropic API key. Your conversations are processed under your agreement with Anthropic, not through an Overdesk-owned AI account. The one exception is text embedding: semantic-search embeddings are generated under an Overdesk-owned Voyage AI account, provided by Overdesk for every workspace; the product does not ask you to supply a Voyage key (see sub-processors below).

If you connect a store, a billing account, or a licence system, Overdesk looks your end customer up in it by the email address they wrote in from, so a draft can answer questions about their own orders, plan, invoices, or licence keys. Two consequences worth stating plainly. Their email address is sent to that system, unaltered, because it is the only thing that can find them; for three of the four it travels as part of the web address of the request, which is somewhere web servers routinely write to their own logs, so if you host the store yourself that address will appear in your own logs. And what comes back is put into the prompt and is deliberately left readable, including the items on an order, so a draft can name what they bought, and the state each order, payment or subscription is in, which covers a refund, an unpaid invoice and a cancellation, since a draft that quotes a tokenised order number answers nothing. The customer's name is the exception in that block. The connected system keeps its own record of it, so where your store spells it differently from your helpdesk, Overdesk registers that spelling too and it is replaced in the same way. What stays readable includes their order numbers, amounts, plan and renewal dates, how many orders they have placed, what they have spent with you, the last four characters of a licence key, and, where a licence system reports them, the web addresses of the sites they installed your product on and the WordPress, PHP and product versions each site last reported. These are your own systems, connected by you, and Overdesk only ever reads from them: it never changes an order, a subscription, or a licence. This is an optional feature on the Pro and Scale plans and during your trial, and it does nothing until you connect one.

When an analysis finds customers who may leave or are frustrated, Overdesk looks them up the same way, in a connected licence system or billing account, and keeps, with that finding, the licences or subscriptions each holds, when they expire or renew, and what they have paid you, so your team can see what is at stake. It never keeps their email address, name or licence key. It keeps only a stand-in for the address, which is how it counts each customer once and finds these facts again. They are removed with the finding, and when you erase that customer.

Your team decides what is sent. By default Overdesk only drafts, and nothing is sent to your end customer without a member of your team reviewing and sending it. If your workspace turns sending on (we enable it for your workspace, and an admin of your workspace turns it on), Overdesk sends the replies your guardrail rules approve without a person reviewing them first. Every other reply stays a draft or a note for your team. For every reply Overdesk sends, it keeps a record of the conversation and message the reply went to and a fingerprint of the reply, never its text, so that a reply it sent is still recognised as its own after the draft is deleted and is never taken for your team's words. Erasing a customer deletes the record for their conversations, and Section 9 says how long it is kept.

5. We do not train models on your data

We do not use your support content or account data to train Overdesk's own models. Draft generation runs on Anthropic under your own API key and is governed by your Anthropic agreement; embeddings run on Voyage AI. We use these providers' commercial API terms, under which your inputs are not used to train their models.

6. Sub-processors

We use the following sub-processors. Support content only reaches those marked "support content". Reports and alerts you route to Slack or ClickUp go to your own workspace with your customers' names replaced by "(customer)", and with contact identifiers such as email addresses and phone numbers (international and North American) left tokenised. The one exception is the record that names no person (described in Section 4); that one reaches your workspace as written. The copy kept in your Overdesk dashboard restores the names, because that copy does not leave your account. An issue your team opens from a conversation goes to your own repository, team, or project on GitHub, Linear, or Jira. Nothing is opened automatically: a member of your team is shown the title and description first and has to confirm them, and contact identifiers are stripped out of that text on the way, one-way, before it is sent.

Reading from a system does not make it a recipient of your data. When you connect Notion, Google Docs, GitHub, Jira, or Linear as a knowledge source, or point Overdesk at your public documentation or forum, Overdesk fetches that content with the access you granted and indexes it. Nothing about your end customers travels in that direction. The one place that needs a sharper statement is a page a customer linked to, described in Section 4: fetching it tells that website's operator that the address was opened, and the address itself is what your customer wrote, so anything they put in the address goes with it. No credential, no account detail and no other part of the conversation travels there, and those sites are not sub-processors because we send them nothing to process on our behalf. Four of those names also appear in the table above: GitHub, Linear and Jira because opening an issue sends text the other way, and Google because the documents are read under Overdesk's own application. Notion is the only one that appears nowhere else, because reading is all Overdesk ever does with it.

Five of those rows are new as of 1 September 2026: Google, and the four customer lookup entries, which have been part of the product since the middle of August and were not written down here until now. Cloudflare was added on 9 October 2026, when we turned on Cloudflare Web Analytics; it already served our websites. Cal.com was added on 23 October 2026: our demo booking page has been hosted there since 18 October 2026 and was not written down here until then.

We will give notice of new sub-processors by updating this page and bumping the version. Enterprise customers may ask to receive advance notice of, and to object to, new sub-processors under the DPA.

7. Cookies and our websites

The app sets only strictly-necessary cookies. sf_session keeps you signed in and secures your session; it is HttpOnly, Secure, and SameSite=Lax. Connecting Help Scout through Overdesk's Help Scout app, Google Docs or Slack sets one more for fifteen minutes, which ties that connection to your browser. We use no advertising, analytics, or third-party tracking cookies.

Our websites, overdesk.io and docs.overdesk.io, are served by Cloudflare, and two things happen there that are not part of the app:

• A security cookie. Cloudflare checks that a visitor is not automated traffic and sets a cookie named cf_clearance, for up to a year, to remember that your browser passed, so the check does not repeat on every page. Cloudflare lists it among the cookies it treats as strictly necessary.
• Visit counts. We count visits with Cloudflare Web Analytics, which sets no cookie and stores nothing in your browser; Cloudflare says it does not fingerprint visitors. It records which page was viewed, the site that linked to it, your country, your browser, operating system and type of device, and how quickly the page loaded. We use these counts, on the basis of our legitimate interest, to learn which pages people read and where the site is slow.
• Booking a demo. The demo link on overdesk.io opens our booking page on Cal.com, a separate site. What you enter there reaches Cal.com and us, and Cal.com's own cookie and privacy terms apply on its page.

When you click a sign-up button on overdesk.io, the campaign tags on the link you followed, the page you started on, the site that sent you there and which button it was travel to the sign-up form in the link's address. Nothing about it is stored in your browser. Section 2 says what we keep once you sign up.

8. Where your data is stored

Overdesk's application and database run in the United States (Fly.io and Neon), and the sub-processors above are US-based providers. If you access Overdesk from outside the US, your data is transferred to and processed in the US; where required by law, we rely on appropriate safeguards for such transfers.

9. How long we keep data

When you delete your workspace, account and support content are removed promptly (only the acceptance, erasure and deletion records and our team's admin action log in the table above are retained; Stripe keeps its own billing history).

10. Data breaches

If we become aware of a personal-data breach affecting support content, we will notify you (the controller) without undue delay and give you the information you reasonably need to meet your own obligations. For account data, we will notify the relevant supervisory authority and affected individuals where the law requires.

11. Security

Credentials, API keys, and webhook secrets are encrypted at rest with AES-GCM. All traffic to Overdesk is over TLS. Each workspace's data is isolated: queries are scoped to a single workspace, enforced by a test gate that fails our build if a new one is not, with a small set of reviewed exceptions (signing you in, billing lookups, and deliberately global maintenance jobs) that cannot expose one workspace's support content to another. The Security & Data Handling page describes this in full.

12. Your rights

Depending on where you live, you have rights over your personal data, including to access, correct, delete, export, restrict, or object to its processing, and to withdraw consent where processing is based on it. Under the GDPR/UK GDPR you may also lodge a complaint with your supervisory authority.

Overdesk makes no decision with legal or similarly significant effect about any individual by solely automated means. By default a person on your team reviews and sends every reply. If your workspace turns sending on, Overdesk sends only the replies your guardrail rules approve, and your team can turn sending off at any time.

Under the California CCPA/CPRA we act as a service provider for support content and as a business for account data. The categories of personal information we collect are identifiers (name, email, IP), internet/network activity (usage logs), and commercial information (billing). We use them only for the purposes above, retain them per Section 9, and do not sell or share personal information or use sensitive personal information for purposes that would trigger a right to limit. You have the right to correct your information, to be free from discrimination for exercising your rights, and to use an authorised agent. Several US state laws (e.g. Virginia, Colorado, Connecticut) also give a right to appeal a denied request; to appeal, reply to our decision email or write to privacy@overdesk.io.

For your end customers' personal data in support content, if one of your end customers contacts us directly we will refer them to you as the controller and assist you in responding, including deleting a specific customer's data on request.

To exercise any right, email privacy@overdesk.io. We respond within the time required by applicable law.

13. Children

Overdesk is a business tool and is not directed to children. We do not knowingly collect personal data from anyone under 18, and in any case never from children under 16.

14. Changes

We may update this policy. Material changes bump the version above and require you to accept again the next time you sign in. The date in the version is the effective date.

Contact: privacy@overdesk.io