Privacy Policy for DemoSched

1. Who we are

DemoSched is operated by Alexander Hungenberg, an individual residing in the Canton of Aargau, Switzerland. We are your organisation’s processor for most of what is described here, the controller of a little of it, and neither for the rest — the next section says which is which. Our full postal details are in the legal notice on the Terms page.

Write to us about anything on this page at contact@demosched.com.

2. Which hat we wear, and when

DemoSched is signed up for by an organisation, but it processes data about the individual people in it. That splits our responsibility, and the split decides who you should talk to about what. It matches clause 8.2 of the Terms.

Your organisation is the controller, and we are its processor

For everything inside your organisation: its membership and the settings its administrators make against you, the roster, the sessions and slots, and whether anyone is contacted at all. Your organisation decides who is enrolled, we act on the instructions its administrators give us, they can change or stop any of it, and we hold none of it for a purpose of our own.

Your sign-in account is Clerk’s, and nobody else’s

The account you sign in with belongs to Clerk, our sign-in provider, which holds it as its own controller under its own privacy policy. It is one account across every organisation you belong to, so no single organisation controls it and none can have it deleted. We store none of it: we read your name from Clerk when a page needs it, and your email address and picture never reach us at all. Section 6 sets out where it goes.

We are the controller

For our own relationship with your organisation as a customer — which plan it is on and what it is billed — and for the technical logs and traces we keep to run and secure the Service. We decide what is collected here and why.

Because your organisation is the controller of the first row, it is the one that has to tell its members they are in DemoSched and what happens to their data here. Section 8 says where to send a request about each row.

Signing up always creates an organisation, even where one person is acting for it alone. If you are its only member, you are also its administrator, and the decisions in the first row are yours to make.

3. What we handle, and why

1. Account and membership data. Your account lives with Clerk, our sign-in provider, and comes from your Google account if you sign in that way. Clerk holds your credentials; a password never reaches us. It also handles the account as its own controller, under its own privacy policy, to run and improve its service. We keep no copy of it. What we read from Clerk is your first and last name, your membership of an organisation and your role in it — not your email address and not your profile picture, neither of which reaches us — and we hold that only in a short-lived cache, described in section 7. Everything else we store names you by an identifier from Clerk and nothing more. Your organisation is the controller of its membership and we are its processor: it decides who is enrolled, the lawful basis is its own rather than ours, and we use what we read to tell members of an organisation apart and for no purpose of our own.
2. Slack workspace data. Where you connect DemoSched to Slack, we read the people in your workspace — display names, real names, Slack identifiers, time zone, and whether someone is active or on Do Not Disturb — along with the list of channels, so that the Service can reach the right people in the right place at a sensible time. We read the whole workspace rather than part of it, because that is what lets us match DemoSched users to the right Slack members. The result is cached so the Service stays quick, and the cache is dropped when you disconnect Slack or close the account. Our installed Slack app also holds permission to read workspace email addresses, which we use for one purpose only — matching a Slack account to its DemoSched account automatically. We hold all of this for your organisation as its processor, and for no purpose of our own.
3. Scheduling data. Who is on the roster — administrators decide that, and can exclude anyone from it — along with the sessions your organisation creates, their dates and titles, who has claimed which slot and what is being presented. From this the Service computes statistics about each person on the fly — not stored — so it can spread demos evenly and notice who has not presented for a while. Your organisation’s administrators can see these figures, including how often each member has presented. That is your organisation evaluating how its own rotation is going, and what it does with the figures is its decision, not ours. We hold all of this for it as its processor, and for no purpose of our own.

   Recording links are stored as links: DemoSched does not host, upload or store recordings, and what is behind a link is governed by whatever service you put it on.

4. Notification records. When the Service contacts someone, we record who was contacted, when, what happened to it — delivered, timed out, or skipped because someone was away or for another reason — and a link to the message. These records, with who last presented, are what the Service uses to pick who to ask next about an unclaimed slot: automatically, by private Slack message, and capped so that no one hears from it often. They also give your organisation’s administrators an audit trail of what the Service sent, and administrators can switch these notifications off or exclude anyone from them. We hold it for your organisation as part of that same processing, and for no purpose of our own.
5. Technical logs and traces. Our servers record request metadata, including IP addresses, along with diagnostic traces of what the Service did to answer a request — which steps ran, how long each took, and what failed. We use them to keep the Service running, to find faults and to resist abuse. That is our legitimate interest — a service that stays up and works — and we do not use them to build a picture of anyone. Our monitoring provider in section 5 receives a copy of the traces; the request logs stay on our own infrastructure.
6. Billing data. This is our own commercial relationship with your organisation as our customer, so here we are the controller, on our own account rather than on anyone’s instructions. Whoever signs the organisation up is our contact for that relationship. On a paid plan we are the seller: the invoice is issued in our own name, and Stripe processes the payment for us. What you give at checkout — the company name and billing address, the email address of whoever pays, and what was bought — stays with Stripe rather than being copied into DemoSched. We reach it there when we need it, and your invoice history is there for you too, on the billing page. We never receive your card details: you type them into fields Stripe controls, and not even the last four digits come back to us. Stripe also uses what it sees on its own account, to detect fraud and to meet the legal duties that bind it, and section 5 says more about that. What our own systems keep is narrower — which plan your organisation is on, how many seats it has bought, and the references that tie it to its Stripe customer and subscription — which we process to perform our contract with it. If a subscription goes unpaid, that record is what automatically returns the organisation to the free plan. That is an automated decision, and we take it because the contract requires it —nothing is deleted when it happens, and you can ask a person to look at it by writing to contact@demosched.com.

4. Cookies and tracking

DemoSched uses strictly necessary cookies and browser storage only — which is why you have not been asked to consent to anything. Two providers set them, and nobody else does.

Clerk, our sign-in provider, on every page: to keep you signed in, to keep the sign-in process secure, and — on public pages like this one — to tell the header whether you already have a session. Those last no longer than your session.

Stripe, our payment provider, on the checkout page and nowhere else. Paying means typing card details into fields Stripe controls, and Stripe checks the browser they are typed in to decide whether the payment is fraudulent — so it sets a cookie that tells one browser from another, looks at properties of your device and how you interact with the page, and may load a CAPTCHA. One of those cookies persists for up to a year. Stripe says these signals stay within a single purchase and are not linked across sessions or sites. We load Stripe’s script only where you are actually paying, so none of this reaches you anywhere else on the site.

Your browser can block or clear any of them at any time, though sign-in and checkout will stop working if you do. Beyond that:

• No analytics. This website and the application run no analytics, no tag manager and no session recording. Nothing measures your visit.
• No advertising, and no retargeting pixels.
• No profiling from your browsing. Nothing follows you across sites or builds a picture of you from your visits. Two things sit next to that rather than under it. The Service does calculate how often each person has presented, and administrators can see it — that is a feature of the product, described in section 3.3, not something we track here. And Stripe examines your device and behaviour on the checkout page, as described above, to decide whether a payment is fraudulent.
• We never sell personal data, and we never share it for anyone else’s marketing.

If that ever changes, this section changes first, and section 10.2 says how we will tell you.

5. Who else is involved

Running DemoSched means relying on other providers. Most handle personal data only on our instructions, bound by a contract to protect it — and where the data is your organisation’s, our instructions carry its own, which makes them its sub-processors. Where a provider instead uses data on its own account, or is not ours to instruct at all, the entry below says so. Each entry names the provider we rely on and what we rely on it for, not every individual product of theirs we use. The country at the end of an entry is where that provider is established — which is not the same as where your data is stored, and matters because a provider can reach data from there. Section 6 is the one that says where the data itself is. This list changes as the Service does: clause 8.4 of the Terms is how, and it gives your organisation, as the controller, at least three Swiss business days’ notice before the list changes, and a right to object before a new sub-processor starts processing its data.

Amazon Web Services

Our cloud infrastructure provider: hosting, storage and content delivery for the website and the application. United States.

Clerk

Sign-in and account management. Your sign-in account is Clerk’s own: its terms make it an independent controller of the account information it collects when you sign in — on its own account, not jointly with us or with your organisation — under its own privacy policy, and that part is not ours to instruct. Clerk also holds the membership settings your organisation’s administrators make, which we write as your organisation’s processor; for those it is a sub-processor acting on instructions that carry your organisation’s. United States.

Slack

Your organisation’s own workspace, which its administrators connect to DemoSched. Slack is your organisation’s provider rather than ours, under your organisation’s own contract with Slack — not our sub-processor, and not ours to instruct. It is a recipient of what we send on your organisation’s instruction, and we have no control over where the data in that workspace resides.

Cloudflare

Domain name services for demosched.com and its subdomains. United States.

Honeycomb

Monitoring. It receives the diagnostic traces in section 3.5, so we can see whether the Service is healthy and work out what went wrong when it is not. The company behind it, Hound Technology, Inc., is in the United States.

Stripe

Payment processing for paid plans, and the card fields on our checkout page. Stripe takes the payment on our instructions, as our processor — we are the seller, and the invoice is ours. It is also its own controller for part of what it does: detecting fraud, and meeting the anti-money-laundering and other legal duties that bind it. That part runs on its own responsibility under its own privacy policy and is not ours to instruct. Involved only if you are on a paid plan. We contract with Stripe Payments Europe, Limited in Ireland; the wider group, including the entity that holds its Data Privacy Framework certification, is in the United States.

We also disclose personal data where the law requires it, and to professional advisers under a duty of confidence. If DemoSched is transferred to a company or an acquirer under clause 11.4 of the Terms, data moves with it and this policy continues to apply until you are told otherwise.

6. Where your data is

Where it sits. This is the physical answer — where each kind of data rests. What travels, and under whose responsibility, comes after it.

Our database, caches, backups and server logs

The European Union, in the AWS Frankfurt region, and so does every request the application makes to us.

The diagnostic traces

Honeycomb’s European region, in the European Union too. Honeycomb is established in the United States and can reach them from there to run and support its service.

The website and application files

Served from a delivery network instead, so the request metadata in section 3.5 — your IP address among it — is handled globally at whichever of its locations is closest to you.

Your sign-in account

Clerk’s, and Clerk is in the United States. We hold no copy of it to place.

Your payment details

With Stripe. We contract with its Irish entity, inside the EEA, and Stripe processes payments on a global basis, including in the United States.

Your Slack workspace

Wherever your organisation’s own contract with Slack puts it, which is not ours to decide or to know. The calls we make into it go to Slack Technologies Limited in Ireland, inside the EEA.

The transfers we make. Some of the providers in section 5 are established outside Switzerland and the EEA — each entry there says where — so using them means either sending personal data there or letting them reach it where it rests. Four do: Honeycomb reaching the traces from the United States, the delivery network handling the request metadata outside the European Union, the payment we instruct Stripe to take, which its group processes globally, and what your organisation’s administrators record about you in Clerk — your membership of the organisation and the settings they make against you there. Your organisation is the controller of that last one and we write it into Clerk as its processor, so Clerk holds it as a sub-processor on our instructions.

Where a country is not covered by a Swiss or EU adequacy decision, those transfers are under the European Commission’s Standard Contractual Clauses with the Swiss addendum, or under an equivalent recognised safeguard such as the Data Privacy Framework — its EU–U.S. and Swiss–U.S. arms both — where the provider is certified. Clerk and Stripe both are, and for as long as that holds their certifications come first. Which set of Clauses applies follows the row of section 2 the data sits in: the controller-to-processor set for the logs, traces and billing record we hold as controller, and the processor-to-processor set for what we hold for your organisation, where the controller behind us is your organisation and the exporter is us.

The transfers we do not make. Not every transfer is ours. Where a provider uses data on its own account, or is not ours to instruct at all, it moves that data on its own responsibility and under its own mechanism rather than under ours.

Your Clerk account

Your name, email address, profile picture and sign-in credentials belong to the Clerk account that follows you across every organisation you are a member of. Clerk collects them when you sign in and holds them as its own controller — separately from us and from your organisation, not jointly — under its own privacy policy. We keep no copy of our own: we read your name as a page is drawn, and your email address, your picture and your credentials never reach us at all. So Clerk moving any of it to the United States is Clerk’s own transfer, under Clerk’s Data Privacy Framework certification — its EU–U.S., UK and Swiss–U.S. arms.

Stripe’s own purposes

Taking the payment is on our instructions and sits above. Detecting fraud and meeting the legal duties that bind Stripe are not: for those it acts as its own controller, so it moves that data under its own mechanism rather than ours — its Data Privacy Framework certification, which covers the EU–U.S., Swiss–U.S. and UK arms, with Standard Contractual Clauses behind it.

Your Slack workspace

It runs on your organisation’s own contract with Slack, not on ours. We read from it and send notifications into it on your organisation’s instruction, but where the data in that workspace travels afterwards is Slack’s own transfer under that contract, not one we make.

The same split applies to any other provider that uses data for its own purposes alongside what it does for us or for your organisation: that part travels under its mechanism, not ours. Write to us at contact@demosched.com for the detail on a particular provider, or for a copy of the safeguards.

7. How long we keep it

Your organisation’s data in DemoSched

The sessions and slots, and the records in the rows below: for as long as your organisation’s account is open, and no longer. Closing it deletes them, as does a written deletion request — promptly, and in any event within 30 days, apart from the backup copies below. That is an outside limit on us, not a recovery window: there is no read-only grace period and we do not restore closed accounts, so ask us for a copy of anything you want to keep before you close. Clauses 5.4 and 5.5 of the Terms say the same.

Your account itself

Your account is not in our database at all: we read your name from Clerk when a page needs it and hold it only in the cache below, and every other record we keep names you by an opaque identifier and nothing more. The account behind that identifier is one account across every organisation you belong to, so no single organisation can have it deleted, and leaving one organisation does not close it. Clerk holds it as its own controller, on the footing in section 6. If you ask us to delete it we pass the request on and ask Clerk to delete too — asking is all we can do, and what it keeps after that is governed by its own policy, not ours. To have the account itself deleted, deal with Clerk directly.

Your membership of an organisation

Gone the moment you leave it, whether you leave of your own accord or an administrator removes you. The settings its administrators made against you go with it. No one left in the organisation, administrators included, can see who you were: it is your membership that makes your name, email address and picture visible there, and your membership has ended.

What you put into your organisation’s workspace stays — the titles of the demos you gave among it — until your organisation’s account is closed. It is attributed to an unknown user rather than to you.

Cached data

Our caches expire no later than 24 hours after it is written.

Notification records

Who was contacted, when and what happened to it, in section 3.4: kept for as long as your organisation’s account is open, and deleted with it. They are what keeps the frequency caps honest and what gives administrators the audit trail, and neither survives their being dropped by age.

Technical logs and traces

14 days on our own infrastructure — both the application’s own logs and the request log that records your IP address — then deleted automatically. The traces we send to Honeycomb are deleted there when they fall out of its retention window, which is fixed by the plan we are on. The delivery network that serves the website files sees your IP address in order to answer the request, but it is configured to write no access logs, so nothing of it is kept there.

Billing records

The plan record goes when the account closes, along with everything else — the plan, the seat count, and the references tying the organisation to its Stripe customer and subscription. The invoices sit with Stripe rather than with us, so closing your DemoSched account does not reach them: Stripe keeps them on its own retention, and they remain available to us for as long as our own accounting obligations run. What Stripe holds on its own side for fraud detection and legal compliance, in section 3.6, is likewise not ours to keep or to delete: it holds that as its own controller, for as long as its own policy provides.

Backups

Copies in routine backups are purged on their normal cycle, within 90 days of deletion.

We keep what the law requires us to keep, and we preserve data that is the subject of a live dispute or legal hold until it is resolved.

8. Your rights

You can ask for a copy of your personal data, have it corrected, have it deleted, restrict or object to how it is used, receive it in a portable form, and withdraw any consent you have given. Under the FADP you always have the right of access and to have inaccurate data corrected; the rest apply where the GDPR does.

Where to send the request depends on the row in section 2.

• Membership, roster, sessions, slots, and being contacted. Your organisation is the controller, so ask its DemoSched administrator. It is also the one that owes you the explanation of why you are in DemoSched at all. If you ask us instead, we will pass the request on and tell you we have — we cannot act on that data without its instructions, and we will carry out the ones it gives us.
• Your sign-in account. That is Clerk’s, held on its own account rather than ours, and we store none of it — so those rights run under Clerk’s own policy and are its to answer. Ask us and we will pass the request on and tell you we have, but only Clerk can act on it.
• The records we hold as controller. The plan record, and the technical logs and traces in section 3.5. Write to contact@demosched.com and we will answer within 30 days. We may need to check who you are before we act. Deletion reaches all of it. The billing details behind an invoice sit with Stripe, as section 3.6 describes, and a request about those we pass on.

Exercising these rights is free. If you are not satisfied, you can complain to the Swiss Federal Data Protection and Information Commissioner (FDPIC) in Bern, or, if the GDPR applies to you, to the supervisory authority where you live or work. We would rather you came to us first — under clause 11.7 of the Terms we aim to give you a substantive answer within 14 days.

9. Security

We maintain technical and organisational measures appropriate to the nature and scale of the Service to protect personal data against unauthorised access, loss and alteration. No service can promise perfect security, and we do not.

If a breach happens, who reports it follows section 2. For the data we hold as controller — the technical logs and traces, and the billing records — the report is ours: we notify the competent authority where the breach is likely to result in a risk to your rights, and you where the law requires it. For your organisation’s data we are its processor, so the report is your organisation’s to make rather than ours. What we owe is to tell it without undue delay and give it what it needs to decide, which clause 8.8 of the Terms sets out.

10. Children, changes and conflicts

1. Children: DemoSched is a workplace tool. It is not directed at children and we do not knowingly collect data from anyone under 16. If you believe we have, tell us and we will delete it.
2. Changes to this policy: We will give at least 30 days’ notice by email before a material change takes effect. Corrections and clarifications take effect when posted, with the date at the top updated. A change to the list of providers in section 5 runs on its own notice instead, under clause 8.4 of the Terms. Changes never apply retroactively.
3. If documents conflict: A separate data processing agreement signed by both of us wins over both this policy and the Terms on the processing of personal data. Otherwise this policy wins over the Terms on how personal data is handled, and the Terms win on everything else. Clause 11.1 of the Terms says the same thing.
4. Language: This policy is written in English, and the English version governs.