By the time a learner withdraws, the decision is usually weeks old. It is the end of a slow fade that began with one missed module, and the signals sit in the course platform for weeks before anyone reads them as a name. Course and cohort businesses run on two scarce things: whether learners keep turning up, and how much instructor attention there is to spend when they stop. Professional training operations run on a third — coordination, across trainers, dates, venues, client contacts and certification deadlines.
Priya, Marcus, the twelve-week March intake and the $1,800 payment plan are one illustrative cohort written to show how the mechanism would work — not a learner we have worked with, and not a completion or refund figure we have measured.
Week five, when the cohort splits in two.
It is Tuesday morning of week five in a twelve-week cohort. The dashboard says completion is at 62 percent, which tells you nothing about who. The community channel is busy — but the people posting in it are not the ones to worry about, because the learners who are leaving stopped posting a fortnight ago. Two weeks later a refund request arrives from a name you last read on the enrolment list, well after the window closed, which makes it a conversation rather than a form. Every signal that predicted it was sitting in the platform the entire time: the login that stopped, the assignment never opened, the two live sessions missed back to back. Nobody ignored it. Nobody was ever shown it.
Where value leaks
Where a cohort loses learners it could still keep.
From research into how a cohort actually runs. Which of these matters most depends on how the cohort is staffed.
01
Learners stop logging in weeks before they ask for a refund
Almost nobody sends a message saying they are dropping out. They miss one live session, fall a module behind, stop opening the weekly email, and then stay enrolled but inactive until the payment plan or the refund window forces the issue. Those signals are all recorded somewhere — last login, unsubmitted work, attendance on the call — but nothing pulls them together into a name an instructor can act on while the cohort is still running.
WEEK 3 OF 12 · NOT ON ANY LIST
LEARNER
Marcus T.
LAST ACTIVITY
At risk: 11 days ago
SUBMISSIONS
At risk: 1 of 4
REMAINING PLAN VALUE
Value: $1,800 across 4 instalments
REFUND WINDOW
Deadline: Closes in 4 days
OWNER
At risk: Whoever runs the refund report
02
Ninety learners, and the instructor can name four
The Thursday before week six, the instructor needs to know which twelve of ninety are at risk. The platform will tell her completion is 62 percent and that average watch time is fourteen minutes. To get names she exports three reports and cross-checks them in a spreadsheet, which takes most of a morning — so it happens in a quiet week and not in the week it would have changed anything. What she never sees at all is whether anyone is on track to pass the exam they enrolled for, or to do the job on Monday, which is the thing they actually bought.
03
The real timetable is a spreadsheet called v7-FINAL
In a professional training business the operating system is a shared file: trainers down one side, dates across the top, cohorts and venues colour-coded, one coordinator holding the version everyone else copies. It works until a trainer is double-booked, a client moves a delivery date, or the coordinator takes leave and nobody else can read the colours. Nothing in that file knows that fourteen learners have already been invited to Thursday’s session, or that the venue deposit has already gone out.
COHORT PLANNER · SHARED FILE
FILE
cohort-schedule-v7-FINAL.xlsx
TRAINER
At risk: Ravi — booked twice on 14 May
LEARNERS AFFECTED
At risk: 14 already invited
VENUE
Value: Deposit paid, non-refundable
LAST EDIT
At risk: Three people, same afternoon
OWNER
Owner: Whoever opens it first
04
One trainer calls in sick and fourteen people need telling
Every delivered session is a short chain of dependencies: a trainer, a room or a link, printed materials, a client’s staff released from their day job, sometimes an assessor. Break one link and somebody rebuilds the chain by phone — find a date all parties accept, tell fourteen learners, reissue joining instructions, move the invoice, and check the new date still clears the certification deadline. That work is unbudgeted, lands on whoever answers the phone first, and disappears from the record the moment it is done.
THURSDAY 08:40 · TRAINER UNAVAILABLE
SESSION
Compliance refresher — Group B
LEARNERS BOOKED
14
CERTIFICATION EXPIRES
Deadline: In 9 days
VENUE
Value: Booked and paid
CLIENT CONTACT
At risk: Not yet told
NEXT ACTION
Next action: Rebook, then renotify everyone
05
The third extension gets granted because checking is slower than saying yes
One learner exists as five records: an enrolment in the course platform, an attendee on the video calls, a customer in the payment system, a thread in the community channel, and a line on a coordinator’s list. So when that learner asks for a deadline extension, the instructor replying has none of it in front of them. The answer is either slow, while somebody goes looking, or generous by default — because saying yes takes ten seconds and finding out whether this is the third request takes twenty minutes.
06
The same four questions, in three inboxes, answered by the person you pay to teach
A cohort generates a steady stream of the same questions — where the recording is, whether the deadline moved, why the login fails, what counts toward the assessment. They arrive in the community channel, by direct message and by email at once, and instructors answer them because a learner waiting two days is a learner who stops opening the emails. The teaching hours the business actually sells get spent on questions the material already answers, and the one question that signals somebody is genuinely stuck looks identical to the rest in the inbox.
The workflow
A moved date, with and without an owner.
One timetable change traced twice: first passed along by hand, then handed to a system that knows who it affects.
Today
How it runs today
Trigger
A learner goes quiet
Priya — no login for eight days
Data
The signals sit in three separate tools
Logins, submissions, attendance
Rule
Nothing defines what drift looks like
Completion is 62%. No threshold, no names.
Human
The instructor answers whoever posts
The loud learners, not the leaving ones
Outcome
A refund request in week seven
Four weeks of drift, none of it recorded
With a system
How it would run with a system
Trigger
Activity falls behind the cohort’s pace
Priya — day three of silence
Data
Logins, submissions and attendance read as one learner
Not as one module
Rule
The drift threshold this cohort agreed
Two missed checkpoints in a row
Context
Her history arrives with her
Payment plan, prior questions, session notes
Human
The instructor chooses the response
Call, extension, or a place in the next cohort
Action
The message they approved goes out under their name
Nothing sends without them
Outcome
The choice is recorded against a name
In week five, whichever way it goes
Systems
What we would build around the cohort.
Each one handles a single mechanic of running a cohort. The instructor keeps the teaching and the marking.
These are systems we would build. Nothing on this page describes a delivered result.
Who Stopped Logging In
When a learner falls behind the pace their cohort is keeping, the system would assemble what the platform already holds about that learner and put a named person in front of an instructor while the course is still running.
Detects
Logins, submissions, live-session attendance and forum activity slowing against the cohort’s expected pace.
Assembles
One learner card: what they finished, what they missed, what they last asked, and what they still owe on their plan.
Human decides
The instructor decides whether this learner needs a call, an extension, a deferral, or nothing at all.
Intended outcome
Designed to put quiet learners on a weekly board as named, ranked and owned, in the week an instructor could still do something about it.
When a Date Moves
When a trainer, a venue or a client date moves, the system would rebuild the affected schedule, work out who is caught by the change, and route the exception to the coordinator who can resolve it.
Detects
Clashes between trainer availability, booked cohorts, venue capacity, invoicing and certification expiry dates.
Assembles
The affected sessions, the learners booked into them, the client contacts to notify, and the alternative dates that still clear the deadline.
Human decides
The coordinator approves the replacement date and decides who is told first — the client or the learners.
Intended outcome
Intended to turn a moved date into a worked queue with an owner, rather than a chain of phone calls nobody records.
One Page Per Learner
When anyone opens a learner or a client account, the system would present a single timeline drawn from the course platform, the live sessions, the payment record and the support inbox.
Detects
The same person held as separate records across enrolment, delivery, community and billing.
Assembles
One chronology: enrolment, attendance, submissions, questions asked, extensions granted, payments and previous cohorts.
Human decides
The instructor or account manager judges what that history means and what the learner is owed.
Intended outcome
The goal is that staff open the conversation already holding the learner’s history, and that a third extension request is visible as a third before anyone answers it.
Which Question Means Somebody Is Stuck
When a learner asks a question, the system would sort it, find where the course has already answered it, and prepare a reply for the instructor to approve, edit or replace.
Detects
Repeat questions, access and deadline problems, and the questions that read as somebody stuck rather than somebody curious.
Assembles
The relevant module material, prior answers to the same question, and the learner’s current position in the course.
Human decides
Nothing reaches a learner until the instructor has approved or rewritten it, and anything touching assessment stays with them.
Intended outcome
Intended to send routine repeats back to the material they came from, so teaching hours go to the questions that need a teacher.
Human control
Automate delay. Not judgement.
A system can
Reading logins, submissions and attendance together, per learner rather than per module
Ranking who has fallen furthest behind the cohort’s pace this week
Pulling a learner’s enrolment, attendance, questions and payment history onto one page before an instructor opens the conversation
Flagging a trainer booked twice, a venue clash, or a session with no room
Offering the coordinator three replacement dates that still clear the certification deadline
Finding where the course already answers a question, and putting that passage in front of the instructor
People still decide
Deciding whether a struggling learner gets an extension
Choosing when a phone call is the only honest response
Judging whether a learner should defer to a later cohort
Approving refunds, withdrawals and payment-plan changes
Awarding a grade, a pass, a fail or a certification
Deciding what a learner is told about their own progress
Confirming a rescheduled session with the client who paid for it
Deciding when the curriculum, not the learner, is the problem
It would tell an instructor that Priya has not logged in for eight days, and show them the two missed sessions and the unopened module sitting behind that. It would not decide whether she needs a phone call, a moved deadline or a place in the next cohort — and marking stays with the person who teaches the course.