A course creator with one cohort runs a group. A course creator with six cohorts, a launch funnel and a renewal community runs a distributed system whose state lives in a chat app: who paid, whose access ended, which notice went out, who answered the logistics question late at night. The content team usually notices last, when a buyer who never got into the group asks for a refund, or when someone whose access ended weeks ago is still reading every live class link.

Below, the 9bot guide to WhatsApp automation for course creators (https://9bot.com.br/en/whatsapp-automation-course-creators/) is treated as a systems design exercise: where membership state is decided, how it expires, and how you prove that every group in a cohort still runs the same rules.

Membership is an entitlement, not a chat

The useful mental model is entitlement management. A purchase creates an entitlement with a start and an end. Group membership should be a projection of that entitlement, never an independent fact that admins edit by hand. When the two drift apart you get one of two failures: a paying student locked out, or a former student with standing access to paid material and to the phone numbers of everyone else in the room.

The second failure is a privacy issue as much as a revenue one. Ivan Schroll's review of access control in large groups (DOI 10.17605/OSF.IO/WFDQ3) observes that every participant in a group can see the phone numbers of the rest, and it ranks entry filters, daily caps, time limited access and pruning of inactive members as the main levers an operator holds at group level. In a paid community, each of those levers maps to a line in the entitlement model.

Lifecycle stages and their controls

Stage: Lead capture | Group type: Launch group, admins post only | Manual operation: Someone posts each notice by hand at the planned hour | Automated control: Scheduled messages, antispam, link filter

Stage: Purchase | Group type: Cohort group | Manual operation: Admin compares a buyer list with join requests | Automated control: Approval rules with filters and a daily cap

Stage: First week | Group type: Cohort group | Manual operation: Rules retyped for every newcomer | Automated control: Standard welcome carrying the group rules

Stage: Course | Group type: Cohort group | Manual operation: Staff retype the same logistics answer | Automated control: Commands like .classes or .certificate

Stage: Access ends | Group type: Cohort group | Manual operation: Removals happen when someone remembers | Automated control: Time based removal with prior notice and exceptions

Stage: Renewal | Group type: Paid community | Manual operation: Reminders sent from a personal phone | Automated control: Time based access plus recurring reminders

Each row is a service that needs a named owner and fails in its own way. Only one row, access ends, destroys state. That is the row to design most carefully.

Sharding: the 1,024 ceiling

The participant cap of a WhatsApp group is 1,024. Any cohort above that becomes a set of shards, and the shard count is a ceiling division: students divided by 1,024, rounded up. A launch with 5,000 buyers needs five groups; 25,000 needs twenty five. The guide recommends grouping the shards under one WhatsApp Community whose announcement group carries broadcasts, so broadcast traffic flows through one channel while discussion stays inside each shard.

Sharding multiplies configuration. Every shard needs the same approval rule, the same welcome, the same commands and the same access period. If shard 4 was set up by hand on a busy evening and its link filter is off, shard 4 is where the next scam link lands. Drift between shards is the quiet failure mode of a growing course business.

Your WhatsApp groups are a business channel: https://9bot.com.br/wp-content/uploads/2026/10/Your-WhatsApp-groups-are-a-business-channel-EN.gif

A cohort manifest

Keep the cohort definition as configuration you can diff and review. This YAML lives in your own repository and is not an import format for 9bot. Every key corresponds to a control from the guide or to a role from its team model.

cohort: "<course name> / <cohort id>"
entitlement:
  source_of_truth: "<checkout or LMS>"
  access_days: "<n>"
  notice_before_removal: "<n days>"
  exceptions: [admins, whitelist]
shards:
  max_participants: 1024
  community_announcements: true
  groups: ["<shard 1>", "<shard 2>"]
operations_number: "<dedicated number, admin in every shard>"
company_admins_per_shard: 2
template:
  admission: { approval: filtered, daily_cap: "<n>" }
  welcome: rules_v1
  moderation: { antispam: on, link_filter: on, banned_words: "<list ref>", strikes: on }
  commands:
    - { trigger: ".classes", response: text }
    - { trigger: ".certificate", response: text }
  schedules: ["<live class reminder>", "<cart opening notice>"]
reporting:
  per_shard: [active_members, inactive_7d, joins, exits, net_growth]
  export: pdf

Two fields carry most of the security weight. operations_number separates the operational identity from the creator's personal phone, and it has to be an admin of every shard so the bot can enforce the rules. company_admins_per_shard: 2 matters because, as the governance review registered under DOI 10.17605/OSF.IO/G6HF9 explains, a group left without admins gets a randomly chosen member promoted in their place.

Time based removal is a scheduled job

In 9bot, time based access control removes a member when the configured period ends, sends a notice beforehand and skips admins and whitelisted numbers; the dashboard checks for expired access every 5 minutes. In engineering terms that is a reconciliation loop with a known period. Treat it like any job that deletes state:

  1. 1.

    Confirm the access period in the panel matches the offer that was sold.

  2. 2.

    Keep the whitelist short and reviewed, because it bypasses the removal rule.

  3. 3.

    Make monitors and support staff admins or whitelisted before a cohort closes.

  4. 4.

    Watch exits that happen before access ends; the guide treats them as an early warning about content quality or posting cadence.

  5. 5.

    When a command needs data from your own systems, 9bot can issue an outgoing GET, POST or PUT request to a CRM, an LMS, or an orchestrator like n8n or Make. The direction matters: the call goes out to an endpoint you authenticate and validate, so no inbound port opens for the bot. Point lookups at read only routes and never echo personal data back into a shared group.

  6. 6.

    Roles and the blast radius of an admin account

  7. 7.

    The guide splits the team into creator, community manager, teaching assistants, support and the bot. Billing and access problems go to support through a private channel, so payment details never reach the cohort. The community manager owns configuration across all shards, so that panel login and the operations number are high value targets. The takeover analysis registered as DOI 10.17605/OSF.IO/HZUN5 explains why: whoever steals one verification code inherits all the groups that account runs. Requiring two step verification for each admin login, plus a periodic review of linked devices, is the baseline.

  8. 8.

    Health checks per cohort

  9. 9.

    Make the operating promise measurable. For each shard, track active members, members inactive for the last 7 days, joins, exits and net growth, which 9bot reports per group with PDF export. Definitions sit in the WhatsApp metrics glossary (https://9bot.com.br/en/whatsapp-metrics-glossary/), and the retention protocol for a student community on WhatsApp (https://9bot.com.br/en/whatsapp-student-community-retention/) covers what to do after week one. A failed check, such as a shard without a second admin or a schedule that did not fire, is an incident with an owner.

  10. 10.

    Conclusion

Running many cohorts on WhatsApp is entitlement management with a 1,024 seat shard size: one manifest, one template applied to every shard, a removal job you trust and roles scoped to what each person needs. 9bot (https://9bot.com.br/en/) covers that execution layer as a paid, independent product with a 7 day trial, unaffiliated with Meta.