A paid cohort on WhatsApp looks like a chat. Underneath, it is a consistency problem. The checkout (or the LMS) already knows who may study until which date. The group only becomes trustworthy when membership is a projection of that record, not a list that someone edits when they have a spare minute.
This note is an engineering reading of that problem. It stays on three testable invariants. Product behaviour and the supporting workflow sit in 9bot's course-creator automation article. 9bot sells a paid subscription; you can evaluate it for seven days. It is not a Meta product and WhatsApp has not endorsed it.
I1. Every non-exception member can be traced to a live entitlement. If the person did not buy, did not renew, or already passed the end date, they should not remain in the room. Exceptions exist (company admins, a short allowlist), and they should be listed, not implied.
I2. Every shard of the same cohort carries the same controls. Ordinary WhatsApp groups accept at most 1,024 participants, a ceiling taken from the Help Center and confirmed on 28 Oct 2026. A larger intake is therefore several rooms, not a bigger room. Those rooms must share admission, welcome, commands, posting windows and the access clock. A single room set up in a hurry becomes the place where a scam link survives.
I3. Expiry is a job you can inspect, not a memory. Removal that depends on someone remembering the last day will fail on a busy week. The job needs a period, a prior notice, a defined exception list and a way to see that it ran.
If I1 drifts, a former buyer keeps seeing live-class links and everyone else's phone number. If I2 drifts, the cohort is no longer one product. If I3 drifts, both failures appear with a delay that looks like "the system is fine" until a complaint arrives.
Treat a purchase as a record with at least four fields: who, which offer, when access starts, when it ends. Membership in a shard is derived state. Refunds, chargebacks, complimentary extensions and transfers between intakes all mutate the record first. Only then should the group change.
Two clocks get confused in practice. "Access lasts 12 months from purchase" is not the same as "access lasts until 31 December." A pause granted by support is a change to the end date, not a silent skip of the removal job. Write the rule the way the offer was sold, then configure the same rule in the panel.
9bot's timed access control is the execution side of I3: after the period you set, the member is removed, a notice can go out beforehand, and admins plus numbers on the exception list are skipped. The panel repeats the expiry check on a five-minute cycle. That is frequent enough for a course operation, provided the period in the panel still matches the offer.
Splitting a cohort is a capacity decision and a blast-radius decision. Five rooms for a 5,000-buyer intake means five copies of the same controls. The useful question is not only "how many rooms do we need" (buyers divided by 1,024, rounded up). It is "what happens if room 4 was configured by hand."
Keep a cohort definition you can diff: the list of rooms, the access period, the welcome version, the command set, the posting calendar, the exception list, and which company number holds admin rights in every room. 9bot does not import that file. It is your manifest, used to review the panel. A WhatsApp Community, with one announcement space, can carry broadcasts while discussion stays inside each shard. Broadcasts still inherit the same risk: if the wrong people are still in a shard, they receive the announcement too.
Billing disputes, identity checks and exceptions belong to a person, in a private channel, not in the cohort. Custom commands such as .classes or .certificate can absorb logistics questions. If a command needs data from software you run, 9bot is able to fire an outbound HTTP GET, POST or PUT toward your checkout, the platform that hosts the lessons, or an orchestrator (n8n and Make are typical). Authenticate that endpoint, keep lookups on read-only routes, and do not print personal data back into a shared room.
Give the bot a company line that is an admin in every shard, kept apart from the handset the creator uses every day. Leave a second company admin in each room as well. A room that loses its last admin is no longer under the business.
Use the same report pack on every shard: people who interacted in the period, people who went silent for seven days, joins, exits, and net change, which 9bot can export as a PDF. Add two operational checks that the report will not invent for you: does every shard still have two company admins, and does the exception list still match the written policy.
| Invariant | Fast check | Typical repair |
|---|---|---|
| I1 | Sample members against the checkout end date | Remove or extend, then fix the period |
| I2 | Compare admission, welcome, commands and filters across shards | Re-apply the standard setup |
| I3 | Confirm last expiry cycle and the notice that precedes it | Correct the period and the exception list |
A failed check is an incident with an owner, not a note in a chat. The work of configuring 9bot is only useful if these three statements stay true after the next launch.