Opens in a new tab
Home / Case studies / Education · ML & Vision

A well-being scoring tool that helps schools notice the students who need support

A behavioral scoring tool that combines structured questionnaires with the engagement signals a school already gathers, generates physical, mental, and emotional well-being scores over time, and informs staff when a student's trend calls for a human conversation – it brings the signal to their attention, and it is then up to people to decide how to proceed.

Client Industry
Education technology · schools & pastoral care
Key Challenge
Spotting struggling students before grades reveal it
Core Tech Stack
Deep learning · Survey analytics · Time series · Python
Deployment Model
Scored history with human-owned escalation

SoftmaxAI developed a student well-being scoring tool which enables pastoral staff to identify a student who is having difficulties before such issues appear in the results. The tool combines structured questionnaires designed to assess a student's mood and level of engagement with signals that the learning platform already has — for example, the material a student selects to study and how frequently they ask for support — and then evaluates the student across physical, mental, and emotional aspects. The scores are kept as a record of trends rather than as a final judgment, so that staff can observe a trend; if this trend goes beyond an agreed threshold, the tool raises it with a member of staff. It suggests a conversation, without making any determination about the child.

The challenge

Grades are a lagging indicator of a struggling student.

  • The signal arrives too late. Generally by the time there is a drop in the assessment results, the period when support could have most easily been provided has already gone by.
  • Staff attention does not scale. Noticing a change in one student among hundreds depends on the right teacher happening to spot it — reliable for some students, invisible for others.
  • A single reading means nothing. It's entirely possible to have a bad week; a tool which responds to a single low response will produce noise — all that's important is whether or not the direction of travel has changed.
  • The wrong design becomes surveillance. When measuring well-being it is easy to end up with a system that monitors children. The inputs had to be legitimate and obtained with the consent of the relevant parties, and the output had to be directed at informing a human rather than replacing that person.
System Architecture Diagram

How the data flows.

The tool operates on a left-to-right pipeline whereby the responses given in the questionnaire when consent is obtained and the signals indicating platform engagement are combined to form features for each student, then scored against various well-being dimensions, tracked as a time series, and only passed on to staff when a sustained trend goes beyond an agreed threshold.

Architecture diagram: consented questionnaire responses and platform engagement signals such as study material choices and support requests flow into a feature assembly stage that builds a per-student record. That feeds a well-being scoring model producing physical, mental, and emotional dimension scores, grouped with a trend tracking component inside a scoring boundary. Scores are written to a time-series history, which drives a threshold and trend evaluation stage. Sustained threshold crossings raise an alert to pastoral staff, who own the decision; the dashboard and review history serve staff directly.
The approach

A signal for staff, not a judgement about a student.

  • Boundaries written into the spec. Prior to carrying out the modeling, we decided which inputs were legitimate, what the score did and did not claim, set the escalation threshold, and established the rule that the tool would never produce an outcome for a student — it would only provide a prompt to a person.
  • Consented inputs only. Scores are built from questionnaire responses the student gives and engagement signals the platform already holds with their knowledge — not from monitoring behavior they did not agree to share.
  • Trends, not snapshots. The deep-learning models evaluate each well-being dimension on a continuous scale and consider the trend over time, meaning that one low response is not enough to trigger an intervention.
  • Human-owned escalation. The client’s educators were responsible for setting the thresholds, choosing the alert wording, and handling the pastoral response — verifying them against real-life situations to ensure that an alert always meant "have a conversation".
Functional outcomes

What the build made possible.

  • Earlier visibility than results allow. A change in engagement and mood can be detected while support is still easy to provide, rather than only after a period of decreasing marks.
  • Consistent attention across every student. Every student is scored on the same basis, so being noticed no longer depends on which teacher happens to be paying attention.
  • An evidence base for difficult conversations. Pastoral reviews and parent meetings start from a documented history across well-being dimensions instead of impressions recalled after the fact.
  • Alerts that mean something. Threshold-crossing on a sustained trend — not a single response — is what reaches staff, which is what keeps the alerts worth reading.
  • Decisions stay with people. The tool surfaces and evidences; educators interpret and act. No score produces an automatic consequence for a student.
Under the hood

Core tech stack.

Deep learningBehavioural scoringQuestionnaire designTrend detectionThreshold alertingHuman-in-the-loopEdTechAnalytics dashboard
The SoftmaxAI Method

Every build runs the same four stages — spec approved before code.

01 / SPECSpec

A written specification that has been approved by the client prior to any coding taking place — covering the architecture, the edge cases, and the acceptance criteria.

02 / BUILDBuild, with agents

The engineers arrange for the AI agents to carry out the specification in parallel, taking weeks rather than quarters.

03 / VERIFYVerify

The evaluations, tests, and security checks are carried out together with the build, and humans examine every decision that is important.

04 / SHIPShip & improve

The system has been deployed to your GCP or AWS, complete with monitoring, production evaluations, and retraining loops.

Start here

Have an AI idea? Let’s pressure-test it — free.

A 30-minute call with our engineers, not a salesperson. You’ll get an honest feasibility read, a rough architecture, and a clear next step.