Privacy Policy

Skeldy SAS (Skeldy SAS, 12 rue de la Paix, 75002 Paris, France) is the data controller for personal data processed through the Skeldy product. Registered in France, RCS Paris (registration number to be confirmed at incorporation).

For privacy questions, contact [email protected]. For Data Protection Officer enquiries, contact [email protected].

The list below describes what actually exists in our database. It is deliberately detailed, including where that detail does us no favours.

• Account data : name, email, role, preferred language, organisation membership.
• Schedule data : shifts, hours, sections, assignments, qualifications, declared availability, slot preferences.
• Time-off requests : the days requested and a free-text reason you write yourself. This field is readable by the managers in your organisation. Do not enter any health information in it.
• Shift swap requests : requester, recipient, status.
• Shift notes : free text attached to a shift. Where an imported schedule names a person we cannot match to an account, that person's name is written into this note.
• AI assistant conversations : your messages and the model's replies. Each conversation now carries its author's name and is readable by that person alone : neither your colleagues nor your management have access. Conversations written before 14 August 2026 have no recorded author and are no longer readable by anyone.
• Imported schedule documents : the photo or PDF you upload, kept encoded inside our database, together with the names and sections extracted from it.
• Invitations : email address, role, and the person who issued the invitation, including where it is never accepted.
• Waitlist : email, name, job title, venue name, language, and marketing consent, if you sign up from the public site.
• Billing data : payment is processed by Stripe and we never see your card number. We do, however, retain the complete Stripe event, which depending on the case contains your name, your email, your billing address, and your VAT number.
• Audit logs : author, timestamp, and a full copy of the row before and after every privileged mutation.
• Product analytics : pageviews and usage events. Section 3 distinguishes browser tracking, which is subject to consent, from server-side tracking, which is not.
• Technical data : IP address, user agent, and platform logs. Our server function logs currently contain your email address on every call to the AI assistant, and staff names on the import path.

Each processing activity has a defined purpose and a GDPR Article 6 legal basis:

Provide the service

Performance of the contract (Art. 6(1)(b)). Includes account creation, scheduling, and AI-assisted reconfiguration.

Billing and tax

Legal obligation (Art. 6(1)(c)) and contract performance.

Artificial-intelligence assistance

Performance of the contract (Art. 6(1)(b)). This processing involves transmitting named schedule data to third-party model providers, one of which is established outside the European Economic Area. The detail is set out in section 5.

Security, monitoring, and abuse prevention

Legitimate interest (Art. 6(1)(f)). Includes audit logs on privileged mutations, rate limiting, fraud detection, and application error monitoring : error reports and a fraction of performance traces, with no session replay whatsoever. See section 12.

Product analytics in the browser

Consent (Art. 6(1)(a)). Tracking stays off until you accept. Global Privacy Control and Do Not Track signals are honoured. You can withdraw consent at any time via the cookie banner or /cookies.

Server-side usage measurement

Legitimate interest (Art. 6(1)(f)). When you are signed in, certain product events : sign-up, completion of onboarding, publication of a schedule, completed import, acceptance of an AI proposal, subscription events : are sent from our servers to PostHog EU, identified by a technical identifier corresponding to your account or your organisation. This flow does not go through the cookie banner and is therefore not covered by your choice. We write it here rather than let you believe otherwise. You can object to it by writing to [email protected].

Customer support

Performance of the contract and legitimate interest. The support chat widget is only loaded if you open it.

The production database resides with Supabase, in eu-central-1 (Frankfurt). The application is hosted by Vercel in EU regions. One flow, and one flow only, leaves the European Economic Area carrying named schedule data: artificial-intelligence processing. Section 5 is devoted to it.

Two further flows leave the EEA without carrying named schedule data, and we name them rather than leave them behind the phrase "one flow only". Payment goes to Stripe. And the whole of the web traffic passes through Cloudflare, a company established in the United States, which provides DNS and the delivery network in front of skeldy.com and routes inbound email: every request to the site crosses its network before reaching our servers, which gives it access in transit to your IP address, your user agent, and the URLs requested.

The list below replaces an earlier list that was inaccurate. It names the sub-processors actually used as at the effective date of this policy.

• Supabase : database, authentication, and realtime. eu-central-1 (Frankfurt).
• Vercel : hosting of the web application. EU regions.
• Cloudflare, Inc. : DNS, content delivery network in front of skeldy.com, and inbound email routing. Company established in the United States; global network, traffic transits the point of presence closest to the visitor.
• Resend : sending of transactional email. EU region.
• Stripe : payments and billing. European Union and United States.
• Moonshot AI : language-model inference: schedule generation, rule interpretation, scheduling chat, and reading of photographed schedules. Company established in Beijing, People's Republic of China. See section 5.
• OpenAI : text recognition on imported PDF documents, and on those alone. United States.
• Google LLC : Gemini API, retained as a technical fallback and not called in nominal operation. Company established in the United States; global infrastructure, data residency in the European Union is not contractually guaranteed.
• Mistral AI : technical fallback path, France. Not called in normal operation.
• Sentry : application error monitoring. EU region (ingest.de.sentry.io).
• PostHog : product analytics. eu.posthog.com.

Two clarifications that close off common suspicions. Fonts are served from our own domain and no request is made to Google from your browser. Payment is a redirect to a page hosted by Stripe: no Stripe script is loaded on skeldy.com and no Stripe cookie is set there.

Where a transfer outside the EU/EEA takes place, we rely on the Standard Contractual Clauses (Decision 2021/914) and on supplementary measures: encryption in transit, limitation of the fields transmitted to what the task requires, exclusion of sign-in credentials and payment data, role-based access, and logging of privileged mutations.

Skeldy's AI features rely on models operated by third parties. The primary provider is Moonshot AI, a company established in Beijing, People's Republic of China. This section is the most important part of this policy.

What is transmitted when a schedule is generated or modified: the first and last names of the staff concerned, their internal identifier, their qualifications, their weekly hours cap, their approved days off, the week's shifts, the section names, and your organisation's rules. To that are added the text you write in the chat and the history of the current conversation.

What is transmitted when a schedule is imported from a photo: the document itself, in full, together with the named list of staff for the section concerned. A photographed schedule generally contains the venue's entire headcount, including people who have never used Skeldy.

What our requests never assemble: email addresses, passwords, time-off request reasons, payment data. None of those fields goes into the data the system puts together and sends to the model.

That undertaking covers the fields we serialise, and it cannot cover what you write yourself. The free text you type into the chat and the history of the conversation go to the model as they are. If you enter a colleague's email address there, or any other data, it is transmitted along with your message. We would rather say so than let you assume a filter reads your sentences: there is none.

The other paths are narrower. Text recognition on PDF documents goes through OpenAI, in the United States. Google LLC's Gemini API is called on no path at all: the tool-calling assistant goes through Moonshot AI as well. It remains wired, with Mistral AI in France behind it, only as a technical fallback in the case described in the next paragraph.

A clarification on the scope of that split. The provider called is not fixed in the code: it is set by a deployment parameter, which we can change without modifying the application. What you read above is the configuration in force as at the effective date of this policy. Were that parameter to be missing, the requests concerned would fall back to Google LLC's Gemini API : hence its presence in the list in section 4. Any lasting change to this split is a subsequent change of sub-processor and follows the 30-day notice period provided for in clause 4 of the Data Processing Addendum.

The European Commission has issued no adequacy decision for the People's Republic of China. The transfer to Moonshot AI therefore relies on the Standard Contractual Clauses (Decision 2021/914) and on the supplementary measures described in section 4: encryption in transit, limitation of the fields transmitted, exclusion of sign-in credentials and payment data.

We do not claim that these measures neutralise the risk. Chinese law allows a public authority to require a local provider to grant access to the data it holds, and contractual clauses do not bind a public authority. A customer for whom this transfer is incompatible with their requirements should write to us at [email protected]: the provider called is a deployment setting, and we will discuss it.

The AI usage counters we keep on our side aggregate token volumes per organisation. They contain no conversation content.

Four retention periods are currently enforced automatically by the system: that of the audit logs, that of imported schedule documents, that of the Stripe webhook log, and that of names read from a schedule and never matched to an account. Everything else stays in the database until deletion is requested or carried out by hand. We prefer to write that down rather than announce periods that nothing enforces.

• Audit logs : 13 months, on every plan. Enforced nightly by a database job.
• Account and schedule data : retained for the duration of the subscription. Termination triggers no automatic erasure: the data stays in the database until you request deletion.
• Imported schedule documents : the file itself, PDF or photo, is erased as soon as its processing ends, whether it succeeded or failed, and at the latest 24 hours after it was uploaded. A database job sweeps every quarter of an hour. Earlier versions of this policy announced deletion after one hour with nothing enforcing it; this is the real period. The processing record, which keeps the names read from the document, has no automatic period.
• Names read from an imported schedule and never matched to an account : 13 months. After that, the name in the shift note is erased and the matching staging row is deleted. The shift itself stays on the schedule : it records how the service was organised, not who a person is.
• Webhook events received from Stripe : a technical log whose function is to refuse the same event twice. Its payload, namely the manager's name, email, billing address, and VAT number, is erased after 30 days; only the identifier, type, and date remain, which is enough for duplicate control. The whole row is deleted after 90 days. A database job enforces this nightly. That retention does not arise from the accounting obligation: the accounting records are the invoices and receipts, issued and kept by Stripe, and it is those that the 10-year retention under the French commercial code covers.
• Invitations : the token expires and becomes unusable, but the record and the email address remain.
• Waitlist : retained until deletion is requested.
• AI assistant conversations : retained with no automatic period.
• Platform and server function logs : retained according to the retention periods of our hosting providers, which we do not set ourselves.
• Analytics events : retained according to the retention configuration of PostHog EU.

You can request deletion at any time. What it takes with it and what it leaves behind is described in the next section.

Deleting an account does not erase everything. Here is the exact split, unrounded.

What goes with the account:

• The authentication account and the user record: name, email, language, role.
• The staff profile: qualifications and preferences.
• Declared availability.
• Section assignments.
• Shift swap requests, both sent and received.
• Time-off requests made by that person, reason included.
• AI assistant conversations written since 14 August 2026, which are attached to their author.

What remains, and why:

• Shifts. They are detached from the person : the link to the account is cleared, the shift stays on the schedule. Without that, the venue's operating history would be destroyed every time a member of staff leaves.
• Names read from an imported schedule that were never matched to an account. They live inside a shift note, with no technical link to a user, so no account deletion reaches them. They are erased automatically after 13 months, and we remove them by hand before that term, on request.
• Audit logs, for 13 months. The deletion is itself logged, with a copy of the erased row. In other words, exercising the right to erasure writes part of that data back for 13 months. That is the accepted trade-off of a log nobody can rewrite, ourselves included. The automatic purge of unmatched names is the exception: it writes no audit row at all, precisely so as not to give thirteen more months of life to the data it has just erased, and leaves instead a record of the operation, its date and the number of rows touched, that contains no name.
• Webhook events received from Stripe, which depending on the case contain the signatory's name, email, billing address, and VAT number. That log carries no link to your organisation: no account deletion reaches it. It now has its own period: the payload is erased after 30 days and the whole row after 90 days. It is not covered by the 10-year accounting obligation, which applies to the invoices kept by Stripe, and we remove it before that term on request.
• Invitations sent, with their recipient's email address.
• The names extracted from an imported schedule, for 13 months. The source document does not remain: it is erased at the latest 24 hours after it was uploaded.
• AI assistant conversations written before 14 August 2026. They record no author, and nothing in our data allows one to be reconstructed: no individual deletion reaches them. We neither deleted them nor attributed them on a guess; we made them unreadable by any account.

When a General Manager removes a member of staff from the organisation, the account is not deleted. It is detached from the organisation, and both the user record and the authentication account remain. Full deletion must be requested at [email protected].

The General Manager can delete their own account from the settings of their customer dashboard. If they are the last manager in the organisation, the organisation is closed along with them: the subscription is cancelled and the schedules become read-only. Schedules, sections, and staff records are not erased at that moment; their deletion follows the procedure described below. The confirmation screen says so before you confirm.

In some cases deletion fails at database level, notably where the person concerned has arbitrated time-off requests. We then handle it manually and confirm the outcome to you within the one-month period set by the GDPR.

An automatic procedure for deleting an entire organisation now exists: a single operation erases the venues, the sections, the schedules, the shifts, the rules, the staff records and everything else attached to the organisation : imports, invitations, subscription, availability, time-off requests, conversations with the assistant : then the organisation itself and its audit logs. It cannot be triggered from the interface: erasing a workspace is done on written request. Staff accounts survive it, detached from any organisation, until their holders delete them.

You have the right to access, rectify, erase, restrict, port, and object to the processing of your personal data, plus the right to withdraw consent at any time without affecting prior lawful processing.

To exercise these rights, write to [email protected]. We respond within one month, extendable by two further months for complex requests, with notice.

Exporting and deleting your account are now available from the settings of your customer dashboard, without going through us. Earlier versions of this document announced these tools while no button in the product reached them; a button does, since 13 August 2026.

What is withheld from that export is withheld by the code, not by hand. Your AI assistant conversations are now returned to you, but only yours: the table has recorded their author since 14 August 2026, and the export returns only the rows that carry your name. Those written before that date have no recorded author and can be returned to nobody. Time-off requests you arbitrated come out reduced to their identifier, their status, and their date, without the requester's name or the reason they wrote. A right of access must not serve to obtain a third party's data.

You may lodge a complaint with the CNIL (France, www.cnil.fr) or with the supervisory authority of your habitual residence, place of work, or place of the alleged infringement : for example AEPD (Spain), BfDI (Germany), Garante (Italy), or the Information Commissioner's Office (UK).

If your General Manager or Section Manager invites you to Skeldy, we receive your name, email, role, and section assignment from them rather than from you directly (GDPR Art. 14). The legal basis for this collection is the legitimate interest of the organisation in operating its workforce schedule, balanced against your interests via this notice and your rights below. You may object at any time by contacting your General Manager or by writing to us.

An account may also be created in your name without your having been told beforehand. When a General Manager imports a schedule from a photo or a PDF, the names read from the document are used to create staff accounts. The address attached to such an account is a technical address derived from your name, on a domain we control which is not the domain of the website. It serves as an account identifier, not as a means of contact: Skeldy sends it no message, and the account's temporary password is handed to the manager who ran the import, never sent to that address. We stop there and do not claim that no mail could ever reach it: that would be a statement about a mail configuration, not an undertaking this document can keep. The account makes your name and your schedule visible to the members of the organisation.

If an account has been created in your name and you want it deleted, write to [email protected]. We handle the request even if you have never used the product and even if you are not our customer.

Skeldy's AI features (schedule generation, schedule reconfiguration, photo and document OCR on import) propose outcomes; they never automatically apply changes that affect your shifts. A General Manager or Section Manager always reviews and confirms before any schedule is published. You are not subject to a decision based solely on automated processing within the meaning of GDPR Art. 22(1).

If you believe an AI suggestion that was actioned by your manager has unfairly affected you, you have the right to obtain an explanation, contest the decision, and request human re-review. Contact your General Manager first; if unresolved, write to us.

Skeldy is a B2B workforce-management platform and is not directed to children. Where staff under 18 are scheduled, most commonly 16- or 17-year-olds in apprenticeship, the General Manager is responsible for confirming parental authorisation where national law requires it. Skeldy applies no automatic country-specific restriction for minors: the rest and hours-cap rules are the ones the organisation defines itself in the product. We do not knowingly collect personal data from children under the relevant national age of digital consent without parental authorisation.

Encryption in transit (TLS 1.2+) and at rest (AES-256). Row-level security on every database table. Role-based access aligned with your hierarchy: General Manager, Section Manager, Staff. Audit logs on privileged mutations : shifts, rules, staff, venues, subscriptions, invitations, imports : retained 13 months.

What we do not have yet, written as plainly as what we do. No penetration test by an independent third party has been carried out to date: the scope is drafted and an internal security review has been run, but the engagement with an external provider has still to be placed. SOC 2 Type 1 readiness is in progress and no attestation report exists. Earlier versions announced annual penetration tests; that was an intention, not a fact, and we are withdrawing it.

The schedule documents you import are kept encoded inside our database in Frankfurt, and not in a separate object store. We spell this out because the usual phrasing, "encrypted object storage", would describe an architecture we do not have.

Sentry monitors application errors: it sends us the error report, the navigation path that led to it, and, on a fraction of page loads, a performance trace. It records no session replay. That feature is not installed in the application and deliberately stays that way, because it would film named schedule grids; were we ever to turn it on, this document and the Data Processing Addendum would say so beforehand. Sentry sets no cookie and writes no entry into your browser's storage. Ingestion transits through our own domain, which makes it invisible to a content blocker. This processing rests on legitimate interest and not on your consent. We write it here because nothing else would tell you.

When a manager creates your account, a temporary password is sent to you by email, in clear text in the body of the message. It must be changed at first sign-in.

Suspected vulnerabilities can be reported confidentially to [email protected].

We notify customers by email at least 14 days before any material change to this policy. The effective date at the top of this page reflects the version currently in force.

That notice period applies to future changes. It was not observed for the version of 13 August 2026, and the explanation fits in one sentence: this version creates no new processing. It describes processing already under way that the previous versions described badly. Waiting fourteen days would have given the reader nothing to weigh up; it would only have prolonged inaccurate information by fourteen days. So we corrected first, and we own that here rather than leave two paragraphs contradicting each other.

What this version corrects: the list of sub-processors, the silence on the transfer to China, the inventory of cookies and browser storage, the retention periods announced, the retention basis for the Stripe webhook log, security measures announced but not in place, and the availability of self-service export tools. The 30-day notice period provided for in the Data Processing Addendum applies to future additions of sub-processors.