A 2x2 triage for cohort students: group silence versus course progress

Teams that run paid cohorts in WhatsApp groups usually have two telemetry streams and use one. The group stream says who posted, who went quiet and who left. The course platform stream says who watched what and who is stuck on a module. Retention decisions made from either stream alone misfire in predictable ways. This note joins them into a small decision table that a tutor can work through once a week.

The operating guidance behind it is the 9bot guide on WhatsApp student community retention, which keeps one to one outreach with a human tutor and leaves scheduled group activity to configuration.

The two signals

Group silence. A member with no message in the cohort group over the last seven days. In 9bot this list comes from Reports, per group. It is cheap, available every week and noisy: plenty of students learn quietly.

Progress delta. Whether the student completed anything on the course platform over the same seven days. It is the closer proxy for learning, but it lives in a different system with a different identifier, usually an email address rather than a phone number.

The matrix

  • Posted in the group (Progress moved this week: Healthy. No action.; Progress stalled this week: Social but stuck. Content question is likely; route to tutor in the group thread.)

  • Silent in the group (Progress moved this week: Quiet learner. Do not interrupt.; Progress stalled this week: At risk. Group nudge first, then private tutor contact if still stalled.)

Two cells need nothing. One cell needs a content answer. Only one cell justifies a private message, and that is the message no bot should send.

Joining the streams

The join is the part that tends to go wrong:

  1. 1.

    Identifier mapping. Keep a mapping table between platform accounts and group phone numbers. It is personal data, so restrict who can read it and drop rows when the access period ends.

  2. 2.

    Aligned windows. Snapshot both sources on the same weekday. A seven day group window compared with a cumulative platform percentage produces false stalls.

  3. 3.

    Cohort scoping. Run the triage per cohort group, never across all groups at once, so a tutor only sees students they are responsible for.

A reviewable rule

{
  "rule": "weekly_cohort_triage",
  "schedule": "same weekday every week",
  "inputs": {
    "silent_7d": "group report, per cohort",
    "progress_delta_7d": "course platform export"
  },
  "cells": {
    "posted_and_moved": "none",
    "silent_and_moved": "none",
    "posted_and_stalled": "tutor_answers_in_group",
    "silent_and_stalled": ["group_nudge_easy_milestone", "tutor_private_contact_if_unchanged"]
  },
  "never_automated": ["tutor_private_contact"]
}

The never_automated key is deliberate. It records in the rule file itself that the private step stays human, which makes the boundary visible in review.

Before the access window closes

Students who stay in the at risk cell near the end of the access period are the ones who most need the pre removal notice. A time based access control that warns before removal gives them a last route to an extension or renewal.

Caveat

The research usually cited for student groups (Frontiers in Education, 2024) links reciprocity and satisfaction to intention to continue. It does not show that a triage like this raises completion. Compare cohorts that use it with cohorts that do not, using completion from the course platform.

Disclosure: 9bot is a commercial subscription with a 7 day trial. Meta does not own, run or endorse it.