SottoV

Privacy

Last updated 19 August 2026

SottoV carries what a household says to the people who act on it. That means it handles the private words of a private house — so this page is specific rather than reassuring, and where something is unresolved it says so.

Who is responsible

EncoSphera GmbH, Dorfstrasse 23, CH-8234 Stetten SH, Switzerland, registered as CHE-241.639.726. Questions about this notice, and any request under the rights described below, go to contact@sottov.com.

The company is Swiss, the service is offered from Switzerland, and the data is stored in Switzerland. Where a household or its staff are in the EU or the EEA, European data protection law applies alongside Swiss law — not because of where the disks are, but because of where the people are, and that is what decides it. Moving the disks to Switzerland does not move that question, and this notice is written to satisfy both.

Whose data, and what

The household’s own people — the principal and, where there is one, the chief of staff. Name, email address, the language they work in, their passkeys and second factor, and the devices and addresses they sign in from.

The entourage — the people a household sends work to. Name, role, the domain they work in, their language, whether they are internal or external, a portrait if one is uploaded, the places they serve, their working week and any absence. They have no account and no password: they reach their requests through a signed link, and the browser they open it in is bound to them — by a one-time code sent to them, or by following a link the household itself sent them by text message. Up to five browsers at once, so that a phone and a tablet, or an app and a browser on the same phone, do not turn each other off; beyond that the oldest quietly steps aside.

When the entourage is not available — the dates of a person’s leave and the fixed weekdays they do not work, set by the desk. These are working-time records. They are shown to everyone in the household about to hand that person work, and they decide whether their phone may ring. Which houses a person serves is recorded too, and travels to the splitting provider along with their name, role and language.

What is said — the transcript of every spoken note, the requests made from it, the messages exchanged about them, and any photograph taken as proof that something was done. A request is free text: it can contain anything a household chooses to say, including matters about children, health or whereabouts. Nothing filters that, and nothing pretends to.

Which is why one kind of thing must be kept out of it. Passwords, passphrases, recovery codes, PINs, card and account numbers, and any other secret whose worth is that nobody else has seen it. A request is stored readable, it passes an automated system that reads it, and it is shown to the person it is addressed to — all three are described on this page, and none of them is a fit place for a credential. This is not a caution about ordinary personal data: names, roles, hours and instructions are what the service is for. It is about the things whose disclosure is itself the harm. The terms say the same in clause 2, and say who carries the loss if it happens anyway.

Visitors to this site — the public pages set no analytics and no tracking cookies. Nothing about a visitor is recorded until they sign in.

Signing in

SottoV holds no passwords: password sign-in is switched off and the database has no password field. People sign in with a passkey on their own device, and a chief of staff also carries a second factor — a time-based code, required unless that device was confirmed within the last thirty days.

There is one way in that uses no passkey, and it should be said plainly: if a device is lost, a one-time link sent to the address on the account restores entry. A chief of staff must still enter their second factor. A new passkey is set up straight away.

Members of the entourage have no account and no passkey at all — they use a signed link, and the browsers they open it in are bound to them by a one-time code or by a link this household texted them.

Where it is stored

In Switzerland, with a Swiss company. The application, the database and the uploaded files — portraits and proof photographs — all run at Nine Internet Solutions AG, Badenerstrasse 47, 8004 Zurich, in their data centre in Rümlang. One supplier, one contract, Swiss law and a Swiss forum. Not a European region rented from an American company, which is a different thing and the one usually on offer.

Backups are taken nightly and kept for thirty days, with a copy held seven days at a second Swiss data centre.

Nine relies on others in turn, and that list is part of their agreement. One entry reaches us: their own company in Canada, listed for emergency support and maintenance, and listed as applying to all their products — so to ours. The annex records Canada as the place of processing for that row. How far it reaches in practice is Nine’s to state rather than ours to infer, and we would rather name the entry than describe it more narrowly than we can show. Switzerland recognises Canada as providing adequate protection where its federal commercial-privacy law applies, which it does for paid support work, so this needs no further safeguard. It needs naming, and that is what this paragraph is.

One exception, and it is about visitors rather than households: the two public pages — the front page and the trust pages on www.sottov.com — are served by Vercel until 22 August 2026. They carry no household data, no sign-in and no measurement of any kind. Everything a household says reaches Switzerland, not them.

Speech, and the two roads it takes

Not every spoken word travels the same way, and the difference matters more than it looks.

A principal’s voice note is sent as audio to OpenAI in the United States to be turned into text. Sent with it: the dictation language where one has been chosen, and a short vocabulary hint — the proper nouns the household has written down, then the names of the entourage, then the household’s own name. SottoV never stores that audio. No table and no file store holds a recording; it stays in the phone’s memory only until a transcript comes back, and only the transcript is saved. What the provider keeps of the copy it receives is governed by that provider’s retention terms, not by ours.

Every other microphone — the one beside any message field, and the one beside the transcript — does not reach our servers at all. It uses the device’s own speech recogniser, which on iPhone and Android normally means audio going to Apple or Google.

And the first falls back to the second. A long voice note is heard by the device’s recogniser instead of the transcription provider in four cases: no key is configured, the provider refused over its own account within the last five minutes, it refuses mid-visit, or the browser cannot record at all. Either way the audio goes to Apple or Google rather than to OpenAI, and words are never lost to a setting or a bill — only heard less well.

Three of those four are brief; the fourth is not. SottoV stops asking a refusing provider for five minutes and then asks again. But a browser without a working recorder never gains one, so there every voice note takes the device path for good — and the screen does not currently say so, because the recording display is the same in both modes. That is a defect rather than a design, it is not yet fixed, and it is written here plainly because the alternative is a notice that describes a fallback as brief when for one cause it never ends.

To split a spoken note into requests, the transcript is sent to Anthropic in the United States together with the household’s directory — each person’s name, role, domain and language, and the properties they serve where a household keeps more than one — plus the properties themselves with their locations and time zones, and the speaker’s local time. Translating a request or a message is a separate call carrying only the text and the two languages, never the directory.

Those three — OpenAI, Anthropic and Resend, which sends email — are the outside services SottoV hands your words to. Two more hold or carry them without being asked to read them: Nine, where the application, the database and the photographs live; and Apple and Google, whose relays carry notifications sealed against your device. What there is none of is a service that watches you: no analytics, no error reporting, no advertising, no measurement of any kind.

Requests are split and routed by a model

The model reads the transcript and proposes who should do what, by when, and at which property, using each person’s role, domain, language and absence. In a household that keeps a chief of staff, nothing reaches anyone until that desk has approved it. In a household that runs without one, the owner reviews and sends. Finance and security matters always pass an explicit human approval, whichever way the household runs.

Photographs

Proof photographs are normally taken with SottoV’s own in-app camera, which never touches the phone’s library: the image is drawn from the live stream and uploaded straight from memory. A household can switch on a second option that lets somebody choose an existing photograph instead; it is off unless the household turns it on, and the app says plainly when it is in use.

Every photograph — a proof, a portrait of somebody in the entourage, a background a principal chooses — is decoded on our server, and where it carries an EXIF, XMP or IPTC container, which is where GPS coordinates live, that container is discarded and the image re-encoded before it is stored. An animated GIF is the one exception, left as it is because re-encoding one here would flatten it to a single frame.

A picture taken with SottoV’s own camera carries nothing to remove and is stored exactly as it was taken. And what the file claims to be is not what decides: the format is read from the bytes.

Notifications

Push notifications travel through the relay operated by the recipient’s own browser vendor — Apple’s on Safari and iOS, Google’s on Chrome and Android. The payload is encrypted for the receiving device before it is handed over, so the relay carries ciphertext.

What a phone may do with a notification once it arrives. Chrome on Android inspects incoming notifications on the device and may replace one with a warning card. If the recipient then reports it, Google states that the notification’s content and our address are sent to Google; if they mark it safe, that details are sent. This is their browser acting on their own tap, after our encryption has done its work — we neither cause it nor see it, and no setting of ours prevents it. We name it because encryption closes the wire, not the door the recipient opens.

A household can switch on content-free notifications: the lock screen then says only that something arrived. Who it is from still appears in the heading. That setting also closes the door above, since a message that names no request has nothing to hand on.

What sits on the device

A session cookie while somebody is signed in. For a chief of staff, a cookie remembering that a second factor was confirmed, for thirty days. A short-lived cookie recording a fresh passkey check, for the few minutes a sensitive action needs one. For a member of the entourage, a cookie that binds their link to that browser, kept for a year, and a shorter one recording that the device is secured enough for finance and security work.

None of these are advertising or analytics cookies. There are none.

Alongside them, two things are recorded that are easy to overlook: the IP address and browser of every live session and of every entry in the access log, and the time each account holder last opened the app — which is what makes the “since you were last here” summary possible.

What is written down about access

Everything that touches access is written to the household’s own log: sign-ins and sign-outs, second-factor checks, invitations, links issued, reissued, revoked or opened, devices bound, sessions ended, and anything SottoV’s operator did. Each entry carries the time, what happened, and the IP address it came from. Separately, each request keeps its own history — created, approved, started, completed, reopened, edited, photographed, withdrawn.

Other actions are in neither: changing a setting, editing a person’s details, sending a message on a request, and simply reading what is there. A household’s chief of staff — or its owner where there is no desk — can read the access log in the app.

How long it is kept

A household chooses. Until it does, nothing expires by itself: requests, messages and photographs are kept until somebody removes them, which is what every household has unless it has said otherwise.

A household may instead set a period — a season or a year. Once a request has been finished or withdrawn for that long, its words are overwritten: the title, the detail, the conversation, the private note the desk wrote for the staff, and every name attached to any of them, including who it was given to. The proof photograph is deleted outright. What is left is that a request of that kind existed, at that hour, and was settled — a record about nobody.

This is not reversible and is not the same as the setting that decides how long finished work stays on the entourage’s own screens. That one hides and can be changed back. This one overwrites.

Two qualifications, both honest. It takes effect on the next nightly pass, not the instant the period elapses. And the database keeps a recovery history described below, so the true figure is the period the household chose plus that window.

Rights, and how they actually work here

A household can ask for everything held about it and receive a single readable file: its directory, properties, requests, messages, recorded steps, spoken notes, accounts and its full access log, with portraits and proof photographs included. Credentials are deliberately left out — a passkey or a second-factor secret is a key to the house, not a fact about it. One thing does travel with it that reads like a credential and is listed here for that reason: each member of the entourage carries a permanent internal identifier, and the copy includes it.

A household can also ask for all of it to be erased. The process rehearses first, lists exactly what would go, and names anything it could not remove rather than claiming success.

One honest qualification about “erased”. It takes effect at once in the live service — nobody can reach the data again from the moment it runs. The database is also backed up, so that a bad migration or a mistake is survivable, and an erased household’s rows remain inside those backups until they expire: one backup a night, kept thirty days, and a copy of it held seven days at a second Swiss data centre. So the last copy of an erased household disappears within thirty days of the erasure, not on the day of it. Nothing is read from there in the ordinary course; it exists to put the service back on its feet.

Both are performed by SottoV’s operator on request, not by a button in the app. An export is written into the household’s own log, so it is never invisible to the people it describes. An erasure cannot be — it removes that log along with everything else, so what survives is one line in the operator’s own register, naming the household, what was removed and when.

Corrections are immediate: the desk edits any person or request in the app. Requests under this section, and any complaint, go to contact@sottov.com. A data subject in Switzerland may also approach the Federal Data Protection and Information Commissioner, and one in the European Union their national supervisory authority.

Who at SottoV can read what

The operator console shows names, counts, states and timestamps — never the text of a request. It carries one deliberate exception: the export described above, which produces a household’s complete data as a file so that an access request can be answered. It requires a fresh passkey each time, and using it writes a line into that household’s own log.

Changes

This notice changes when the service does. The date at the top is the last change, and material changes are told to households directly rather than left to be noticed.

ImprintPrivacyTermsBack