Cohort.software · The whole series
One enrollment should mean the whole arc.
Cohort is planned around a group that begins and finishes together. This walkthrough uses a fictional adult workshop to explain the decisions behind that model. It is not a live booking tutorial: the recurrence, enrollment and continuity surfaces are not built on this site.
First, describe the commitment before drawing the calendar
Imagine an eight-week evening workshop for adults learning a professional skill. The facilitator starts with a cadence, a time zone, a start date and an end condition. They also need to say what the participant is joining. Eight dated meetings are not automatically one series: the program must actually treat them as a connected commitment. Cohort's planned input is that whole-series intent, plus enough calendar detail to show its occurrences. The desired output is a set of dates a person can inspect before deciding whether the arc fits.
Now ask a less tidy question: does eight weeks mean eight meetings or an eight-week span that includes a holiday? Those phrases can produce different expectations. The proposed recurrence layer should not hide that difference behind a short label. Review the actual intended dates in the exercise, including the finish, and write down the exception rule. If the facilitator cannot explain which dates belong to the commitment, opening enrollment would be premature. This page can help frame the question; it cannot expand or publish the rule for you.
Then decide who belongs to the series
The planned enrollment layer takes the series as its unit. A fictional participant joins the workshop once, with a place that is intended to continue across its occurrences. They should not have to compete for a new place every Tuesday just to complete the same course. In a walkthrough, the input is a decision to join the arc; the expected output is a clear association with that series and an understandable statement of the commitment. A calendar event alone would not answer whether the person belongs to the whole program.
Capacity belongs in this discussion, but a built capacity engine is not a built Cohort enrollment service. The site identifies the shared engine separately from the planned series layer. Do not treat a capacity number in an example as an available seat or a payable offer. If a program actually wants separate purchases for different nights, pause and compare that model with the single-session boundary on the apex. Repeated dates are not sufficient reason to force independently booked sessions into a continuing-roster product.
Change one occurrence without changing the meaning of enrollment
Suppose the room is unavailable in week four and the facilitator proposes a different evening. The intended change concerns an occurrence within the series. The continuity requirement is that existing enrollments still belong to the same arc after the date changes. In a design review, compare before and after: which date moved, what is now the final date, and which participants are still members of the series? This is the central Cohort question. The page describes planned behavior and does not execute the move or notify anyone.
A participant may still object because the new evening does not work for them. Keeping an enrollment intact does not settle their availability, agreement or program remedy. The facilitator needs a policy and a conversation for that case through the system already in use. Do not promise that roster continuity makes disruption disappear. Its narrower purpose is to avoid accidentally turning one calendar edit into a new intake. A useful walkthrough exposes both the scheduling change and the unresolved human decision instead of collapsing them into a reassuring success message.
Give the end of the series a real boundary
The planned lifecycle ends with completion and treats a next intake as a separate, opt-in step. That distinction matters for a group that has finished what it signed up for. A new series may have different dates, a different scope or a different price. In the example, the output at completion should make the end clear; it should not quietly extend the original commitment indefinitely. The next-intake idea belongs to the product plan, and this site does not roll a roster forward or invite participants.
Review a mid-series join alongside completion. A person entering in week three may need a different explanation of what remains, while the existing group should keep its continuity. That is a policy question as well as a scheduling question. Write the intended treatment down before discussing automation or billing. A successful evaluation is one in which the facilitator can explain the initial commitment, a changed date, a late join and the end without contradicting themselves. If that account remains unclear, the right next step is to refine the program model.
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.