Privacy & data · Whenly.software
A poll that finds a time should not become a directory.
whenly.software books time, not people. A poll is a set of candidate times and a set of answers from opaque handles — not a contact list, not an advertising profile. This page says what a poll would hold and, just as plainly, what it deliberately does not.
Because the product is early access, this describes the design the poll is being built to. Where a protection is a design property rather than a running feature, it is written as such.
What a poll holds
Times, answers, and the narrowest handle a response needs.
✓Candidate times, and how each person marked them
The times a coordinator proposed, and for each responder’s opaque handle, whether they marked a time available, if-need-be, or no. That is the substance of a find-a-time poll — a set of times and a set of answers.
✓The narrowest handle a response needs
A responder is referenced by an opaque handle, not a name or an email shown to the group. The design goal is that answering a poll needs no account at all, so the record carries as little about a person as the mechanism can work with.
✓The locked time, once a group agrees
When a time is locked, a booking row against the shared no-double-book floor: which time, in which state, held against capacity. Where a school roster is involved, every identity field routes through a consent chokepoint first — a suppressed person’s name is masked at the server; the row still counts, only the identity is stripped.
What whenly is not
No names, no ads, no profile, no sale.
✓No names in the poll, no directory built from it
A responder is an opaque handle. Opening a poll does not hand you a list of everyone else’s name and email — the exact thing the group-poll tools normalise. There is no contact list to harvest here.
✓No ads shown to the people you invite
The design commitment is that whenly shows no ads to anyone who opens a poll, on any tier. Rival tools in the category usually cover their costs with ads served to your invitees; this is not.
✓No names in the calendar feed
The subscribable .ics feed carries opaque labels only: no participant name, no organizer name, no real email address — only a non-PII handle. Subscribing to a meeting cannot turn your calendar into a directory.
✓No advertising profile, no data sale, no model training
We do not build an advertising profile from a poll, we do not sell or rent scheduling data, and no model is trained on anyone’s responses. There is no third-party analytics or advertising script on this site.
✓No automated decision about a person
Finding the overlap is a count of who is free; the coordinator decides. Nothing here scores, ranks, or profiles a person, and there is no eligibility determination about anyone.
The examples on this site are explanatory material.
The new group-scheduling examples use invented adult roles and synthetic availability. A, B and C are labels in a written exercise, not records of people answering a live poll. No response is requested from the visitor to complete those examples. Their purpose is to explain what a conditional answer or an unanswered candidate means. A page that describes an availability grid should make this boundary visible so a reader does not mistake explanatory marks for their own group's stored information.
The same distinction applies to a sample time. Thursday at 15:00 can be a useful way to demonstrate a thirty-minute window, but it is not an advertised appointment or a resource offered to the reader. Changing that example in a personal note does not create a booking on Whenly. This site supplies no input control for performing the illustrated scheduling task. Its diagrams and worked prose remain descriptions, even where they resemble the information a scheduling tool might display.
This explanation adds no new operational data guarantee. The existing privacy material above describes the product's stated design and its current limitations. A fictional example cannot verify how an unbuilt poll stores information or how a separate system handles a calendar event. Keep the public page, the illustrative material and an actual operational service distinct when deciding what information a task requires.
Describe the shape of the question without reproducing a group's circumstances.
An initial product question can usually be explained with an invented example: four adult roles, two candidate windows and one conditional answer. That gives enough information to discuss the response-state distinction without identifying a real person or reproducing their private reason for a condition. The number and arrangement are fictional inputs chosen to make the example legible. They are not an instruction to submit an actual group's availability here.
For instance, the statement one response applies only to a shorter discussion identifies the scheduling uncertainty. An account of the respondent's personal circumstances is unnecessary to explain that uncertainty. The reader can ask whether the design distinguishes the two meeting lengths and preserves the condition as such. This is a manual way to keep a product inquiry focused on the task, not a claim that the site automatically removes personal information from correspondence.
If the question requires facts the public explanation does not establish, leave the answer open. A contact note does not grant product access or prove a particular storage, retention or calendar arrangement. The meaningful output of this exercise is a bounded question about the design. It does not add a consent procedure, a collection workflow or an operational promise to the existing page. The broader product and data assertions remain subject to the limits already stated here.
A question about the public page can refer to the public wording.
A reader who thinks an example is misleading can identify the page, the example heading and the particular conclusion that appears unsupported. Suppose a fictional column includes three available marks and one unanswered role, but a sentence seems to call the whole group available. The relevant material is already in the public explanation. A useful correction points to that mismatch; it does not need an actual group's answers to demonstrate the problem.
The manually authored correction might say: In the example under this heading, one answer is missing. The conclusion appears to describe everyone as available. Please distinguish the three supplied marks from the unanswered role. That gives a reviewer enough context to inspect the claim against the example. It remains a request about wording, not an upload, a stored support case or an automated check of the visitor's scheduling information.
The same approach works when the uncertainty concerns a diagram rather than a paragraph. Name the visible label and explain what it seems to imply. A highlighted column can illustrate a group preference without implying a booking exists. The reader's question should preserve that distinction instead of attributing a live result to a static example. These public-page references help keep an inquiry focused on the explanation itself, within the closed operational scope stated on the site.
Minors
The minor-safety floor binds even for adult coordination.
whenly is built for committees, chaperones, and staff — adults — but the minor-safety rules bind regardless. Minor scheduling data is consent-aware, access-controlled, and never made public. Where any surface touches a school roster, every identity field routes through a consent chokepoint: a suppressed person’s name is masked at the server, not by a UI filter a client request could disable, and the row still counts — only the identity is stripped. The calendar feed carries opaque labels only, and there are no names in a poll.
The design uses consent-aware access controls, opaque calendar labels, and no public display of minor scheduling data. Those controls are not a FERPA or COPPA certification or a compliance guarantee. There is no facial recognition and no photo store here, because whenly holds no images: it schedules time.