Privacy notice

Quorum measures what meetings cost and recommends which of them need fewer people live. It reads calendar metadata and attendance records for the employees of the workspace that installed it. This page states exactly what is collected, what is never collected, who it is shared with, and how long it is kept.

Who is responsible for your data

Quorum is a product of CREATIVE CODERS SPÓŁKA Z OGRANICZONĄ ODPOWIEDZIALNOŚCIĄ (Creative Coders sp. z o.o.), ul. Płk. Zoltána Baló 6 lok. 5, 02-793 Warszawa, Poland, entered in the National Court Register under KRS 0001271368, NIP 9512657914 (“we”). The full registered details are on the Company information page. Our role depends on whose data it is:

• We are the controller for the personal data of visitors to this website (including the public analytics described below), of people who send us a contact or sales enquiry, for account holders’ sign-in data (work email, password hash, sign-in links and sessions), for participants in the Quorum referral and partner programmes, and for newsletter subscribers.
• We are a processor for workspace data: the calendar, attendance, directory, conversation-volume and other data listed under “What Quorum reads”. We process it on behalf of the organization that created the workspace, which is the controller: it decides which sources to connect and why, and it answers its employees’ requests about that data.

What Quorum reads

Public website analytics

When enabled, the landing page measures page loads, time with the page visible and focused, scroll milestones, sections viewed, call-to-action clicks and whether the cost calculator was used. It also records the selected page language, a broad screen-size category, the referring website’s hostname and permitted campaign tags. Calculator values, form contents, full referring URLs and IP addresses are not stored in these analytics records.

The tracker uses a random identifier held in memory for one page load. It does not use analytics cookies, persistent browser storage or fingerprinting, and does not identify unique people or link visits to workspace accounts. Signed-in browsing and browsers sending Do Not Track or Global Privacy Control are excluded. You can also disable collection for a visit by adding ?analytics=off to the landing-page address. Analytics are not collected on dashboard, sign-in or other product pages. Only explicitly authorized Quorum operators can view aggregate reports. Records older than 90 days are removed by the daily retention sweep. Temporary hashed abuse-prevention counters expire separately; ordinary hosting request logs are separate from analytics.

Cookies and browser storage

Quorum sets only cookies that are strictly necessary for something you asked for: keeping a language you chose, signing you in and keeping you signed in. None is used for analytics or advertising, none is set by another company, and so the site asks for no cookie consent (Art. 399 of the Polish Electronic Communications Law, implementing Art. 5(3) of the ePrivacy Directive). A visit to the public pages sets no cookie unless you choose a language, and the public pages write nothing to your browser’s storage. The Cookies page explains this in full; the list is the same.

Once you are signed in, the dashboard keeps these conveniences in your browser’s local storage. They stay in your browser and are not sent to Quorum.

Optional calendar extension and add-on

When a person chooses to use a Quorum calendar surface, it reads only the identifier and title of the event they open. It sends those values and a Google ID token to Quorum so the service can verify the person’s work email and return their own view of that meeting. The surface does not scan the rest of the calendar and does not write to it. The Chrome extension keeps the token in session storage until the browser closes. Quorum does not create a separate extension session or durably store the token; a hash of the token, the verified email and its expiry may remain in application memory until the token expires. If the verified person is not an invited participant, no meeting details are returned.

Your own figures (My week)

Each person can see their own calendar figures for last week and the three before it: meeting hours (private meetings counted as time only, never their title or people), the share of the working week, days with a two-hour focus stretch, back-to-back stretches, invitations they did not join where attendance was recorded for everyone, counts of their written threads, and the recurring meetings they organize. Only that person can open it — not their manager, not an administrator, not the workspace assistant — and it appears in no report, export, audit entry or log. It is calculated when opened and not stored. It shows no score and names no colleague; the only comparison is with the person’s own team total, and only when the rest of the team is at least three people. People can ask for it as a private weekly message in Slack, Microsoft Teams or Google Chat, or hide it. Administrators decide whether employees without dashboard access may sign in to it.

What Quorum never does

• It never evaluates an individual. Audits and recommendations operate at organization, team, and meeting-series level. Authorized admins and team managers can also view named calendar commitments and factual participation for workload planning. Meet-derived attendance is excluded from these person views. There is no per-person score, ranking, or productivity metric, and no feature may add one. Google’s Meet API terms prohibit using that data for performance tracking, and Quorum enforces the same rule product-wide for every provider.
• It never joins your calls. Attendance comes from the platform’s own join/leave records. No recording bot appears in the participant list.
• It excludes sensitive meetings at ingestion, not in the UI. A meeting whose title or description matches 1:1s, performance reviews, compensation, promotion, termination, disciplinary matters, PIPs, HR cases, medical, legal privilege, grievances, or interviews is reduced to a time-and-duration shell before it is stored. It never gains participants, attendance, cost, AI output, or artifacts. Only its time counts: each person whose calendar holds it has that time included in their team’s meeting hours and focus figures, for teams of at least three people, and never shown per person or per meeting.
• It never sends sensitive-meeting content to a model. Excluded meetings have no content to send.
• It never retains or analyzes message bodies, documents, or email content. The standard Slack install is limited to delivery, account matching and the slash command. Public-channel thread tracking is a separate administrator opt-in. Slack includes text in those signed event envelopes; Quorum ignores that field at the request boundary and stores only the event id, count, timestamp, mapped participant set and the public channel's name. On GitHub it requests only metadata and counters; no comment body is fetched or stored. Teams channel messages and Jira, Linear and GitLab webhooks carry text, which is discarded on arrival; only ids, times, state, the container's title or channel name and mapped participants are kept.
• It never counts messages per person. A thread is expensive because of its size and duration, not because of who posted most. There is no per-person message figure anywhere in the product, and the data model has nowhere to put one.

Automated decisions

Quorum produces recommendations; a human makes every decision. An AI recommendation and an organizer’s decision are stored as separate records and are never merged. Nothing in an employee’s calendar changes unless the meeting organizer acts on it themselves. Cost, health scores, and savings are deterministic code — no model is involved in any number.

Retention

Retention is enforced by a daily job, not promised in a document. Your workspace sets the windows in Settings; the defaults are:

• Meetings, attendance and conversation volume — 365 days by default (configurable 30–3650). Anything older than the window is deleted, along with its participants, attendance, recommendations, and decisions. Teams, Jira, Linear and GitLab conversations follow it too; cached Teams channel names go once nothing has been heard from the channel within the window, and an unanswered thread author's digest after 30 days.
• Transcripts — 30 days by default (configurable 7–365), deliberately the shortest window because it is the most sensitive artifact.
• My week settings (whether a person hid the page or asked for the weekly message) are kept until they change them and deleted when the person is erased or the workspace is deleted. The figures themselves are never stored.
• Deactivated people — erased after the workspace’s window (the meeting window unless an administrator sets a separate one, 30–3650 days). The daily job erases them exactly as an administrator’s erasure does (see Access, export and deletion).
• Workspace exports are held encrypted for 7 days so an administrator can download them, then deleted.
• Newsletter requests that are not confirmed are deleted after 7 days, and an unsubscribed address 30 days after it left (see Newsletter).
• Sign-in links expire after 15 minutes, are single-use, are stored only as a SHA-256 hash, and are purged a day after expiry.

Reducing a retention window takes effect on the next daily sweep, and the Settings page shows the configured window. Ask an administrator to review exports before reducing it.

Enquiries and change tracking

Sales enquiries contain the contact details and message you submit. They are used to handle the request, stored in an operator queue, and forwarded to the configured sales inbox when delivery is available. Database copies are deleted by the daily sweep after 90 days; forwarded email copies require the operator’s mailbox retention policy.

Series change plans store the owner, target date, implementation date and administrative confirmation note. Plans and their decision audit records follow the workspace meeting-retention window. Do not include private meeting content or employee assessments in these notes.

Referral programme

When you introduce a company through the referral programme, we store your name, email address, relationship to and role at that company, the company’s name and website, any buyer contact and message you give, your reward choice (and charity), and when you confirmed each safeguard and the programme terms. We use them to contact the company, to tell its buyer the introduction came through the programme, and to pay or donate any reward; bank details are requested by email only once a reward is due. Root Quorum operators alone can see these records, with a log of every change. Open referrals expire after 12 months; declined and expired referrals are deleted 12 months after they close, and paid or donated ones 6 years after payment, as accounting records.

A referral link (an address ending in ?ref= and a code) fills in the optional “Referral code” field of the contact, partner or signup form it leads to, where you can change or clear it. If you send the form with a code that belongs to a referral, we store the code with your enquiry or new workspace so it is attributed to that referral. Nothing about a referral is stored in your browser: no cookie, local storage or session storage is used, and a visit through a referral link is not recorded.

Newsletter

If you ask for the Quorum newsletter in the form at the foot of a page, we store your email address, the language of the page, which page it was, the wording and version of the consent you ticked, and when you asked and confirmed. We do not store your network address or browser. We send you one email with a confirmation link, and you are subscribed only when you press the button on the page it opens; until then you receive nothing else. The link works once and expires after 7 days, and a request that is not confirmed by then is deleted. Short-lived counters under a keyed one-way hash of your address and of your network limit how often the form can be used, and expire within a day.

• Purpose and basis. To send you the newsletter — news about Quorum and articles on the cost of meetings and written work — on the basis of your consent (GDPR Art. 6(1)(a)), which the Polish Electronic Communications Law requires for commercial email (Art. 398). Keeping a record of that consent is how we show it was given (Art. 7(1)).
• Who sends it. The confirmation email and every issue are sent through Resend, the email provider listed on the Security & sub-processors page. Only root Quorum operators can see or export the list, and it is not shared with anyone else or used for anything else.
• Withdrawing consent. Every email has an unsubscribe link, and mail programs that offer their own unsubscribe button can use it too. Unsubscribing takes effect at once and does not affect emails sent before. You can also ask through the contact form.
• How long. While you are subscribed. After you unsubscribe we keep your address and the date for 30 days, so we can remove it from the copy used to send issues, and then delete it; nothing is kept afterwards.

Access, export and deletion

• Your own data. Anyone who can open their My week can download everything Quorum stores about them in their workspace as a file, including what only they can see (their private time, My week settings and pulse answers). Nobody else is told.
• A person’s data, for an administrator. Administrators can download what Quorum holds about one person, to answer that person’s request. It holds what administrators can already see; the private time, My week settings, pulse answers, assistant use and Google Meet attendance that Quorum shows to the person alone are left out, and the file says so. The download is recorded in the audit trail.
• Erasing a person. An administrator can erase someone who has been deactivated; the daily job does the same once a deactivated person’s window has passed. Their directory entry, calendar copies, private time, pulse answers, assistant use, chat and account links, settings, sign-in links and authenticator are deleted. Past meetings keep an anonymous participant in their place — a stand-in address made for that meeting alone — so meeting sizes and costs already calculated do not change and nothing links the stand-ins of different meetings; anything the person wrote or was sent (a catch-up brief, a meeting-reset answer, a transcript) is deleted, and the model’s reasons about them are emptied. Audit entries about them are emptied in place; entries they made as an administrator keep the action under an identifier that no longer names anyone. If a connected directory or calendar still lists the person, Quorum will see them again, so remove them there first.
• Exporting a workspace. Administrators can export the whole workspace from Settings: every table Quorum stores as JSON, with people, meetings, series and costs as CSV, and a list of what was left out and why. Credentials and password hashes are never included. The archive is prepared in the background, encrypted while it waits, and deleted after 7 days; downloading it needs both the emailed link and a signed-in administrator of the workspace.
• Deleting a workspace. An administrator can schedule the deletion of the whole workspace by typing its domain; for a contract that ends, Quorum can schedule it too. Every administrator is emailed, and any of them can cancel during the 14-day cooling-off period. Then every person, meeting, conversation, analysis, setting and stored credential is deleted; Quorum revokes its own Slack and HRIS access where their APIs allow and lists the access the customer granted that it must remove on its side. Every administrator receives a deletion certificate. What remains is a record that the deletion happened — a one-way hash of the workspace identifier, the dates, who asked (administrator or Quorum) and the number of records — and the workspace’s audit trail until its own retention window ends.
• Backups. The database is hosted in the EU (Frankfurt) with point-in-time recovery for 3 days, so deleted data leaves the backups within that period; a database export Quorum’s operator takes is kept for the hosting provider’s export retention (at least 7 days) and then expires. Backups are used only to recover the whole service.

Security records

Administrative changes and security events — sign-ins and failed sign-ins, sign-outs, authenticator and recovery-code changes, exports, erasures and deletions — are kept in an append-only audit trail that each workspace’s administrators can read in Settings. An entry records who acted, what they did and when; for security events also the network address and a broad browser class (never the full browser string). Network addresses are kept for 90 days, for security purposes only, and then cleared; the audit trail itself is kept for 400 days, including after a workspace is deleted, and then deleted. A failed sign-in for an address that belongs to no account is recorded with a keyed one-way digest of the address, never the address itself. When a person is erased, entries about them are emptied in place.

Your rights and data-protection requests

Where we are the controller, you can ask us for access to your personal data, its rectification or erasure, the restriction of its processing or its portability, and you can object to its processing, as the GDPR provides. Send the request through the contact form, saying that it is a data-protection request, or by post to Creative Coders sp. z o.o., ul. Płk. Zoltána Baló 6 lok. 5, 02-793 Warszawa, Poland.

For workspace data, the organization that uses Quorum — usually your employer — is the controller, so send the request to it. You can also download your own data at any time from My week, and your administrator can export or erase it as described under Access, export and deletion.

You can lodge a complaint with the Polish supervisory authority, the President of the Personal Data Protection Office (Prezes Urzędu Ochrony Danych Osobowych, PUODO), ul. Stawki 2, 00-193 Warszawa, Poland, or with the supervisory authority of the country where you live or work.

Where data goes

Quorum is hosted on Render in its Frankfurt, Germany region, in the EU: the application, its background processing and its database. The full list of third parties that receive any data, what each one receives, where it processes it and on what basis any transfer outside the EU/EEA rests, is on the Security & sub-processors page.