Cohort.software · The whole series
A group signs up for a journey, not eight unrelated Tuesdays.
Cohort.software is the planned recurring-series enrollment product in the scheduling family. Its purpose is specific: keep the meaning of a whole-series commitment clear while ordinary calendar changes happen. The examples on these pages are fictional adult programs, and the series-specific surface is not live.
The unit changes what a calendar edit means
An adult learning group often joins because the meetings build on one another. Week one introduces a practice, week two develops it, and the group reaches an end together. If the only stored idea is a booking for one date, a moved meeting can make the organizer reconstruct the continuity by hand. Cohort's product plan starts from a different unit: the series has an identity, the roster belongs to it, and the dates express when its occurrences happen. That is the organizing idea behind the planned enrollment layer.
This does not make every repeated event a cohort. A studio may offer the same session each week while allowing people to choose individual dates. In that case, the separate session may be exactly the right unit. The distinction is about the commitment, not the calendar's appearance. Cohort is intended for the whole arc; the classly sibling is described around a seat in one dated session. Neither a similar name nor a related link establishes that a sibling product is live or that an account exists across both.
The ordinary exception is the real design test
A holiday, an unavailable room or a facilitator's necessary date change is not an exotic edge case for a multiweek program. It is an ordinary part of running one. The product plan should therefore explain what happens to the existing group when an occurrence moves. The intended continuity is narrow and useful: the person's enrollment remains associated with the series instead of being reconstructed from individual replacement bookings. The person may still need to discuss the revised date; keeping membership does not settle every practical consequence.
That is why these pages spend time on exceptions instead of promising that a calendar makes coordination disappear. A program has policies, people have constraints, and a late join can change what someone receives. Software needs an understandable account of those decisions. In a conversation, we would rather hear one awkward week in detail than a long list of desired features. A fictional scenario is enough to reveal where the planned model helps and where the program needs a different approach. No live roster is required.
The product idea and the shipping status belong on the same page
The apex names capacity-N as a shared built engine mode and labels recurrence expansion, series enrollment and roster continuity as planned. That separation matters because a credible component can make an unfinished product sound further along than it is. These guides keep the planned qualification close to the behaviors they discuss. A reader should be able to understand the product's intended value without mistaking an explanation for an available tool. This site has no live checkout, and its pricing is display-only rather than a billable offer.
The same discipline applies to an early-access conversation. It can clarify fit, surface a missing requirement or lead to a decision to wait. It does not provision a tenant, hold a seat or create a subscription. If a future discussion needs real operational records or a deployment, that is a separate scope to establish with actual evidence. The current pages cannot stand in for it. The purpose of the detailed examples is to make that later evaluation more precise, not to imply it has already happened.
A small promise is easier to evaluate honestly
Cohort's focus is recurring-series enrollment and fixed-roster continuity. Institutional K-12 timetabling, one-to-one appointments and field dispatch sit outside this scope. A program may have adjacent needs, but sharing a calendar vocabulary does not make them one workflow. The related-product footer is a way to read those products' own explanations. It is not an integration map, a deployment statement or a promise that an enrollment will travel between them. Keep the actual problem in view when comparing the planned series model with another tool.
For a facilitator, the useful next step is to describe a single adult series, its membership rule and one change that is hard to manage today. For a participant, the useful question is what the original commitment includes and how a revised date would be explained. For a buyer, the useful test is whether the planned feature answers both sides without concealing an unresolved policy. If it does not, say so. A well-defined mismatch is more valuable than an early-access conversation that mistakes polite interest for a working fit.
A useful design can still be an unfinished product
The recurrence rule, series enrollment and roster continuity described here are planned. The shared capacity-N engine is a narrower built component; it does not establish that a facilitator can publish a Cohort series, accept an enrollment or change an occurrence through this website. There is no live checkout and no card is charged here. Examples describe decisions a future product must make legible, not records being created in the background. A polished explanation should make that boundary easier to see, not harder.
For an evaluation, keep your existing calendar and enrollment process in charge. Choose one fictional adult series and work through what a facilitator and participant would need to understand at each step. If the proposed behavior does not fit, that is a useful result. A conversation is not an enrollment, a displayed price is not a bill, and a related product link is not evidence of an integration. Read the help guide for the existing capability ledger and the starting guide for the scope of a conversation today.