We run a server. Here's exactly what's on it.

Effective August 24, 2026 · Last updated August 24, 2026

Meeting details read from connected calendars are never stored.

The times you offered, an optional meeting title you type into Say When, your recipient's name and time zone — their email too, if you gave one — and the addresses of people who asked for early access are stored. Live agenda details transit the server so the desktop can show your next meeting, but are returned no-store, kept only in process memory, and never persisted. Your free/busy is fetched, used to work out which times are open, and thrown away.

This Privacy Policy applies to the Say When desktop application; getsaywhen.com and any page that links to this Policy; Say When booking and standing-link pages; private tests, trials, subscriptions, support, and related communications; and your interactions with Say When as an account holder, booking recipient, website visitor, or waitlist member. It does not govern Google, Microsoft, Stripe, or another third-party service you choose to connect or use — those services process information under their own terms and privacy policies. Say When is operated by Teamsimple Inc., Ontario, Canada ("Teamsimple", "we", "us", or "our"). A Host is a person who creates or uses a Say When account or offer; a Recipient or Guest is a person who receives or uses a Say When booking link.

The sections that follow cover one kind of data each, and a test in this product's repository fails when the database gains a table or column those sections don't account for. The legal frame — purposes, disclosure, retention, your rights — follows them.

One product identity, across your devices.

We store the verified email address and display name your calendar provider returns, an opaque identity id, and when that identity was created. Connected calendar accounts belong to this identity, so reconnecting the same provider account on another device restores the same account set. Billing is keyed to this identity rather than to a device or calendar account.

Which account, and nothing inside it.

When you connect a Google or Microsoft account, we keep which provider it is, the email address on it, the name it reports, and when you connected it. That ordinary account row contains no password or token.

An encrypted grant, kept server-side.

For a connected Google or Microsoft account we store its long-lived refresh grant as an authenticated AES-256-GCM encrypted envelope. The encryption key is held separately in server configuration. Our server exchanges that grant for a short-lived access token when it needs to reach your calendars; access tokens are kept only in memory and refreshed automatically. Microsoft refresh-grant rotation replaces the encrypted envelope atomically. Disconnecting, or either provider reporting the grant revoked, deletes the envelope.

Opaque session and connection metadata.

The desktop keeps an encrypted Say When session. The server stores only its one-way digest, expiry and revocation state, links it to your Say When identity, and temporarily keeps hashed OAuth state and handoff values plus an encrypted PKCE verifier. Attempts expire and can be completed only once. When a verified email matches an existing identity, we also keep a one-shot choice record with provider identity metadata. Its authenticated encrypted refresh grant remains only while that one-shot choice is active. We remove that grant atomically when you successfully link or create a separate identity; otherwise it becomes eligible for removal at expiry by the maintenance sweep scheduled every ten minutes. The non-secret choice metadata remains as lifecycle history. Google and Microsoft authorization codes and access tokens are never returned to the app or written to application logs, audit events, or the database.

Which legal documents you accepted.

When you continue from a disclosed desktop calendar-connection screen, we keep an append-only acceptance history containing your opaque Say When identity, the Terms and Privacy Policy versions, the acceptance time and method, and the originating Google or Microsoft connection-attempt identifier. This lets us determine which published versions you accepted without storing provider tokens or calendar contents in the acceptance record.

Which calendars we look at, and when you work.

Your profile carries the name you give it, the calendar you picked to hold events — its identifier, its display name, and whether we can write to it — and the list of calendars consulted for availability, each recorded the same way.

Your working hours are stored as structured time-of-day windows, one set per weekday, and nothing else — the database itself rejects anything in that field beyond a time zone and those windows. We also store your before-and-after buffers, slots-per-day count, and minimum lead time so every offer follows the scheduling preferences on your profile. Your profile also stores the title and meeting-referencing note template you choose for private travel blocks, your default meeting-place choice, an optional in-person place, and the reusable meeting URL you choose to save.

To notice calendar changes without re-reading every hold, we keep the provider's opaque change cursor for that calendar and a current index containing only provider event ids and Say When's own offer and slot tags.

Your trial clock and its extensions.

When you first connect a calendar, we store the start and current expiry of your trial, the trial length promised at that time, and whether the one-time unused-trial extension was applied. We also keep the current duration policy for future trials. Manual extensions are an append-only audit record containing the operator name, time, number of days, and the deadline before and after the extension.

Subscription state, without card details.

We store the opaque Stripe Customer, subscription, Price, and webhook-event identifiers tied to your Say When identity, plus your plan, subscription status, billing-period end, cancellation-at-period-end choice, and the times those records were created or projected. These records let the server apply subscription access and safely ignore duplicate events.

Stripe receives your name, email, billing address, payment information, buyer-location tax information, and the invoice and receipt data needed to run Checkout and the billing portal. Say When never stores card numbers or card security codes.

Booking speed, without booking identity.

After a successful recipient booking, we store when one anonymous performance record was collected and its ordered phase names and non-negative durations. The record has no offer, link, slot, recipient, calendar, request, provider event, path, or error identity, so it is not directly keyed to a person or booking. Its collection time can still let an operator associate it with a booking when only one occurred in that window. Unavailable and failed attempts store no performance record. These records are routine operational records under the retention table below.

Every offer, and everything that happened to it.

For each offer: the times you offered and how long each runs, whether booking is live or plain, the unguessable link addresses, when you created it, and where it stands now — open, booked, expired, or withdrawn, or simply plain for the offers that never track booking.

A live booking address also uses your profile's public handle. We store the current handle and retain former handles as an append-only ownership history so links using an old handle can redirect safely and cannot be claimed by another profile.

A standing link definition stores its profile, public name, meeting duration, whether it is enabled, its meeting-place choice and optional in-person place, and any optional description you choose to publish. An enabled standing page publicly reveals availability derived from free/busy data; the underlying free/busy intervals are used only transiently and are not stored. The description appears with that availability when present.

Behind that sits a log of what happened to the offer — created, viewed, clicked, booked, cancelled, expired, withdrawn — each entry with a timestamp. The log is append-only: the database refuses to update or delete its rows. It contains opaque identifiers, scheduling rules, intervals, timestamps, and provider facts, but not recipient names or emails, sender-authored titles, descriptions, meeting URLs, or physical places. Those offer-specific details live in deletable related records, so they can be irreversibly disconnected while the identity-free lifecycle history remains intact.

Each new booking also stores a one-way digest of its unguessable cancellation code, the exact provider event it can remove, when the code was created, and when it was consumed. The original code is a bearer link shown to the booked recipient, but it is not stored or included in desktop audit data.

If the sender enables more times, the creation entry also retains that offer's fixed date window and either the legacy time-of-day choice or the snapshotted host-local custom start–end range. One-off creation entries retain the same fixed criteria. A booking from those additional live times records the exact chosen interval on the original offer.

If the sender enables travel blocking, the creation entry stores only the before-and-after minute durations. The private travel-event title and note remain profile settings.

While someone confirms an unheld time, we briefly keep an opaque attempt identifier, the host profile identifier, the selected interval, and a lease expiry. It contains no visitor name or email and is deleted when the attempt finishes; an interrupted attempt expires automatically.

If someone sent you times, read this bit.

You never sign up, so this is your place to read what Say When holds about you: your time zone, plus your name and email when they are supplied. The sender always chooses the time zone and may enter your name and email before creating the offer; if they do not, the booking page asks you for your name and email before it books.

They are used for one purpose: addressing the booking page to you and confirming the time you pick. If your name and email were supplied, booking is one click; otherwise the booking page asks you for them first. Say When uses those details to create the calendar event, but sends no mail.

One email address, and nothing else.

If you asked for early access: the address you typed, which form it came from, and when. The table it lands in is unreachable from a browser — row-level security is on with no policy granting anyone access, so only our server writes, with its own key. Addresses are compared case-insensitively, so signing up twice adds nothing.

Connected-calendar details are never stored.

To show the live menu-bar agenda, event titles, times, and the minimum conference-link data needed to recognise Google Meet, Microsoft Teams, or Zoom transit our server. A conference candidate can come from the provider's conference fields, location, or description. The reduced result is returned with no-store, lives only in the desktop process's memory, and disappears when the process exits.

Titles read from connected calendars, descriptions, attendees, agenda times, and agenda links are never written to the database, desktop preferences, audit events, or application logs. An optional meeting title you type into Say When is different: it is sender-authored, guest-visible offer content, so we store it with that offer and use it on the booking page, invite, and dashboard. Postgres whitelists every structured field, and repository tests fail if undeclared calendar content becomes persistent. The opaque change cursor, provider event ids, and Say When's own offer and slot tags remain the only calendar-sync state persisted. Free/busy intervals are also fetched, used, and discarded.

For connected Google or Microsoft accounts, the server also calls the provider's calendar APIs to work out which times are open and to place holds and create the Google Meet or Microsoft Teams meeting you book. Those older availability and booking paths remain reduced to the identifiers, times, tags, deletion state, and meeting link each operation needs.

Unless we clearly tell you otherwise before collection:

• we do not request access to Gmail or Microsoft Outlook mail;
• we do not store passwords for connected Google or Microsoft accounts;
• we do not persist titles, descriptions, attendees, agenda times, or links read from connected calendars;
• we do not persist free/busy intervals;
• we do not sell personal information;
• we do not share personal information for cross-context behavioural advertising;
• we do not use connected-calendar information, booking data, or Recipient details to train generative AI models; and
• the availability, hold, and booking path does not make a generative-model call.

Please do not enter sensitive personal information, confidential client information, health information, government identifiers, financial account details, or other information that is unnecessary for scheduling into an offer title, description, meeting place, or other free-text field.

Calendar permissions only.

Say When asks for no mail access of any kind, on either provider. That isn't a policy we could quietly change; it's a permission we never requested.

Say When's use and transfer of information received from Google APIs complies with the Google API Services User Data Policy, including its Limited Use requirements. Google user data is accessed, used, stored, and disclosed only to provide and improve user-facing Say When features that are prominent in the Service; for security; to comply with law; or as otherwise permitted by Google's policies and authorized by the user. We do not use Google user data for advertising, sell it, or allow humans to read it except with the user's affirmative agreement for support, where necessary for security or abuse investigation, to comply with law, or where the data has been aggregated and anonymized for internal operations.

The same product restrictions apply to information received through Microsoft APIs. You can revoke Say When's access through Say When Settings or through the connected provider's security settings.

What a form submission left behind.

The early-access form has been retired from the site; addresses collected while it ran remain stored as described above. While it ran, the server read the forwarded client address and used it as a key in an in-memory counter — at most five submissions a minute. The counter lived in the server process, was discarded past 5,000 entries and on every restart, and the address was never written to the database. Operational errors do reach our hosting platform's server logs, kept under the routine-logs line of the retention table below.

What is not built yet.

Dedicated hold storage. The hold lifecycle is built: for each offered slot, a hold being placed, its start time passing without a booking, or the hold being withdrawn is stored as a row in the append-only offer event log. There is no separate holds table or hold-specific column.

What this Policy covers

This Privacy Policy applies to:

• the Say When desktop application;
• getsaywhen.com and any page that links to this Policy;
• Say When booking and standing-link pages;
• private tests, trials, subscriptions, support, and related communications; and
• interactions with Say When as an account holder, booking recipient, website visitor, or waitlist member.

It does not govern Google, Microsoft, Stripe, or another third-party service you choose to connect or use. Those services process information under their own terms and privacy policies.

In this Policy:

• an Account Holder or Host is a person who creates or uses a Say When account or offer;
• a Recipient or Guest is a person who receives or uses a Say When booking link; and
• the Service means the Say When app, website, booking pages, and related services.

Why we use personal information

We use personal information only for identified purposes, including to:

1. create, authenticate, secure, and administer accounts;
2. connect to calendar providers at the Account Holder's direction;
3. calculate availability and apply working hours, time zones, buffers, lead times, and other preferences;
4. create, maintain, and remove private holds;
5. create booking pages, standing pages, calendar events, meeting links, travel blocks, and cancellation flows;
6. show Hosts their offers, bookings, trial status, subscription status, and limited agenda information;
7. process subscriptions, payments, taxes, refunds, and account access;
8. deliver private-test access, service notices, support, and requested communications;
9. detect abuse, protect accounts and links, prevent fraud, rate-limit requests, debug errors, and maintain reliability;
10. understand feature performance using limited, proportionate operational data;
11. enforce our Terms of Service and protect our users, rights, and property;
12. comply with law, court orders, lawful requests, tax, accounting, security, and recordkeeping obligations; and
13. complete a financing, merger, acquisition, reorganization, or sale, subject to appropriate confidentiality and privacy protections.

We will obtain additional consent before using personal information for a materially new purpose unless the law permits or requires the use without consent.

Consent and other legal grounds

Under Canadian privacy law, we collect, use, and disclose personal information with meaningful consent, except where the law allows or requires otherwise. Some processing is necessary to provide a feature you request. For example, we cannot calculate your availability without transiently checking the calendars you select, and we cannot create a booking without using the Host and Recipient details needed for the calendar event.

You may withdraw consent to optional processing at any time, subject to legal or contractual restrictions and reasonable notice. Disconnecting a calendar stops Say When's future access to that calendar account. Withdrawing consent may mean a feature or the Service can no longer operate for you.

Where the European Economic Area, United Kingdom, or similar law applies, our legal grounds may include:

• performance of a contract or steps requested before entering one;
• our legitimate interests in operating, securing, supporting, and improving the Service, where those interests are not overridden by your rights;
• your consent; and
• compliance with legal obligations.

When we disclose information

We disclose personal information only as needed for the purposes above.

Between Hosts and Recipients

A booking page displays the Host information and offer details needed to book. When a Recipient books, the Host receives the Recipient's name, email, selected time, and other information intentionally supplied for the booking. The created calendar event may be visible to people who have access to the Host's or Recipient's calendar under their provider settings.

Booking pages and cancellation links are bearer links. Anyone who obtains the link may be able to open the page or exercise the action available through it. Hosts and Recipients should share and protect those links accordingly.

Connected services

At your direction, we disclose or receive limited information through:

• Google, for identity, Google Calendar, and Google Meet functionality;
• Microsoft, for identity, Outlook calendar, Microsoft Graph, and Microsoft Teams functionality; and
• Stripe, for checkout, subscription administration, invoicing, tax, and payment processing.

Your use of those services remains subject to their terms and privacy policies.

Service providers and subprocessors

We use carefully selected providers for functions such as cloud hosting, databases, infrastructure, security, error logging, customer support, and payment processing. They may process personal information only under our instructions, for the contracted service, and subject to confidentiality, security, and data-protection obligations.

A current list of material subprocessors and their processing locations is available by contacting privacy@getsaywhen.com.

Legal, safety, and rights

We may disclose information where we reasonably believe it is necessary to comply with law or valid legal process; investigate fraud, abuse, or security incidents; protect a person from harm; enforce our agreements; or establish, exercise, or defend legal claims. Where lawful and practical, we will notify the affected person before disclosure.

Business transactions

We may disclose information to professional advisers and transaction participants in connection with a proposed financing, merger, acquisition, reorganization, sale of assets, or similar transaction. Any recipient must protect the information and use it only for evaluating or completing the transaction. If control of personal information changes, we will provide notice where required.

With your direction or consent

We may disclose information where you direct us to do so or give meaningful consent.

Retention and deletion

We retain personal information only as long as reasonably necessary for the purpose for which it was collected, to provide the Service, resolve disputes, enforce agreements, maintain security, and meet legal obligations. We then delete, anonymize, or securely isolate it.

Our standard retention periods are:

Deleting an account does not automatically remove events already created in Google Calendar or Microsoft Outlook, messages the Host sent through another service, or information retained by a Recipient or third-party provider. You must manage those copies with the relevant person or provider.

Some offer history is maintained in an append-only audit design to prevent silent alteration of booking history. When a valid deletion request applies, personal identifiers in that history will be deleted, irreversibly de-identified, or disconnected from the audit record so the remaining event cannot reasonably identify a person, unless law requires us to preserve it.

Security and breach response

We use administrative, technical, and physical safeguards appropriate to the sensitivity of the information, including encryption in transit, authenticated encryption for stored calendar refresh grants, separation of encryption keys from encrypted data, least-privilege access, one-way session digests, expiring connection attempts, restricted production access, and monitoring for operational and security events.

Our database and repository include controls intended to prevent undeclared connected-calendar content from becoming persistent. Security is a process, not a guarantee, and no internet service can promise absolute security.

If a breach of security safeguards creates a real risk of significant harm, we will notify affected individuals and report to the appropriate regulator as required by law. We maintain records of security breaches for the legally required period.

Please report suspected security issues to security@getsaywhen.com. Do not include live credentials, access tokens, or sensitive personal information in an initial report.

International processing

Teamsimple Inc. is based in Ontario, Canada. Our service providers and connected providers may process information in Canada, the United States, and other countries. Information processed outside your province or country may be subject to the laws and lawful access rules of that jurisdiction.

We remain accountable for personal information transferred to a service provider for processing. We use contractual, organizational, and technical safeguards appropriate to the information and the destination, including data-protection terms and access controls. Where required, we use approved transfer mechanisms for personal information originating in the EEA, UK, or Switzerland.

Your rights and choices

Subject to applicable law, you may ask us to:

• confirm whether we hold personal information about you;
• explain how it has been used and disclosed;
• provide access to it in an understandable form;
• correct inaccurate or incomplete information;
• delete information that is no longer required;
• withdraw consent to optional processing;
• object to or restrict certain processing;
• provide portable information where the law requires it; or
• explain a decision about your request.

You can disconnect a calendar in Settings. You can also contact privacy@getsaywhen.com to make a privacy request. Please describe what you are requesting and the email address involved. We may ask for information reasonably necessary to verify your identity and authority. We will not ask for your Google or Microsoft password.

We respond within the period required by applicable law. For requests governed by Canada's Personal Information Protection and Electronic Documents Act, that is generally within 30 calendar days, subject to permitted extensions. We may refuse or limit a request where the law requires or permits, such as where disclosure would reveal another person's information, compromise security, or conflict with a legal obligation. We will explain the reason where required.

We do not discriminate against people for exercising applicable privacy rights.

If an organization provided your access

If you use Say When through an employer or another organization, that organization may control the account and determine the purposes for which some personal information is processed. It may be able to access, export, correct, restrict, or delete information associated with the managed account. Direct organization-controlled data requests to the organization first. We will assist it as required by our agreement and applicable law.

If a Host provided your information

A Host may have provided your name, email, or time zone to create an offer. You can contact us directly, but the Host may also be responsible for responding to your request. We may notify or involve the Host where needed to verify and complete it.

Communications and choices

We may send Account Holders service messages needed to administer an account, security, trial, subscription, or requested support. These are not promotional messages.

If you joined the early-access waitlist while it was open, we use your email to communicate about access. If we ask to send broader product news or marketing, we will obtain consent where required and include a working unsubscribe method. You can also withdraw marketing consent by contacting privacy@getsaywhen.com. Withdrawing marketing consent does not stop necessary service communications.

Children

Say When is a business scheduling tool and is not directed to children under 16. We do not knowingly allow a person under the age of majority in their jurisdiction to create an Account Holder account. A Host should not enter information about a child into Say When unless the Host has lawful authority and the information is reasonably necessary for the booking.

If you believe we collected personal information from a child contrary to this section, contact privacy@getsaywhen.com so we can investigate and delete it where appropriate.

Changes to this Policy

We may update this Policy as Say When changes or as legal requirements evolve. We will post the updated version here and change the date above. If a change materially affects how we use personal information already collected, we will provide additional notice and obtain consent where required before the change applies.

Ask us what we hold.

Questions, privacy requests, or complaints go to our Privacy Officer: privacy@getsaywhen.com. Say When is operated by Teamsimple Inc., Ontario, Canada. We will investigate privacy complaints and explain the outcome. If you are not satisfied, you may contact the Office of the Privacy Commissioner of Canada or the privacy regulator in your jurisdiction.