Doors close on Friday, cohort starts Monday
Your six-week cohort course had a good launch. Doors closed on Friday night with a full cohort. Now you have a weekend to do the admin. You export buyers from the checkout into a spreadsheet, split them into accountability pods of six by time zone, add each person to the community space for this cohort, send calendar invites for twelve live sessions, and set up the welcome email with the pod details.
On Monday morning, three people email to say they have no invite. One is in the wrong pod because the time zone column was blank. Two late buyers who paid on Saturday under the grace period are not on the spreadsheet at all. Your assistant spends the first live call fixing access instead of watching the chat.
Why cohort launches are admin-heavy
An evergreen course is one product and one access rule. A cohort course is a product plus a date, a group, a schedule and a set of people who need to meet each other. Most course platforms handle the first part and leave the rest to you. So every launch involves the same manual steps, done under time pressure, from exported data that is already out of date.
- Buyers must be placed into the right cohort when more than one is on sale.
- Pods or small groups depend on time zone, experience or goals.
- Calendar invites have to go to every student for every live session.
- Community spaces are per cohort, and alumni need moving out later.
- Late buyers and deferrals arrive after the spreadsheet is built.
The cost of launch-week admin
Your time, at exactly the moment you should be preparing to teach. A first week that starts with missing invites and wrong groups sets the tone for the whole cohort, and students who feel lost in week one are the ones who drift away by week three. If you hire help for launch week, you pay for work that could run by itself.
Cohort onboarding that runs on purchase
- Each cohort is set up with its dates, live session schedule, community space and capacity.
- The checkout asks one or two questions you need for grouping, such as time zone or experience level.
- When someone buys, a service reads the payment and places them in the right cohort, and into a pod by your rules.
- Calendar invites for every live session go out from one shared calendar, so a change to a session updates everyone.
- The buyer is added to the cohort's space in Circle, Discord, Slack or your platform's community, through its API.
- The welcome sequence in your email tool starts with their cohort, pod and first session details filled in.
- Late buyers, deferrals to the next cohort and pod swaps are handled in the same place, with the changes flowing to every tool.
| Buyer situation | What happens automatically | Your job |
|---|---|---|
| Buys before doors close | Cohort, pod, invites, community, welcome | Nothing |
| Buys in the grace period | Same, joins the existing cohort | Nothing |
| No time zone given | Asked in the welcome email, placed when answered | Nothing |
| Wants to defer | Moved to the next cohort, access adjusted | Approve |
| Pod unhappy | Swap requested | Approve the swap |
Pod rules are yours. If you like to balance experience levels or put friends together, we write that into the rules, and you can always move people by hand.
Launch weekend, without the admin
When doors close, the cohort is already set up. Students arrive on Monday with invites, a pod and a welcome that tells them exactly what to do first. You and your assistant spend the first live call teaching and welcoming, not fixing access. When the cohort ends, students move to an alumni space on the date you set, and the next cohort starts clean.
Is launch week like this for you?
- You export buyers into a spreadsheet after every launch.
- Calendar invites are sent by hand.
- Pods are built manually, often over a weekend.
- Students start the course without an invite or community access.
- Late buyers and deferrals are handled by memory.