A parent-teacher meeting is one of the few times a school’s data has to be usable by a human being under time pressure. A teacher has a queue of parents, a few minutes each, and forty students they cannot all hold in their head at once.
What usually happens is that the teacher speaks in generalities for the students they are unsure about, and specifically about the two or three they remember well. Parents can tell the difference, and it does more damage to trust than most schools realise.
Fifteen minutes per parent, no preparation time
The information needed for a good five-minute conversation already exists in the school’s records: how the student has done in recent tests, how often they have been in class, whether there are dues outstanding, whether anything has been logged about behaviour, whether there has been a run of leave.
The problem is that it exists across five modules. Assembling it for one student takes a few minutes of navigation. Assembling it for forty, the evening before, takes an evening that a teacher does not have — which is why almost nobody does it.
This is a straightforward retrieval and summarisation task, and it is a good use of AI precisely because it is not a judgement task. The judgement stays with the teacher; the fetching does not need to.
Scheduling PTM sessions and slots
The briefing sits on top of a scheduling model, because a briefing needs to know which student is in front of the teacher at which time.
A PTM session is created for a class and a date. Slots are generated from it, one per student, and can be adjusted individually. A session carries statistics — how many slots are booked, completed, and pending — so a coordinator can see the state of an evening at a glance. Sessions can be cancelled, and slots can be edited when a parent asks to swap a time.
Parents get their own view of their slot and can leave feedback against it after the meeting, which closes a loop most schools currently leave open.
What goes into a briefing card
Requesting a briefing for a slot pulls together five things about that student, from the school’s own tenant data.
Recent performance — the most recent exam marks, with the subject, the exam name, the marks obtained against the maximum, the date, and whether the student was absent for it. Absences are carried explicitly rather than being folded in as zeroes, which would misrepresent the student.
Attendance — total days recorded, present, absent and late counts, and the resulting percentage for the year.
Fees — total pending amount across ledger entries that are pending, partial or overdue, with the latest due date. This is a read-only lookup; nothing about a PTM briefing touches a financial record.
Behaviour — the most recent behaviour records, with type, category, description and date, where the school uses that module.
Leave — the most recent leave requests with dates, reason and status, which is often the missing context behind an attendance number.
The result is cached for a day. On a meeting evening a teacher may open the same student’s card several times, and re-running the summarisation each time would be wasteful for no gain.
Talking points a teacher can actually use
The generated card is short by design: a summary of where the student stands, and two or three specific, actionable talking points.
The constraint on quantity is doing real work. A briefing that listed twelve observations would be a report, and a teacher with four minutes would read none of it. Two or three points is what fits a conversation, and forcing the selection means the model has to decide what actually matters for this student rather than restating everything it was given.
The card also has an obvious property that is worth stating: everything in it is traceable to a record in the school’s system. A talking point about attendance rests on counted attendance rows. A talking point about a subject rests on a specific exam result. If a parent challenges a point, the teacher can open the underlying screen.
The follow-up message after the meeting
The second half of a PTM is the part that usually never happens. Whatever was agreed in the meeting — extra practice at home, a follow-up in a month, a referral to a subject teacher — lives in the teacher’s memory and the parent’s, and the two versions diverge within a week.
EdunodeX drafts the follow-up. Once a teacher has recorded their own notes against the slot, a draft can be generated: a short message from teacher to parent, summarising what was discussed and including any action items, written to be sent over WhatsApp in a few lines rather than as a formal letter.
The draft is built from the teacher’s notes plus the briefing context, so it reflects the meeting that actually happened rather than a generic template. It requires those notes to exist — asking for a follow-up on a slot with no recorded feedback returns an error rather than inventing a conversation.
If the AI call fails, the system falls back to a plain template that carries the teacher’s own notes through verbatim. That is the correct failure behaviour for this feature: a parent receives something accurate and slightly plainer, instead of nothing.
What a briefing deliberately leaves out
A briefing is a preparation aid, not an assessment. It does not produce a grade, a prediction, or a recommendation about the student’s future, and it is not written into the student’s record.
It does not decide what to tell the parent. A teacher may look at a card, see a fee due, and choose not to raise it in an academic conversation — that judgement is the teacher’s, and the school’s policy on who discusses dues with parents governs it, not the software.
And it does not replace the teacher’s knowledge of the child. What it removes is the specific failure where a teacher who does know the child cannot recall the three data points that would have made the conversation concrete.