A training centre management system, scoped module by module

A centre running six cohorts a term asked us to price a management system. The brief listed nineteen features. Two of them were the reason anyone was unhappy, and the other seventeen were things a competitor's screenshot had put in their head.

That is the normal shape of this request, so this note is the scoping conversation rather than a feature list. We have written about the symptom side of it before, in the three tools every training centre rebuilds in spreadsheets. This is the other half: what the system itself should contain, and in what order.

What people mean when they ask for one

The phrase covers at least four different products. For some centres it means a student record system: who enrolled, what they paid, what they finished. For others it means timetabling, because rooms and trainers collide. For others it is a sales tool, because the real pain is that enquiries go cold in a WhatsApp inbox. And for a few it means a learning platform, with content and assessment inside it.

These are not variants of one system. They have different data, different users and different failure modes, and a build that tries to be all four at once is the build that arrives late. The first job is to find out which of the four is causing the pain, and that is usually answered by asking what went wrong last month rather than what the system should do.

The four modules, in the order they earn their place

Assuming the centre is running real cohorts and taking real money, this is the order we would build in. Each row earns its place only when the row above it is working and dull.

Notice what is missing. There is no learning platform, no mobile app, no dashboard for the owner. Those are the features that sell a demo and they are almost never the reason the centre is struggling. A dashboard built on top of four modules that do not yet hold clean data is a very expensive way to display guesses.

The data model decides what you can ask later

One decision in this domain causes more retrofitting than any other, and it is worth getting right on the first day. A student is not the same thing as an enrolment. The same person can take three courses over two years, pay for two of them personally and have the third paid by an employer, and drop one halfway.

If you model that as a row per student with course columns, every one of those situations breaks the sheet and eventually breaks the system. If you model it as a person, and separately as enrolments that point at a person and a cohort, all of it fits without a special case. The general version of that argument is in database design for beginners, and this is the training centre instance of it.

The same applies to money. A payment belongs to an enrolment, not to a person, and an instalment plan is a set of expected payments rather than a note in a comments field. Get that shape right and questions like which cohorts are underpaid become a query. Get it wrong and they stay a manual reconciliation forever.

Student data is regulated data in Egypt

This is the part that gets skipped and should not be. A training centre holds names, phone numbers, national ID numbers in some cases, payment records and attendance. That is personal data, and in Egypt it sits under Law No. 151 of 2020, the Personal Data Protection Law.

The published English translation of Law 151 of 2020 sets out that personal data may not be handled without the explicit consent of the person it concerns, unless the law permits it otherwise, and that handling is bound by purpose limitation, accuracy and security. It also establishes the Personal Data Protection Centre as the authority responsible for licensing, monitoring and enforcement.

Three practical consequences for the build. Consent has to be recorded as data rather than assumed, so the enrolment record needs to know what the student agreed to and when. Purpose limitation means the marketing list is not simply everyone in the student table, because they enrolled on a course rather than subscribed to a newsletter. And security is an obligation rather than a nice to have, which in practice means real accounts for staff instead of one shared login, and a retention rule for records nobody needs any more.

We are describing the shape of the obligation, not giving legal advice. A centre holding national ID numbers or data about minors should take actual advice on the specifics rather than a note from its software supplier.

Build, buy, or keep the spreadsheet a while longer

Buying is the right answer more often than a development company is likely to tell you. There are established student information products, and if one of them fits the way you already work, the cheapest system is the one you do not commission. The case for building is narrow and specific: your enrolment or scheduling rules are genuinely unusual, or the product you would buy cannot be made to hold the data model above without fighting it.

Keeping the spreadsheet is also a legitimate outcome, and the honest test is whether the process has stopped changing. A centre still inventing how it runs cohorts will be hurt by a schema, because the flexibility of the sheet is doing real work during that period. We set out where the no code and low code middle ground stops in no code versus custom development, and that is often the correct first step here rather than a full build.

One thing worth watching for. A centre that runs weekday, evening and weekend cohorts of the same course has a scheduling problem several times harder than a centre running one intake at a time, because trainers and rooms are shared across all of them. U Courses describe what that looks like from the student's side in their piece on evening marketing courses in Cairo, and every one of those parallel timetables is a constraint your system has to hold.

What we would leave out of version one

Deliberately out of scope on a first build, in our experience of what goes unused: a student mobile app, automated marketing sequences, a content and assessment platform, and any analytics beyond a list of cohorts with their enrolment and payment totals.

• The mobile app is usually a website the centre has not made work on a phone yet.
• Marketing automation belongs in a marketing tool, not in the record system, and coupling them makes both harder to change.
• Content and assessment is a second product with its own budget, and plenty of centres run it perfectly well on an existing platform.
• Owner dashboards should wait until the underlying data has been correct for a full term, because a dashboard on bad data is worse than no dashboard.

Scoping this properly before anyone writes code is most of the job, and we set out how we do it in how to scope a software project. If the enquiry side is what actually hurts, the pricing and shape of that piece alone is closer to what a custom CRM costs than to a full centre system.

Honest limits

Three caveats. First, the module order above assumes a centre with paying students and repeating cohorts. A single trainer running occasional workshops does not need any of this, and would be worse off with it.

Second, we have not put a price on any of it here, because the honest range depends on how unusual your enrolment rules are, and a number quoted without that is a number for somebody else's centre.

Third, the legal position summarised above is the shape of the obligation rather than a compliance checklist, and the executive regulations that give the law operational detail are recent enough that a centre should check the current position rather than rely on any article, this one included.