Before choosing school software, map the school day.

Imagine Monday morning: a teacher is absent, a timetable has changed and the office has two different class lists. A new screen will not decide which list is right. Start by agreeing how the work should happen.

A useful school software checklist names the task, the record it needs, who maintains it and how a mistake gets corrected. You can prepare it with blank forms and fictional examples. You do not need to upload children's records to compare products.

Describe the school you actually run

A nursery, a primary school, a senior secondary school and a boarding school have different days. Write down the stages you teach, academic year, classes, sections, languages and whether residential routines belong in scope. Add the people who will use the system, including office staff, teachers and school leaders.

The official UDISE+ 2025–26 data capture format separates school profile, facilities, staff and student information. Those headings are a useful starting point for your inventory. They are not a reason to collect extra information for a software trial, and this guide is not a reporting checklist.

Find the record people should trust

List where each record lives today and who checks it. If a paper register and a spreadsheet disagree, decide who resolves the difference before asking a vendor to import both.

This is a planning exercise. It is not a list of features already available in Kyloth Class. Keep nursery observations distinct from examination marks, and include boarding work only where your school needs it.

Give every handover an owner

Choose one routine that often needs a second person. Write who starts it, who checks it and who deals with an exception. For a timetable change, the person approving the change and the people who need to hear about it may be different.

CBSE's school quality framework connects school practices with records and evidence across several areas of school work. Its context is CBSE school assessment, not a universal rule for every board. The practical lesson here is simple: a saved document should support a real action. Our handover guide offers a general way to record the next action and responsible person; adapt the idea to your school.

Ask for a small demonstration with fictional records

Give each supplier the same example: a fictional class, a teacher away for a day and a lesson that needs moving. Ask them to show the change, a correction and what different staff roles can see. Try the steps on the phones and computers your team expects to use.

Then ask what happens if the connection drops, a staff member leaves or you need your records back. Request a demonstration of any promised export or offline feature. A presentation slide is not proof that it works. Keep real student, guardian and staff details out of public previews.

Compare the full scope and cost

Separate what is included today from paid extras and future plans. Ask about setup, data preparation, training, support, message charges, devices and recurring fees. Write down who will do each part of the work.

The Class product page separates the intended school suite from current work. New sign-ups are not open yet. Use the pricing and cost-scope page to understand the wider questions to settle before a paid commitment; a Commerce price is not a Class quotation.

Start with one routine you can explain

Pick a process, agree its owner and define what a successful demonstration would show. Keep a short list of unanswered questions. A clear school day is a better starting point than the longest feature list.