About · Whenly.software
The useful ending is a time people understand.
Whenly is the find-a-time lane in the scheduling family: the group has a reason to meet, but the shared time is unresolved. Its existing product description is candid about the stage: no Whenly poll or booking surface is running. This site explains the problem, the design and the distinctions a coordinator needs to keep visible. It does not turn reading those explanations into access to a product.
The organiser is reconciling answers, not merely collecting them.
A reply-all exchange often contains the raw information needed to choose a time, but its answers refer to different versions of the question. One person answers the first suggestion, another proposes a shorter meeting, and a third says that the afternoon works without naming which afternoon. The hard part is not the existence of messages. It is identifying which answers describe the same activity and which unanswered point prevents a decision.
Whenly's design starts from that reconciliation problem. The coordinator proposes a bounded set of candidates; the group answers using stated response choices; the overlap makes the counts legible. That is a description of the intended mechanism. Its value is easiest to assess with a particular situation, such as four adults comparing three equal-length discussion windows. A general claim that scheduling becomes effortless says much less than a worked explanation of what the coordinator can infer from those marks.
The brand is deliberately group-first. An individual choosing a slot from a host's published availability has a different task, even if both tasks end with something written on a calendar. Whenly's question comes earlier: which one of these times can this group use? A clear product boundary makes the surrounding family easier to understand without claiming every named sibling is live or connected.
A family relationship is context, not a deployment certificate.
The existing page identifies Whenly as a Stanley Studios product and describes the shared scheduling floor through the sibling Schedule page. It also states an unusually important limitation: that shared-floor description is grounded in sibling copy, not an independent verification inside the Whenly renderer. The new pages retain that qualification. They do not use a family's common vocabulary to claim that a Whenly poll, overlap calculation or booking endpoint is available.
This matters because a marketing front door can be reachable while the product it discusses is closed. A reader can navigate a complete site, inspect a worked example and find contact information without being able to create a poll. Those are real improvements to the explanatory site, but they are not a deployment of the operational design. The distinction belongs in ordinary prose, where a coordinator deciding how to organise a meeting can actually see it.
Does that make the site less useful? It makes its present use specific. A reader can examine whether the group-availability problem matches their own work, identify a missing dependency and prepare a clearer question. The site should not ask that reader to tell a committee a meeting is handled merely because the design sounds suitable. A good account of the product's stage is part of explaining the product itself.
Worked examples should leave their assumptions on the page.
Every new worked situation uses invented adult roles and fictional availability. No participant is asked to supply an answer to the page. The examples describe what a coordinator can write or infer manually from the stated inputs. Their purpose is to expose differences that are easy to lose in a compact grid: conditional versus available, missing versus unavailable, a group decision versus a resource hold. None is an operational demonstration or evidence of customer use.
The assumption that a meeting lasts thirty minutes is part of an example, not a universal scheduling rule. If the duration changes, the old answers may no longer answer the current question. If another adult joins the discussion, the original count does not magically describe the larger group. Showing those limitations gives a reader something practical to reuse: the habit of asking whether the result still corresponds to the question that produced it.
A reader does not need to copy the sample wording exactly. They can use the distinctions to improve their own established process. The strongest output may be a short note explaining one unresolved condition. That is more useful than a long summary that quietly changes a proposal into a confirmation. The examples are complete enough to inspect, and limited enough not to imply hidden features behind them.
Judge the explanation by the distinction it helps you make.
A polished example is persuasive because its assumptions can be made unusually tidy. Every person answers, every candidate has the same length and the most convenient column is highlighted. That can explain the basic idea, but it should not hide the ordinary cases that make coordination difficult. The additional pages deliberately include an unanswered role, a conditional reply, a changed duration and a separate resource dependency. Those are questions a coordinator can recognise without a fabricated success story.
The examples establish only their own reasoning. A fictional count of three available answers is not an adoption statistic, an attendance result or proof that a product improved an organisation's work. The site makes no customer claim through those invented cases. Their value is that a reader can check whether the written conclusion follows from the written inputs. If an example calls a missing answer agreement, the error is visible without any access to a live system.
A useful product explanation should also distinguish a concept from an acceptance decision. A coordinator may decide that the group-first problem is relevant while still needing a working operational tool. Reading this site can support the first judgment; it does not provide the second outcome. That is why a contact conversation should begin with the task and its unresolved point, rather than with an assumption that a described surface is ready for the reader's next meeting.
Keep the family connection useful and the product boundary specific.
Scheduling covers several jobs that often appear together in one organisation. A group may first find a common time, then arrange a room, then communicate the final window. The family context helps identify those different needs. It does not justify treating a description of one job as evidence that every other job is connected, deployed or available to the visitor. The links in the footer are routes to related explanations, with no operational promise attached.
Whenly's own contribution to that conversation is a clear account of the group-availability decision. Its page menu separates the worked flow, situations, mechanism and background from practical getting-started and help material. A reader can move to the section that matches their question and retain the same product boundary. More pages improve the explanation; they do not change the build state named by the underlying source.
The result should be a reader who can describe the problem in ordinary words: we need one time for this group; these answers are conditional; that role has not answered; the room is a separate dependency. Those statements are useful even before a tool enters the conversation. They also make it harder to confuse an appealing grid with a completed arrangement. That is the standard this site applies to its own examples.
Describe the decision you need, and the point where your process stops.
An inquiry can begin with the shape of the task: an adult group needs one discussion window, several candidates are plausible, and the organiser repeatedly loses track of which answers refer to which option. Add the constraint that changes the decision, such as a fixed duration or a separate room arrangement. A participant list, a calendar export or a collection of personal explanations is unnecessary for that initial description. The contact page helps keep the inquiry bounded.
The question can also be about what the design does not settle. For example, does the concept assume every invited adult answers, or how should a coordinator describe a conditional preference before a resource is arranged? Asking that question does not mean the corresponding feature exists. The current site provides no self-serve signup, poll creation, booking action or purchasable plan, and an inquiry does not complete those steps.
Whenly's own voice is the coordinator trying to bring a scheduling exchange to a clear, accurate ending. That ending may be an agreed time, a named missing answer or a decision to ask a better question. The site can explain each of those outcomes without pretending it has produced them for a live group. The nine-page navigation makes the explanation easier to follow; the limits remain visible across it.