Privacy policy.

SECTION 01

Who this policy is for

Owneli is the software a salon, spa, medspa or wellness practice uses to run its day. Two very different people read this page, and which one you are changes almost every answer below.

This policy covers the Owneli platform: this website, the staff application, the client portal, the booking and shop pages we host for businesses, the tokenised links we send by email and text, and the mobile apps.

• You run a business on Owneli, or you work in one. You hold a Owneli sign-in, and this policy tells you what we hold about you.
• You are a client of a business that uses Owneli. Your appointments, forms and treatment records live in that business’s workspace. This policy tells you what the software does with them, and who to ask about them.
• You are reading the website. You have given us nothing beyond the request that loaded this page — unless you asked for early access, registered a business, or asked us to help move your data across.

SECTION 02

Two roles: controller and processor

For your account with us, Owneli decides what is held and why. For everything a business records about its own clients, the business decides and we act on its instructions.

Owneli is the controller of the data behind a Owneli account: the sign-in itself, the profile attached to it, the sessions it opens, and the enquiry that may have preceded it. We decide what that needs to contain for the software to work, and we answer for it.

Owneli is a processor of everything a business records about its clients — the client record, the appointment, the intake form, the chart, the photograph, the sale, the message. The business decides that data exists, decides who on its team may see which part of it, and decides when it goes. We store it, protect it, and do what the business’s use of the software instructs.

That split is enforced in the database, not just described here. Every record carries the organisation it belongs to, and the access rules attached to each table refuse rows belonging to another organisation. A business’s team cannot reach another business’s clients, and neither can a business reach the platform’s other customers.

One person can be a client of several businesses on Owneli. Each business holds its own separate record of you, and one portal sign-in can be linked to several of them. Deleting the sign-in unlinks all of them at once; it does not reach into any business’s own records.

SECTION 03

What is held

Grouped by whose data it is, because the answer to “who decides about this” differs for each group.

People who hold a Owneli staff sign-in — owners, managers, practitioners, front desk. Owneli is the controller of the account; the employer is the controller of the employment record behind it.

Clients of a business using Owneli. The business is the controller of all of it; we hold it on their behalf.

Visitors, and people who ask us for something. Owneli is the controller.

Where it comes from: typed by a business’s team, entered by you when you book, fill in a form or use the portal, generated by using the software, imported by a business from a system it used before, or returned to us by a payment, email or messaging provider — a payment outcome, a delivery receipt, a text message you sent back.

SECTION 04

Health data

Medical and treatment information is special-category data. Owneli handles it as such rather than as ordinary client detail.

A medi-spa records health information as a matter of course, and this platform is built to hold it: consultation and intake forms, treatment charts written against an appointment, allergies on the client record, patch test results, clinical free text, before and after photographs, and whatever a person types into the “anything we should know?” box when booking.

Health data is not treated as ordinary client data anywhere in the product:

• Seeing it is a separate permission. A colleague who can book appointments does not automatically see charts, allergies or clinical notes; a business grants those capabilities deliberately, per person.
• A form a business marks as containing health information has its answers and signatures hidden from staff without the charting permission, and revealing them is a deliberate, audited action.
• Where a field is hidden from someone by permission, the screen says it is hidden. It never renders as empty — “no allergies recorded” is a clinical assertion and the software will not make it on a permission’s behalf.
• Photographs, signatures, uploaded documents and imported files live in private storage that is never publicly readable, and are served through short-lived signed links.
• The AI assistant has no access to it at all. There is no chart tool, and the search index it reads is built from a business’s own authored material, never from a client record.

The lawful basis for holding health data — usually explicit consent, given to the business on a consultation or consent form — is the business’s to establish and record. Owneli provides the forms, the signature, and the evidence trail that shows when it was given.

SECTION 05

Why it is processed

Each kind of processing exists for a stated reason. For client data the purpose is set by the business; the column below describes the purpose the software serves.

Owneli does not sell personal data, and does not share a business’s client list with another business. A client of two businesses on the platform has two separate records that never meet.

SECTION 06

Who else receives it

The companies that hold or handle data on our behalf, what each one gets, and whether it is always in use.

Beyond those, data is disclosed to a business’s own people under the permissions it sets, and to anyone we are legally required to disclose it to. The first two rows are always in use, and error reporting runs wherever a deployment has been given a reporting key; every other row depends on a feature being configured, and several depend on an individual business turning it on.

SECTION 07

AI features

Sage is the assistant inside the app. It is off unless an administrator turns it on, it reads what the person asking is already allowed to read, and it cannot reach clinical charts.

Sage is switched off for an organisation until an administrator enables it, and then reaches only team members holding the capability for it. It is not available to clients and it is not part of the booking flow.

What it can look up: clients and their contact details, tags, visit history and memberships; the schedule; services, products and stock; reviews; the recent messages in a client’s conversation thread, in both directions; published policies; form templates; reports and business totals; settings; and the help centre. Every result is filtered through the permissions of the person who asked, so Sage never becomes a way around a permission. It drafts and explains — it cannot charge a card, send a campaign, delete a record or change a permission.

What it cannot reach: clinical charts. There is no chart tool, and the search index Sage reads is built from a business’s own authored material — policies, care pages, services, products, form templates and our help articles — and contains no client records.

Where the data goes. A question, and the records fetched to answer it, are sent to a large language model provider — Anthropic or Google, depending on how the deployment and the organisation are configured. The search index behind Sage is built with Google’s embedding model in every configuration. A file attached to a question, including a scanned document, is sent to the provider in full. Voice input is sent to Google for transcription along with the business’s own glossary of service and product names; the audio itself is never written anywhere — it exists for the length of the request and is gone when it returns. Only usage totals are recorded, not the transcript.

Sage conversations are deleted thirty days after they are saved, discarded or expire. A file staged for a question is swept within the hour if the question is never asked.

One related use outside Sage: when a business imports clients from another system, the column headings are sent to a model to work out which column is which. The sample values that go with them are masked first — an email becomes a shape, a phone number becomes a run of hashes, free text keeps only its word count — so no real value leaves. Drafting campaign copy and rewriting a venue description also go to a model; neither is sent anything about a particular client.

SECTION 08

Messages, marketing and consent

Service messages are part of the booking. Marketing messages need consent, respect opt-outs, and are held to a civilised hour.

Service messages — a booking confirmation, a reminder, a receipt, a form request, a payment link, a sign-in email — are part of what a business does for you and are sent because you have an appointment or a purchase. They carry no unsubscribe link, because unsubscribing from your own appointment confirmation is not a thing anyone wants.

Marketing messages — campaigns, win-backs, birthday and loyalty notices, review requests, expiring-offer nudges — go out only where the consent flag on the client record allows them, and the moment consent was given or withdrawn is recorded beside it.

Text messages pass one gate before they are sent, and the gate fails closed:

• The business must have messaging switched on at all.
• Anyone who has opted out receives nothing, of any kind, from that business.
• A marketing text additionally requires the consent flag on the client record.
• If the recipient cannot be positively matched to a client record, nothing is sent.

Replying STOP, STOPALL, UNSUBSCRIBE, CANCEL, END or QUIT opts you out immediately, for the business that owns the number that texted you. START, UNSTOP or YES opts back in. The change is written to the client record, dropped into the conversation thread so the business can see it happened, and logged. Because an unverified opt-out could be used to revoke consent in bulk, the platform refuses to act on a reply it cannot verify came from the messaging provider.

Marketing texts are held to a daytime window — by default 09:00 to 20:00, adjustable by the business. A message that would land in the quiet hours waits. The window is evaluated in the business’s own timezone, or its location’s where it runs more than one, rather than the server’s — which also means it is not evaluated in yours. If you live somewhere else, a message timed for that business’s evening can reach you in your early morning.

Marketing email carries a one-click unsubscribe in the mail headers as well as a link in the footer, alongside the business’s postal address. Unsubscribing switches the consent flag off for that business’s marketing entirely, not just for that campaign. Reporting an email as spam does the same thing, permanently, as soon as the delivery provider tells us.

A client with a portal sign-in can see and change both consent flags themselves at any time, and a business can change them on request.

SECTION 09

Cookies, storage and measurement

The app itself sets a handful of cookies and no analytics. Advertising measurement exists, but only on the booking pages of a business that has switched it on.

Rather more is kept in your browser’s own storage, where it stays on your device and is never sent to us: an unfinished booking so a refresh does not lose it, a shopping bag, a form draft, your language, your calendar and report preferences, which notifications you have read, and the cookie-banner decision if you were shown one.

Owneli’s own website and application run no analytics and no session recording. They do run error reporting: when a page or a request fails, a report goes to Sentry, described under who else receives it. It carries the technical shape of the failure, not the form you were filling in, and it sets no cookie. The fonts and icons the pages use are served by the application itself rather than fetched from a third party. The exception is the brand-themed surfaces — a business’s own venue page, the client portal and shared care pages — which load two typefaces from Google Fonts, so Google sees the request for them and the address it came from.

Conversion tracking is different, and it is worth being precise about it. It is an add-on an individual business switches on for its own booking and shop pages. Where it is on, those pages load Google and Meta tags, and a completed booking is also reported from our servers to Meta, Google Analytics and Google Ads. That report contains the value of the booking and a hashed form of your email address and phone number, and — to Meta only — your IP address and browser string unhashed.

Separately from the banner, the advertising click identifiers and campaign tags in the link you arrived on are kept in your browser for thirty days and attached to a booking if you make one. That happens on any booking page, whether or not a banner was shown.

SECTION 10

Where it is processed

The application is served from the United States, and its providers operate internationally, while much of the customer base is in Canada, the UK and Europe.

The application runs in the hosting provider’s Washington, D.C. region — the identifier in our deployment configuration is iad1 — which means requests are served, and code executes, in the United States. Scheduled work such as reminder sending, billing and retention sweeps runs from the same place.

The providers named above operate internationally. Payment, messaging, email, push and AI providers each process data in their own regions, which are not all the same and are not all in one country. Error reports are the exception we have pinned down: they go to Sentry’s European Union region, and the software refuses a reporting key from any other region unless the deployment states in so many words that it accepts one.

A great many of the businesses on Owneli, and their clients, are in Canada, the United Kingdom and Europe. Data therefore crosses borders as an ordinary part of using the service. The precise region of each data store, and the transfer mechanism relied on for each provider, are being documented and are on the list at the end of this page rather than being asserted here without the paperwork to back them.

SECTION 11

How it is protected

Separation between businesses, permissions per person rather than per job title, and private storage for the sensitive material.

• Every table enforces its own access rules in the database, so a query that escapes the application still cannot cross from one business to another.
• Permissions are granted per capability, not per job title. Contact details, financial figures, clinical fields and photographs are each their own permission, and a business gives them out deliberately.
• Photographs, signatures, documents, message attachments and import files live in private storage and are reachable only through short-lived signed links.
• Presentational images are deliberately not in that private storage: staff profile photos, business logos and branding, care page media, and product, service and venue images sit in public buckets, because they are drawn on booking and shop pages that anyone can open without signing in. Anyone holding one of those URLs can open it without signing in, and it stays reachable until the image is replaced or removed. The file paths cannot be listed or browsed, so a URL has to have been given to you. Nothing clinical is stored this way.
• Card numbers never reach us. Card entry happens in a payment form hosted by the payment provider, and we receive only a token, the brand, the last four digits and the expiry.
• Sensitive actions are written to an audit trail with the person, the time, the IP address and the browser — including reads of restricted records, which require a written reason.
• Responses carry a strict content security policy with a per-request nonce, transport security is enforced in production, and public endpoints are rate limited and protected against automated abuse.
• Webhook calls from payment and messaging providers are signature-verified and rejected if they cannot be verified.
• Operational logs redact credentials, tokens, cookies, email addresses, phone numbers and clinical fields to a short prefix, so a request can be traced without the log becoming a copy of the data. Error reports are put through the same list, and more strictly — any field whose name so much as contains one of those words is redacted — before they leave the browser or the server.

No system is beyond compromise, and a policy that promised otherwise would be worth nothing. What we can say is where the boundaries are and how they are enforced.

SECTION 12

How long it is kept

Clinical records have a long, deliberate window. Most other retention is a setting the business controls.

The eight-year default for clinical records is not arbitrary. Guidance for aesthetic and cosmetic practice sets a minimum of eight years from the final appointment, and professional liability insurers often want longer, so the software keeps charts for a year beyond the general seven-year figure it used previously.

One gap worth stating plainly: records for a person treated under eighteen should be kept until their twenty-fifth birthday or eight years after the final appointment, whichever is later. The automatic sweep does not read a date of birth and so does not apply that rule. A business treating minors needs to hold those records deliberately rather than rely on the default.

Several records — the audit trail, sign-in sessions, booking funnel events, conversion reports, early access enquiries, and requests for help moving data in — have no scheduled deletion today. Setting one is on the list at the end of this page.

SECTION 13

Erasure, and why some records are restricted instead

A request to be forgotten is honoured by destroying what can be destroyed and withdrawing what cannot — not by pretending records never existed.

Some records cannot simply be deleted on request. A signed consent form is the evidence that a treatment was authorised. A patch test is the evidence an allergy was checked. Before-and-after photographs are frequently the only evidence in a liability claim — a claim the same person remains free to bring. Destroying those to honour an erasure request would destroy the business’s defence to it, and the law does not ask for that. It asks that the records stop being available for everyday purposes.

When a client record is erased, four different things are done to four different kinds of data. The callout below the table says which of them the software does on its own today, and which we carry out on a business’s behalf:

A withdrawn record can still be produced when a legal claim genuinely requires it, through one route only: an administrator, with a written reason, and a high-priority audit entry written for every retrieval. The access log is the entire justification for keeping the records at all.

If you want your details erased from a business’s records, ask that business. It is their record and theirs to decide about; they action the request, and we carry out the part of it that happens in the database.

SECTION 14

Deleting your Owneli sign-in

You can request account deletion inside the app or without signing in. Owneli reviews requests before any removal. Requesting personal account deletion, closing a business and archiving an employee are separate actions.

If you have a client portal sign-in: deleting it destroys the sign-in and every link it held, across every business at once. Your saved cards, any outstanding card-capture link and your notification devices go with it. A membership that was billing a saved card will need a new one.

What stays is each business’s own record of you — your appointment history, treatments, consent forms, receipts, gift cards, packages and memberships. That record is the business’s, not the sign-in’s: it carries balances it may be owed, treatments it must be able to account for, and it exists identically for the very many clients who never created a sign-in at all. To have your personal details erased from it, ask the business, and the section on erasure describes what happens then.

If you have a team sign-in: deleting it ends your access everywhere you used it, and clears your personal phone numbers, home address, emergency contact, date of birth, profile photo, saved signature, email signature, bank details and any private note held about you — in your profile and in each organisation’s copy of it.

What stays is your employment record: your name, job title, hire and end dates, employment type, hours, pay rate and role, your timesheets and commission, and which treatments you performed. Payroll, tax and clinical records have to name the person who did the work, and replacing that name with “deleted user” would falsify a clinical record rather than anonymise one.

Before a team sign-in can go, the business it leaves behind has to stay workable: an owner hands the owner seat to someone else first, the last remaining administrator cannot leave an organisation with nobody to administer it, and future appointments, an open clock-in and an open cash drawer have to be resolved so no client is left without a practitioner. This also applies to an owner of an organisation with no other members and no clients, appointments or sales — personal account deletion never closes the organisation automatically. Business closure requires a separate owner request and review.

Submitting a request does not remove access or delete data. We aim to complete requests within 30 days, subject to applicable legal deadlines, explain any additional steps, and confirm completion. Completed deletion is permanent. We retain a review history and document any records retained to meet legal obligations.

SECTION 15

Your rights, and the mechanism for each

Rights are only real if there is a way to use them. Here is the actual route for each, and who to address it to.

We will help a business answer a request about its own clients, but we will not answer it over their head or against their instructions — that is what being a processor means. If you have asked a business and got nowhere, tell us and we will do what we can.

SECTION 16

Children

Owneli is business software for adults. A business may treat a minor, and that record belongs to the business.

Owneli is not directed at children and we do not knowingly create accounts for them. A staff sign-in is for a person employed by a business; a portal sign-in is created by the person themselves.

A business may of course treat a minor with a parent’s or guardian’s consent, and record them as a client. That record is the business’s, obtained and held under its own consent process, and its longer retention rule is described under retention. If you believe a child has created a sign-in, tell us and we will remove it.

SECTION 17

Changes, and how to reach us

The date at the top of this page is the version. When the product changes in a way that changes this document, the document changes.

This policy describes behaviour that exists in the software today. When a feature changes what is held, where it goes, or how long it stays, this page is updated with it and the date at the top moves. A change that materially affects you will be signposted rather than slipped in.

If you booked with a business, contact that business first — it holds your record and it decides about it. The contact page carries their phone number, email and address when you reach it from their booking pages.

For Owneli itself — the platform, your sign-in, or anything on this page — use the contact page. A dedicated privacy address is one of the items still to be published, listed below.

SECTION 18

What this document still needs

This page is written from the code and is accurate about what the software does. It is not yet a lawyer-reviewed legal instrument, and these are the specific gaps.

• A named legal entity as data controller, with a registered address, and a published privacy contact address.
• Confirmation of the region each data store runs in, and the transfer mechanism relied on for each provider named under who else receives it.
• Signed data processing terms with each of those providers, including the AI provider, and a settled answer on whether content sent to it may be retained or used to improve its services.
• A demonstrable record of consent for the cookie banner. Today the decision lives only in the visitor’s browser, which is not a record anyone can produce later.
• A decision on whether the consent banner should be on by default rather than a switch each business finds for itself, and whether marketing email should become opt-in the way marketing texts already are.
• A retention schedule for the records that have none: the audit trail, sign-in sessions, booking funnel events, conversion reports, early access enquiries, and requests for help moving data in.
• Erasure carried out by the software rather than by us. The withholding of an erased record is automatic; the emptying and the deletions that go with it are not written yet, and setting the mark is not a self-service action either. All three belong behind one audited button.
• A standard processing agreement offered to every business using Owneli, since each of them is the controller of their own client data.
• Review by a qualified lawyer in each jurisdiction Owneli operates in, and a template each business can adapt as its own client-facing policy.

This list stays on the page until the items on it are done. A privacy policy that overstates its own standing is worse than one that is honest about where it has got to.