Student Retention and Early Alert Software: How Do You Reach a Student in Week Four Instead of Week Twelve?

Why early alert systems fire too late to matter

Week eight of the fall term at a regional public university. Midterm progress reports close on Friday. Faculty submit them at maybe half participation, mostly from the instructors who were already paying attention. The reports generate 900 alerts on Monday morning. Four advisors share a caseload of 2,600 students. They work the list in the order it appears on screen. By the time anyone reaches a first year student flagged in three courses, it is week ten, the withdrawal deadline has passed, and the honest conversation is about how to fail forward rather than how to recover.

That student was visible in week two. She stopped opening Canvas after the second assignment. Her card stopped swiping at the dining hall on weekdays. She never completed the verification step her financial aid file needed, and there is a $1,100 balance blocking her spring registration that nobody has mentioned to her. Every one of those signals existed in a system on your campus. None of them met each other.

The stack is predictable: Banner or Colleague for the SIS, Canvas or D2L for the LMS, a separate card system, Slate or Salesforce for admissions and sometimes advancement, a spreadsheet per advising unit, and an early alert module that ships with one of the above. EAB Navigate360, Civitas Learning, Aviso Retention and Watermark Student Success and Engagement all sell into this gap and all of them do real work. What none of them do is fit your institution's actual advising structure and actual signal sources without a configuration project that costs more than the licence and still leaves the hardest part manual.

In the student success projects we have delivered, the pattern is consistent: the institution can produce a risk list, and cannot answer three follow up questions. Who owns this student right now. Did the outreach actually happen. Did it change anything. A retention system that cannot answer those is a report, and you already had reports.

Problem 1: your best signal is engagement, and it arrives weekly at best

Midterm grades are a lagging indicator by construction. The leading indicators are behavioural: LMS login gaps, assignment submission timing relative to the due date, discussion participation, and the shape of the drop rather than the level. A student who submits everything at 11:55pm and then misses two in a row has changed. A student who never logged in on weekends and still does not is fine.

The commercial platforms do consume LMS data, and Civitas in particular is built around it. The constraint is refresh cadence and feature depth. Nightly aggregate counts of logins tell you far less than submission timing distributions per student per course, and most integrations are built for the former because it is what a generic connector can carry. You also cannot ask the vendor to add the signal that actually predicts attrition in your nursing program, because their model is not yours.

What a custom build does: pull real event data on your terms. Canvas exposes both a data warehouse export and Caliper Analytics event streams, and D2L, Blackboard and Moodle have their own equivalents. You build a per student per course engagement profile updated daily, with features you choose: days since last meaningful action, submission lateness trend, gradebook trajectory against the course median, and drop off relative to that student's own baseline rather than a cohort average. Relative to self is the feature that separates a struggling student from a student who has always worked in bursts, and it is the one generic products handle worst.

Problem 2: the model is a black box and you will have to defend it

A dean asks why this student is flagged high risk and that one is not. If the answer is that the vendor's model says so, you have a problem in the meeting and a bigger one later. Institutions are increasingly asked, by faculty senate, by legal counsel, and sometimes by the press, what features the model uses. If race or Pell status is doing work in your risk score, you need to have decided that on purpose and be able to explain it.

Vendor models are trained across many institutions, which is a genuine strength for cold start and a genuine weakness for your specific population. A model calibrated across hundreds of campuses will systematically misjudge the parts of your institution that are unusual, which is usually your highest risk programs.

What a custom build does: use a model you can read. A gradient boosted tree with SHAP explanations, or in many cases a straightforward logistic regression on twelve well chosen features, gives you a score and a per student reason list an advisor can act on. Our position is firm: exclude protected characteristics from the features and use them only in the fairness audit, where you check whether the model performs differently across groups. That audit is a report you run every term, and it is the document that ends the faculty senate conversation. Explainability here is not a nice property, it is the operating requirement, because the output is a human being calling a student.

Problem 3: alerts go to a queue, not a person, and the loop never closes

Advising structures are institution specific in a way vendors underestimate. You may have professional advisors by college, faculty advisors by major after the sophomore year, a separate TRIO and student support services unit with its own participant list, athletics academic services with NCAA eligibility obligations, an honors college, and a nursing cohort with its own progression rules. A single student can sit in three of those at once, and only one of them should own the outreach.

Navigate360 handles caseloads and does it competently. What breaks is the ownership rule, because your rule is not caseload alone, it is caseload plus program plus flag type plus who spoke to the student last. The commercial answer is to assign a case to a team inbox, and a team inbox is where accountability goes to die.

What a custom build does: encode the routing rule as a rule. A financial hold alert for an athlete in week three routes to athletics academic services with the bursar contact attached, not to the general advising queue. Every case carries an owner, a due date, a required outcome disposition, and an escalation if it goes untouched. The advisor logs the contact in one click from the alert, including the fact that the student did not respond, which is itself data. And the system knows about the other flags on that student so nobody is the fourth person to call her this week, which is the most common way a well intentioned retention program annoys students into leaving.

Problem 4: the data is legal to use, but only if you can prove why

FERPA permits sharing education records internally with school officials who have a legitimate educational interest, and that is the clause your entire retention program runs on. It is a real permission and it has real edges. Card swipe data, counseling center contact, and health center visits are not the same category as grades. Bringing them into one risk score without a decision about who can see them is how an institution ends up in an uncomfortable article.

What a custom build does: separate the score from the evidence. The risk score can be computed from sensitive signals while the evidence shown to a given user is filtered by role. An advisor sees academic engagement and holds. A case manager with a documented need sees more. Counseling records stay out entirely unless the student consents, which is a design decision we recommend making explicitly and writing down. Every view of a student record is logged. When your general counsel asks whether the athletics office can see financial aid detail, the answer should be a role definition you can show them, not a shrug.

Problem 5: you cannot tell which intervention worked

Every unit claims the students who persisted. The tutoring centre counts them, the advisors count them, the success coaches count them, and the same student is in three success stories. Meanwhile the intervention that genuinely moved the needle, which in our experience is often something unglamorous like clearing a small balance or fixing a registration error, gets no credit and no budget.

What a custom build does: record interventions as events with a timestamp, an owner and a type, then compare outcomes among students with similar risk profiles who did and did not receive them. This will not be a randomised trial and you should not pretend it is, but propensity matched comparison on your own population is defensible enough to redirect budget, and it is infinitely better than headcount claims. Build the outcome measurement in the first release, not phase three, because retrofitting it means a year of interventions you cannot evaluate. Your board will eventually ask what the retention program bought. Decide now whether you will have an answer.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is the honest shape. A focused first release, meaning signal ingestion from the SIS and LMS, an explainable risk model with per student reasons, and case routing that mirrors your real advising structure with outcome dispositions, runs $80,000 to $170,000 and ships in 12 to 16 weeks. That is a system your advisors work from in week three of a live term. A full platform adding multi channel outreach campaigns, financial aid and balance triggers, intervention outcome measurement, a student facing app, and predictive term to term persistence modelling runs $200,000 to $450,000 phased over 6 to 12 months.

What drives price up specifically here: the number of source systems, because each additional one is integration plus data governance plus a committee. LMS data access, since Canvas data warehouse access is straightforward and some Blackboard and Moodle estates are not. The number of distinct advising units with distinct rules, because five units with five rulebooks is five times the routing logic. Historical data depth, because a model needs several years of outcomes and if your SIS history is messy that is a cleanup project. And single sign on plus role design, which sounds like plumbing and is actually the governance conversation that takes six weeks of meetings.

What keeps price down: starting with first year students only, two signal sources, and one advising unit. That covers the population where retention effort pays back fastest and teaches you the rules before you scale.

Build versus buy, and when buying is the right call

Buy if you are under roughly 2,000 students and your advisors can name the at risk students without a system. Aviso Retention is reasonable at that scale and your LMS already ships analytics that will surface the obvious cases. Buying is also right if you have no data engineering capacity at all and no plan to acquire any, because a custom system with nobody to maintain the pipelines becomes a broken system in eighteen months.

Build when two or more of these hold. Your advising structure has more than three units with genuinely different ownership rules. Your signal sources include something the vendors do not connect to, which for many institutions is card access, a homegrown degree audit, or a state workforce data share. You have been asked to explain the risk model and could not. Your alerts fire on midterm grades and you have accepted that as normal. Or you already own a vendor platform and your team has quietly built a shadow spreadsheet system beside it, which is the clearest signal in this entire category that the fit is wrong.

Our opinion, stated plainly: the model is not the hard part and vendors oversell it. Routing, ownership, and closing the loop are the hard parts, and they are exactly the parts that must match your institution. That is why this category keeps producing custom builds even at institutions that already bought something.

How to choose a developer for student success software

Ask them to explain how they would prove the model is fair before you talk about accuracy. A developer who leads with model performance and has nothing to say about subgroup calibration has not worked in higher education and will hand you a defensibility problem at your first faculty senate meeting.

Ask what they will do about the student who is flagged by four units in one week. If the answer is not a contact suppression rule and a single owner, they are building an alert firehose that advisors will learn to ignore within one term.

Ask specifically which LMS they have pulled event data from and by which method. Canvas Data plus Caliper is a different job from scraping a Blackboard report, and the difference determines whether your signals are daily or weekly. Ask for the institution and the method, not a general claim.

Ask who owns the code, the model and the data, in writing, before kickoff. You should own the repository, the cloud accounts and the right to bring in another firm. At Digital Heroes the client owns the code from the first commit. For a system that makes judgements about your students, a model you cannot inspect or move is a liability regardless of who built it.