The mechanism · Whenly.software
Each part has a job. Each result has a limit.
The existing Whenly design describes candidate times, three answer states, an overlap count and a connection to a booking. These parts deserve separate explanations because a useful result from one does not prove the next has happened. The poll, overlap finder and booking connection are not running on Whenly. The following original examples examine their intended meaning without offering controls that pretend to execute them.
A candidate is a question with boundaries.
A candidate window gives respondents something concrete to consider. In an invented adult planning exercise, the choice is a twenty-five-minute conversation beginning at 11:00, with all participants using the same stated time basis. The question is whether the whole conversation fits. An answer about being free briefly at 11:00 does not settle that. The coordinator's first job is therefore to make the window legible, including its end and the activity it contains.
If the activity expands to forty minutes, the original answers cannot simply be carried across unchanged. The people answered a different question. An organiser can explain the changed duration and seek an answer against it through their existing process. This is a manual distinction, not a versioning or automatic notification feature. The Whenly design does not become a working revision system because this page describes how a careful coordinator handles a changed question.
The practical objection is that people often know what the organiser means. Sometimes they do. But a scheduling decision is easier to share when the meaning survives outside the original conversation. A small amount of explicit context prevents a start time from standing in for an unspecified block of work. Keep the candidate narrow enough that a person can answer it without guessing how long the organiser intends to keep them.
Available and conditional should not become the same colour of yes.
The three stated response choices are available, if need be and no. In a fictional group of five adults, one candidate receives three available marks, one conditional mark and one no. A summary that says four people can attend loses a distinction the input deliberately supplied. A better account says that three are available, one is conditional and one is unavailable. The coordinator can then decide which open question matters, instead of asking a total to carry information it has discarded.
A condition is not a request to collect the person's private reasons. The scheduling question can stay bounded: is this particular candidate workable for this meeting? Likewise, a no should not be softened because another time is inconvenient for the organiser. The example concerns the meaning of the selected answer, not a prediction of whether someone can be persuaded to change it. The product's existing description uses deterministic counting rather than a model; this page adds no automated interpretation.
A missing answer remains outside those three choices. It is neither consent to the proposed time nor a refusal to take part. If the organiser knows only that four of five adults have answered, the useful summary keeps the fifth answer open. No tally on this page is collected from visitors, and none of these fictional marks becomes a saved response. The example teaches the distinction without claiming a hidden polling service.
A count explains the marks, not every reason for choosing a time.
Suppose candidate A has four available and one conditional response. Candidate B has four available and one unavailable response. Those columns have equal available totals, but they do not describe equivalent options. The conditional response may be worth clarifying; the unavailable response is an established conflict in the supplied information. A reader can understand that difference without a scoring formula. The numerical result should support an explanation rather than replace it.
A second fictional comparison is less tidy: candidate C has three available and two conditional marks, while candidate D has four available and one missing answer. The inputs do not establish a universal winner. The coordinator may need to clarify a condition, wait for an answer or reconsider the proposed windows. The design's overlap finder is described as counting response states; this page does not invent a tie-breaking rule, weighting system or ranking of people that the source does not establish.
Is an overlap tool useful if a person still makes the decision? Yes, the arithmetic and the decision are different jobs. A clear count can expose why the choice is difficult: one known conflict, two conditions or an unanswered participant. It can help the organiser ask a smaller next question. It cannot determine every purpose of the meeting or make missing evidence disappear. The current site explains that distinction; it does not compute a live group's availability.
A response count needs a stated group and a stated question.
A total can be arithmetically right and still be misleading. In an invented exercise, four adult roles were asked to consider a discussion window, but only three marks are present. Saying three available leaves open whether the fourth adult is unavailable, conditional or unanswered. The input should support a summary that preserves the denominator: three of the four invited roles have marked available, and the remaining answer is missing. This is manual explanatory arithmetic, not a visitor-facing analytics feature.
Now suppose the organiser adds a fifth role because the discussion's purpose requires another adult. The original three marks remain three marks, but they concern a smaller invited group. The old summary should not be reused as though every necessary person had already been considered. The group boundary is part of the question, just like the duration. Changing it creates a new uncertainty even if the candidate time stays exactly the same.
The useful objection is that displaying every caveat can overwhelm a simple decision. Include the caveat that changes what the count establishes. One missing answer in a group of four matters; an unrelated history of every earlier meeting does not. The concise output names the candidate, the known states and the unanswered part. It leaves the coordinator with an interpretable result rather than a number that appears more complete than it is.
A static illustration should be readable without pretending to be a control.
The grid on the home page is a fixed illustration. Its labels and highlighted column explain the find-a-time idea, but clicking through the site does not change its marks. The long-form examples use prose instead of an interactive poll so the reader can inspect the assumptions and arithmetic directly. There is no hidden result saved by reading a section, and no input is requested to turn a sample column into the reader's own meeting.
A useful explanation should answer what went into the result and what the result means. In a three-choice example, that means distinguishing available, conditional and unavailable states, then naming any missing answer separately. In a booking example, it means separating the group's selected window from the resource action that must occur elsewhere. The reader can test the reasoning by changing a fictional premise on paper, without mistaking that thought exercise for a product operation.
These boundaries also make product questions more precise. A reader can ask about the meaning of a conditional answer or the point where a chosen time becomes a held booking. The current description may leave an implementation question unanswered; the page should preserve that unknown. It offers no promise that a visual design, an inquiry or a shared family name supplies the missing operation.
The booking connection is a separate, unbuilt part of Whenly.
The existing product description contrasts a group preference with a held booking. That is a useful distinction, but the connection is explicitly planned. The shared booking floor is described in the sibling Schedule page; the Whenly source does not independently verify that engine or establish a Whenly booking surface. This guide therefore makes no stronger backend claim. A favourable column in an example cannot reserve a room, consume capacity or prove that a competing reservation is impossible.
The same boundary applies to calendar handoff. The existing Whenly design describes a feed associated with a locked time, but this page supplies no subscription endpoint or calendar event. A written statement that the group prefers Tuesday does not establish that anyone's calendar contains Tuesday. If a coordinator records the choice elsewhere, that is an action through their established tool, separate from reading or discussing the Whenly design.
The useful stopping questions are concrete: has the group chosen a time, has the relevant resource actually been arranged, and has a final instruction been issued through an established process? Each answer needs its own basis. The page offers no account, live poll, resource lock or checkout to complete that chain. Understanding those limits helps a reader describe the specific gap in their current work without treating a family relationship or a polished illustration as an integration.