Attendance and Progress Alerts

Students almost never announce that they are giving up. They miss one session with a good reason, miss a second one quietly, stop opening the course, and then four weeks later the provider finds out through a refund request, a funding clawback, a sponsor complaint, or an empty seat at the final assessment. By then the window for a cheap intervention has closed. The information that would have predicted it was sitting in three different places the whole time: the attendance register the tutor keeps, the course login and lesson data, and the assignment submission list.

Nobody owns the join. Tutors see their own cohort but not the pattern across courses. Admin sees enrollments and invoices but not whether anyone is actually learning. A progress bar cannot tell you that a student is fourteen points behind where the cohort sits at week five, has not logged in for nine days, and has two assignments overdue. Those three facts together are a near-certain withdrawal. Separately they are invisible.

The leak is on both sides of the ledger. Revenue goes out as refunds, part-paid plans that stop paying, and renewals that never come. Revenue that never arrives is the bigger half: sponsors and employers who do not send a second cohort, outcome-based or completion-linked funding that is withheld, accreditation and awarding-body reviews that go badly, and the referral flow from graduates you never produced. Every one of those is downstream of the same operational gap, which is that no system was watching between the weekly class and the final grade.

Pipeline and stages

One pipeline, Student Success, with every active learner on it for the full life of their enrollment. This is a retention board, not a sales board.

• Enrolled - paid or funded, course not yet started.
• Week One - first session attended, first login landed.
• On Track - risk band green. The resting state for most of the cohort.
• Watch - risk band amber. Automated nudges running, no human assigned yet.
• At Risk - risk band red. An advisor task exists and is counting down.
• Intervention Booked - a success check-in or tutor catch-up is on the calendar.
• Plan In Place - barriers identified, catch-up plan agreed, watching for compliance.
• Recovered - back to green and held there for 30 days.
• Withdrawal Intent - the student has said they want out. Save play running.
• Withdrawn - closed lost, with a reason captured.
• Completed - closed won. Feeds the alumni upsell build.

Calendars

• Success Check-in - 15 min - round robin across the student success advisors, 3 slots per advisor per day, 2 hour minimum notice, no same-day after 3pm.
• Tutor Catch-up - 30 min - routed to the tutor named in tutor_assigned, academic content only.
• Withdrawal Save Call - 20 min - a short, deliberately easy-to-book calendar held by the program lead only.
• Guardian or Sponsor Call - 20 min - used when a third party has to be in the conversation.

Custom fields

Group these on the contact record so an advisor can read a student in one screen.

• Enrollment: cohort_name, cohort_start_date, cohort_week_number, course_code, enrollment_date, expected_end_date, funding_source, tutor_assigned, advisor_assigned.
• Attendance: sessions_scheduled_to_date, sessions_attended_total, attendance_rate_percent, sessions_missed_consecutive, last_attendance_date, last_absence_reason.
• Progress: last_login_date, days_since_login, lessons_completed_count, lessons_total_count, progress_percent, progress_expected_percent, progress_gap_points, assignments_overdue_count, next_assessment_date.
• Risk: risk_score, risk_band, risk_reason, risk_band_changed_date, intervention_count, last_intervention_date, barrier_primary, catch_up_plan_agreed, plan_review_date, save_call_outcome.
• Third parties: guardian_name, guardian_email, guardian_phone, guardian_contact_permitted, sponsor_company, sponsor_contact_email, sponsor_reporting_permitted.

Tags

• State: student-active, cohort-[course_code], risk-green, risk-amber, risk-red.
• Signals: missed-1, missed-2, missed-3plus, stalled-7d, stalled-14d, assignment-overdue, behind-pace.
• Process: intervention-open, plan-active, recovered-30d, save-play-running, guardian-contactable, sponsor-reportable.
• Suppression: sms-opt-out, email-opt-out, comms-paused, authorized-absence, on-break.

Forms and surveys

• Attendance Exception Form - tutor-facing, one submission per absent student per session. Captures student, session date, absent or late, reason, and whether the absence is authorized. This is the fallback when no register integration exists.
• Barrier Check - four questions sent to amber students: what is getting in the way (time, money, confidence, health, tech, work, caring, other), how confident are you that you will finish on a one to five scale, what one thing would help most, and the best time to reach you. Writes barrier_primary.
• Catch-up Plan - advisor-facing, filled during the check-in. Agreed sessions, agreed deadlines, review date. Sets catch_up_plan_agreed and plan_review_date.
• Withdrawal Intent Form - reason, whether a deferral would work instead, and consent to one save call.

BO and the guardrails

BO handles the conversational layer on inbound replies to any alert, in SMS, email and web chat.

• BO may: acknowledge an absence, log a stated reason into last_absence_reason, offer the Success Check-in and Tutor Catch-up calendars, answer logistics questions about timetable, room, platform access and deadline dates, send a password reset path, and apply authorized-absence when the student states a reason on the approved list.
• BO may not: discuss grades, give academic feedback, agree an extension or a deferral, discuss fees, payment plans or refunds, or accept a withdrawal. Each of those routes to a human and pauses the nudge sequence.
• BO must escalate immediately, silently stop all automated sequences, and raise a priority task to the program lead if a reply mentions health, bereavement, safeguarding, harassment, financial hardship or anything suggesting risk to the student. This is a hard rule, not a scored judgment.
• BO never writes risk_score or risk_band. Only the nightly recalculation workflow writes those.
• Tone: short, warm, plain, no exclamation marks, never implies the student is in trouble, always names a specific next action.

Numbers and channels

• One dedicated local number for student success, separate from the admissions number, so attendance alerts never land in a sales thread.
• Email from a monitored student support address with replies threaded into the contact conversation.
• Quiet hours enforced platform-wide: nothing outbound before 8am or after 8pm in the student timezone field, nothing on a cohort rest day.
• Guardian and sponsor messages go out on a separate sender identity and are never mixed into the student thread.
• In-app or portal announcement as a fourth channel for stalled students who have stopped opening email.

One student, week one to recovery.

1. Enrollment lands. Priya pays for the twelve-week evening program. The enrollment workflow creates her contact, tags student-active and cohort-DIG12, writes cohort_start_date, expected_end_date, tutor_assigned and advisor_assigned, and drops an opportunity into Enrolled.
2. Week one lands clean. She attends session one and logs in the same evening. The nightly recalculation sets progress_percent to 8, progress_expected_percent to 8, risk_score to 0, risk_band to green, and moves her to On Track. No message is sent, which is the point: green students are left alone.
3. She misses session four. The tutor files an Attendance Exception Form marking her absent, unauthorised. sessions_missed_consecutive becomes 1, tag missed-1 applies, and ninety minutes after the session ends she gets one SMS asking if everything is alright and offering the recording link.
4. She replies. BO reads the reply, logs the reason into last_absence_reason, confirms the recording link, and asks nothing else. No stage change. The ladder resets if she attends session five.
5. She misses session five too. sessions_missed_consecutive hits 2, missed-2 applies. The nightly job adds the absence weight to risk_score, which crosses into amber. She moves to Watch and the Barrier Check goes out by email with an SMS pointer.
6. Progress stalls as well. Six days with no login pushes days_since_login to 6, then 7, which applies stalled-7d. The stall watch sends a single-lesson nudge naming the exact next lesson she has left unfinished, not a generic come-back-to-the-course message.
7. An assignment goes overdue. assignments_overdue_count becomes 1 and assignment-overdue applies. The chase sequence starts and the tutor is notified in their own daily digest rather than individually pinged.
8. Risk crosses red. Three signals together put risk_score above the red threshold. risk_reason is written as a readable string: two consecutive absences, seven days no login, one assignment overdue, eleven points behind pace. She moves to At Risk, risk-red and intervention-open apply, and a task lands on her advisor with a four-hour due time.
9. The human call happens. The advisor calls and texts the Success Check-in link. Priya books a slot for the next afternoon, which moves her to Intervention Booked and pauses every automated nudge sequence so she is not being chased while a meeting is in the calendar.
10. Barriers get named. On the call it turns out she changed shift pattern and can no longer make Tuesdays. barrier_primary is set to work. The advisor fills the Catch-up Plan form: switch to the Thursday group, two recorded sessions to watch by Sunday, the overdue assignment due in nine days. catch_up_plan_agreed is yes and plan_review_date is set seven days out.
11. She moves to Plan In Place. plan-active applies. Nudges stay off except the plan reminders, which fire two days before plan_review_date and reference the exact commitments she made.
12. The plan is reviewed. On the review date the nightly job checks whether attendance resumed, days_since_login dropped below 3, and assignments_overdue_count returned to 0. All three are true, so risk_score falls back to green and she moves to Recovered with recovered-30d applied.
13. She is watched, quietly, for a month. If any signal reappears inside the 30 days she goes straight back to At Risk and skips the amber tier entirely, because a second slide is a stronger signal than a first one. If nothing reappears, the tag drops and she returns to On Track.
14. She completes. At course end the opportunity moves to Completed, the success fields are frozen as a record, and she is tagged for the alumni and advanced course upsell sequence. Her sponsor gets a final completion summary because sponsor_reporting_permitted is yes.

Eight workflows. The first one is the engine; the rest react to what it writes. Build them in this order.

1. Nightly Risk Recalculation

Trigger: scheduled, every day at 03:00 platform time, over every contact tagged student-active and not tagged on-break.

Steps in order:

1. Refresh the source fields: last_attendance_date, sessions_missed_consecutive, attendance_rate_percent, last_login_date, lessons_completed_count, assignments_overdue_count.
2. Compute days_since_login as today minus last_login_date.
3. Compute progress_percent as lessons_completed_count divided by lessons_total_count, and progress_expected_percent from the agreed pace curve for course_code at cohort_week_number. Write progress_gap_points as expected minus actual.
4. Score, additively: consecutive absences 0 points for none, 10 for one, 25 for two, 40 for three or more. Days since login 0 under 4, 10 at 4 to 6, 20 at 7 to 13, 35 at 14 or more. Assignments overdue 15 per assignment, capped at 30. Progress gap 0 under 5 points, 10 at 5 to 9, 20 at 10 to 19, 30 at 20 or more. Failed payment on an active plan, 15. Prior intervention inside 30 days, 10.
5. Write risk_score, then risk_band: green under 25, amber 25 to 49, red 50 or above.
6. Write risk_reason as a plain readable sentence listing only the contributing signals, so an advisor never has to decode a number.
7. If the band changed, write risk_band_changed_date, swap the risk-green, risk-amber, risk-red tags, and move the opportunity to On Track, Watch or At Risk to match.

Branches: if the contact is in Intervention Booked, Plan In Place or Withdrawal Intent, update the fields but do not change the stage. Human-owned stages are never overwritten by the scheduler. If recovered-30d is present and the band moves off green, jump straight to At Risk regardless of score.

Stop conditions: contact not tagged student-active, or stage is Withdrawn or Completed. No message is ever sent by this workflow; it only writes data.

2. Consecutive Absence Ladder

Trigger: Attendance Exception Form submitted, or an absence record arriving from the register integration.

Conditions: exit immediately if the absence is marked authorized, or the contact carries comms-paused, on-break or save-play-running.

Steps:

1. Increment sessions_missed_consecutive and write last_absence_reason if one was given.
2. Branch on the new count.
3. Count is 1: wait 90 minutes after session end, then one SMS. "Hi [first name], we missed you at tonight's [course name] session. Nothing to worry about, just checking in. Here's the recording: [link]. Reply here if anything's getting in the way." Apply missed-1. End.
4. Count is 2: wait 2 hours, then SMS. "Hi [first name], that's two sessions now and we'd rather sort it than let it slide. Two minutes to tell us what's going on: [Barrier Check link]. Or reply here and we'll call you." Wait 24 hours. If the Barrier Check is still not submitted, send the email version with the subject "Two sessions missed - what would help?". Apply missed-2. End.
5. Count is 3 or more: no automated message. Apply missed-3plus, create a priority task for advisor_assigned due in 4 hours titled "Three absences - call [first name] today", and notify the advisor in internal chat. Three absences is a phone call, not a text.

Reset: any attendance record resets sessions_missed_consecutive to 0 and removes all three missed- tags.

Stop conditions: sms-opt-out suppresses the SMS leg but the task leg still runs. Any inbound reply hands the thread to BO and pauses the next scheduled step in this workflow only.

3. Progress Stall Watch

Trigger: days_since_login field changes, evaluated after the nightly job.

Conditions: only for students past week one, stage in On Track or Watch, not tagged plan-active.

Steps:

1. At 7 days: apply stalled-7d. Send email naming the specific next incomplete lesson. Subject: "Your next lesson is waiting: [lesson name]". Body opens with one line, gives one button to that exact lesson, and closes with "If something's blocking you, reply to this email - a person reads it."
2. Wait 48 hours. If days_since_login is still 7 or more, send SMS: "Hi [first name], you're [progress_percent] percent through [course name] and the next bit is a short one. Pick it up here: [deep link]". A deep link to one lesson converts far better than a portal login link.
3. Wait 5 days. If still stalled, apply stalled-14d, remove the automated leg, and create a task for advisor_assigned: "Fourteen days no login - call".
4. Post a portal or in-app announcement at the 14-day mark for students tagged email-opt-out.

Stop conditions: any login removes both stall tags and exits the workflow. Stage moving to Intervention Booked, Plan In Place or Withdrawal Intent exits immediately.

4. Assignment Overdue Chase

Trigger: assignments_overdue_count increases above 0.

Steps:

1. Apply assignment-overdue.
2. Day 1 after the deadline, email: "[Assignment name] was due yesterday". One paragraph, the submission link, the late policy in one line, and "Need more time? Reply and ask - that's always better than silence."
3. Wait 3 days. If still overdue, SMS: "Hi [first name], [assignment name] is still outstanding. Submit here: [link], or reply EXTEND and we'll talk about a new date."
4. Wait 4 days. If still overdue, add the student to the tutor's daily digest (workflow 8) rather than sending a third chase. Two chases is the limit.
5. If assignments_overdue_count reaches 2, create an advisor task immediately and stop all further automated chasing. Two overdue assignments is a conversation.

Branches: a reply containing EXTEND, extension or more time routes to the tutor as a task and pauses the sequence. BO does not grant extensions.

Stop conditions: submission detected, or count returns to 0, which removes the tag.

5. Red Band Intervention

Trigger: risk_band changes to red.

Steps:

1. Apply risk-red and intervention-open, move the opportunity to At Risk, increment intervention_count, write last_intervention_date.
2. Create a task for advisor_assigned due in 4 working hours, titled "At risk: [first name] - [risk_reason]", with the reason string in the body so no lookup is needed.
3. Notify the advisor and the program lead in internal chat with name, cohort, score and reason.
4. Wait 2 hours, then send the student one SMS: "Hi [first name], it's [advisor first name] from [provider]. I'd like 15 minutes to help you get back on track - no lecture, I promise. Grab a slot that suits: [Success Check-in link]". Sending from a named human, not the brand, roughly doubles booking rates in practice. Measure it.
5. Wait 24 hours. If no booking and the task is still open, send the email version with the same offer plus two alternative times and the advisor's direct number.
6. Wait 48 hours. If still no booking, escalate: reassign the task to the program lead and, where guardian_contact_permitted or sponsor_reporting_permitted is yes, hand off to workflow 6.

Stop conditions: a booking on the Success Check-in or Tutor Catch-up calendar moves the stage to Intervention Booked, applies nothing further, and pauses workflows 2, 3 and 4 outright. Band returning to green or amber closes the task with a note.

6. Guardian and Sponsor Notification

Trigger: handed off from workflow 5 at the 48-hour escalation, or sessions_missed_consecutive reaching 3.

Conditions: hard gate. Runs only if guardian_contact_permitted is yes with a valid guardian_email, or sponsor_reporting_permitted is yes with a valid sponsor_contact_email. No permission, no message, no exceptions and no fallback to the student's own contact details.

Steps:

1. Branch by recipient type.
2. Guardian: email from the support identity. "We wanted to let you know [student first name] has missed [n] sessions of [course name] and we haven't been able to reach them. We'd like to help. You can book a short call here: [Guardian or Sponsor Call link]." Attendance and progress facts only. No reasons, no disclosures, no grades.
3. Sponsor: email with the agreed reporting fields only - attendance rate, progress percent, sessions missed - plus the booking link. Never the barrier, never the absence reason.
4. Wait 3 working days. If no response and no booking, create a task for the program lead to call.
5. Log every third-party message against the contact so the disclosure trail exists.

Stop conditions: student books their own check-in, band returns to green, or permission flag flips to no, which stops everything mid-sequence.

7. Plan Compliance and Recovery Close-out

Trigger: Catch-up Plan form submitted.

Steps:

1. Set catch_up_plan_agreed to yes, write plan_review_date, apply plan-active, move to Plan In Place, and suppress workflows 2, 3 and 4 for this contact.
2. Immediately send the student a plain summary of exactly what they agreed, in their own words where possible. "Here's what we agreed: [commitment 1], [commitment 2], by [date]. I'll check in on [plan_review_date]." Written commitments get kept far more often than spoken ones.
3. Wait until 2 days before plan_review_date, then SMS: "Hi [first name], checking in ahead of [date] - how are you doing with [commitment 1]?"
4. On plan_review_date, evaluate: attendance resumed, days_since_login under 4, assignments_overdue_count at 0.
5. All met: move to Recovered, apply recovered-30d, remove plan-active and intervention-open, close the advisor task, and send "You're back on track - nice work." Nothing else.
6. Partly met: extend plan_review_date by 7 days once and task the advisor to reconfirm. One extension only.
7. Not met: remove plan-active, return to At Risk, and task the program lead rather than the advisor. The second failure needs a different person.
8. At 30 days after Recovered, remove recovered-30d and move to On Track.

Stop conditions: Withdrawal Intent stage, or Withdrawn.

8. Withdrawal Save Play and Tutor Digest

Trigger A: Withdrawal Intent Form submitted, or BO detects withdrawal language in any inbound message.

Steps:

1. Immediately stop every other workflow for this contact, apply save-play-running and comms-paused, move to Withdrawal Intent. Nothing automated is allowed to talk over a withdrawal.
2. Create an urgent task for the program lead due in 2 working hours.
3. Wait 30 minutes, then one SMS from the program lead's name: "Hi [first name], I got your message. Before we process anything I'd like 20 minutes to understand what happened and talk you through the options, including deferring to a later cohort. [Withdrawal Save Call link]"
4. If the call happens, the lead writes save_call_outcome as retained, deferred, withdrawn or no contact.
5. Deferred: apply on-break, set a reactivation date, and schedule a single re-engagement message 14 days before the next cohort starts.
6. Withdrawn: move to Withdrawn, record the reason, remove student-active, and send one email confirming the process and what access they keep.
7. Wait 60 days after Withdrawn, then one re-enrollment invitation referencing the specific cohort that would suit them. One message, not a sequence.

Trigger B: scheduled daily at 07:30, one digest email per tutor.

Steps: list their students at amber or red with name, score, reason and current stage, plus anyone with two chases unanswered. One email, ranked by score, no individual pings during the day. Include a one-line count of the cohort's green students so the digest reads as a health report rather than a problem list.

Stop conditions for the digest: skip send entirely if the tutor has no amber or red students. An empty digest teaches people to stop opening it.

What is different afterwards

• Risk is a number, not a feeling. Every active student carries a score and a readable reason, recalculated nightly, so a conversation about who is in trouble takes thirty seconds instead of an hour of cross-checking registers.
• The gap between the first missed session and the first human contact collapses from weeks to hours, and the first contact is cheap automation rather than expensive staff time.
• Advisors stop spending their day finding problems and spend it solving them. The system hands them a short, ranked list with the reason already attached.
• Tutors file one short exception form instead of being chased for registers, and receive one daily digest instead of scattered pings.
• Green students are left in peace. This matters more than it sounds: blanket chase sequences train the whole cohort to ignore your messages, which is what makes the real alerts invisible.
• Sponsors, employers and funders receive progress reporting on a schedule instead of on request, which changes the renewal conversation before it starts.
• Withdrawals that do happen arrive with a captured reason, so the pattern across a year becomes a curriculum and timetabling input rather than a mystery.

Metrics to watch

• Completion rate by cohort - the headline number. Compare cohorts before and after launch, and compare like-for-like intakes rather than across seasons.
• Withdrawal rate and week-of-withdrawal distribution - a working system should push withdrawals earlier (caught fast, deferred cleanly) and reduce the late ones.
• Time from first red signal to first human contact - the core operational metric. Measure the median, not the average.
• Amber-to-green recovery rate - what share of students who hit amber return to green without ever reaching red. This is the test of whether the automated tier works.
• Red-to-green recovery rate - the test of whether the human tier works.
• Intervention booking rate - share of red students who actually book a check-in. If this is low, the message copy or the calendar friction is the problem, not the student.
• Barrier distribution - the ranked count of barrier_primary values. If work schedule dominates, the fix is timetabling, not messaging. The system earns most of its value here.
• False positive rate - students flagged red who were fine. Track it deliberately and tune thresholds down if advisors start ignoring the list.
• Alert fatigue proxies - SMS opt-out rate, email unsubscribe rate, and reply rate on the first absence nudge over time.
• Revenue retained - part-paid plans still paying at course end, and refunds avoided. Report as counts, not as a claimed saving.

Data sources, which is the real work

• Decide how attendance arrives before anything else. Options in rough order of quality: a direct integration from the student information system, a scheduled CSV or sheet export the platform ingests, a tutor-facing Attendance Exception Form, or a kiosk check-in form at the door. Pick one and make it the single source. Mixing two silently breaks the consecutive-absence counter.
• Decide how progress arrives. If courses sit on the platform memberships, the signals are native. If they sit elsewhere, you need lesson completion and last login pushed in on a schedule or via a connector such as Zapier or Make.
• Agree the expected-pace curve per course before you score anything. progress_expected_percent has to come from somewhere: a straight line from start to end date is the usual starting point, adjusted for holiday weeks and assessment blocks.
• Confirm the scoring thresholds with the program lead in writing. Amber and red boundaries are a policy decision about staff workload, not a technical one. Start deliberately conservative so the red list is short enough that someone actually works it.

Integrations and provisioning

• Student information system or course host, with credentials and a tested read path.
• Calendar connection for every advisor and tutor, so the check-in calendars show real availability rather than double-booking people.
• Payments connection if part-paid plans are in scope, so a failed payment can feed the risk score.
• A dedicated local number for student success, provisioned and tested in both directions. Do not reuse the admissions number.
• A monitored support email address with replies routed into the platform conversation, and SPF, DKIM and DMARC aligned on the sending domain.
• Reporting sink if leadership wants cohort dashboards outside the platform.

Messaging compliance

• Complete A2P 10DLC brand and campaign registration for the student success number before launch, and register it honestly as a mix of informational notification and conversational traffic. Unregistered or misregistered traffic gets filtered, and filtered attendance alerts are worse than no alerts because the dashboard will show them as sent.
• Capture SMS consent at enrollment with explicit, logged wording, and keep the enrollment form record as the evidence. Consent for service and attendance messaging is a separate thing from marketing consent; store them as separate fields and never let a marketing sequence borrow the service consent.
• Honor STOP, UNSTOP, HELP and their variants automatically at the platform level, and make sure the sms-opt-out tag hard-suppresses every sequence rather than just the one the student replied to.
• Set quiet hours in the student timezone and do not let a nightly job push a message at 2am because that is when it ran. Hold overnight output in a queue and release it at 8am.
• Cap frequency explicitly: no more than one SMS per student per day and three per week from this build, across all workflows, with a shared suppression window.

Data protection and safeguarding

• Guardian and sponsor contact is the sharpest edge in this build. Never message a third party without a recorded permission in guardian_contact_permitted or sponsor_reporting_permitted, captured at enrollment with the specific scope stated. For adult learners, assume no third-party contact is permitted unless the student has said otherwise.
• Keep third-party messages to attendance and progress facts. Health reasons, personal circumstances and anything a student disclosed in confidence do not go into a sponsor report.
• Define a retention period for attendance, progress and barrier data, and have the plan delete or anonymize on schedule rather than keeping it forever by default.
• Write the safeguarding escalation path before BO goes live: who is notified, how fast, what gets logged, and what the system must stop doing. Test it with a deliberate trigger phrase before any real student touches it.
• Education data is heavily regulated and the rules differ by jurisdiction, learner age, funding source and awarding body. Student records, minors, and sponsored or publicly funded learners each carry their own obligations. Confirm consent wording, third-party disclosure, retention periods and messaging practice with the client's own counsel and their data protection lead before launch. The guidance here is operational, not legal advice.