Tutoring centre management software: which features you actually need

The easiest mistake when choosing tutoring centre management software is to go for the longest feature list. The daily work of a tutoring centre is fairly fixed: enrolments, registers, instalments, messages to parents, mock-exam results and homework. This post looks at who uses the system, what the first version has to cover and what can wait.

Who uses the system, and what each person needs on screen

Four different people look at the same student record. The manager wants money and class sizes, the teacher their class, the parent their own child, and the student their homework. A good system opens on the answer to each person’s question and keeps the rest out of the way.

A common mistake is designing everything around the manager’s reports. Teachers take the register and set the homework. If their screen is slow and cluttered, the data never goes in and the manager’s report stays empty.

What the first version of tutoring centre management software must cover

The test is simple: work that comes round every week and currently lives in a ledger, a spreadsheet or a WhatsApp group. In most tutoring centres and course providers, these six modules pass it.

Instalments are the most underestimated module. Sibling discounts, deposits and bursaries make every student’s plan slightly different. The system should build the plan at enrolment and put overdue payments on the manager’s first screen. If you use accounting software, agree early on whether payments should flow into it.

For mock exams, the first version only needs to import the file from your answer-sheet scanner or exam publisher without anyone retyping it. Mapping questions to learning outcomes makes the data far more useful. If your list of outcomes isn’t tidy yet, that step can wait for version two.

What can wait for version two

Most centres ask for these after a while. Added in the first term, before anyone has used the system for real, they stretch the timeline and make it harder for teachers to settle in.

• Online card payments: instalment tracking has to work properly first; the payment gateway sits on top of it.
• A question bank and test builder: tagging questions by learning outcome is a workload of its own.
• An app in the App Store and Google Play: at first, a mobile-friendly web page with notifications is enough for most parents.
• Cross-branch reports and teacher pay calculations: both need at least a term’s worth of clean data.

A practical rule: run the system for one term, then plan version two around what teachers and parents ask for most.

Off-the-shelf package or custom software for a tutoring centre?

There are ready-made education management software packages aimed at tutoring centres, and some of them do the job well. The choice depends on how standard your centre’s way of working is.

There is also a common middle route: standard work such as accounting stays in a ready-made product, and the parts specific to your centre are built separately. With custom software, the source code and IP transfer to you on final payment.

Questions to ask a vendor

Every package looks good in a demo. Ask for clear answers to these:

• Does a parent see only their own child, and a teacher only their own class? Can you show me with a test account?
• Can I import the results file from our answer-sheet scanner or exam publisher without editing it by hand?
• How is the payment plan built for a student with a sibling discount who starts mid-term?
• When the contract ends, can I export all of my student, payment and exam data?
• Where is the data stored, and how often is it backed up?

For custom software, also ask when you’ll hear the time and budget impact of a scope change, and how often you’ll see a working version. On our projects a product owner is your single point of contact, you see a working version every week, and scope changes come to you in writing within 24 hours.

When in the school year to switch systems

Switching mid-term, and above all during mock-exam weeks, leaves teachers running two systems at once. The plan that usually works looks like this:

1. 01

   Choose and scope

   April-May

   Pin down your mock-exam format and instalment rules, and have the first call now.

2. 02

   Build and migrate

   June-July

   Students, classes and open instalments move across. An operations dashboard with roles and notifications typically takes 4-8 weeks.

3. 03

   Trial with staff

   August

   Teachers and the front desk try it with real enrolments, and whatever trips them up gets fixed before lessons start.

4. 04

   Go live with lessons

   September

   Registers and homework run through the system from week one; the first mock exam tests the parent notifications too.

If lessons have already started, the next sensible window is the winter break. Start planning in October and a first version can be ready by then.

Student and parent data: the general picture under KVKK

A tutoring centre system holds students’ marks and absences, parents’ phone numbers and payment details, and most of the students are minors. Under Türkiye’s data protection law (KVKK), as under GDPR in the UK and EU, the centre is the data controller. Preparing the privacy notice and collecting consent where it’s needed are the centre’s responsibility.

On the software side, plan these from the start:

• Role-based access: teachers see their own classes, parents their own child, and payment details open only for the manager and the accounts team.
• Access logs: a record of who opened or changed which student record, and when.
• No shared numbers: in a WhatsApp group every parent’s number is visible to everyone; notifications sent through the system avoid that.
• Retention: how long a former student’s data is kept, and how it is deleted.

This section is a general outline and isn’t legal advice. For your privacy notice and consent process, speak to a lawyer or a data protection adviser.

Frequently asked questions