We sell a school ERP. We told this client not to buy one.
A three-branch children's skill training centre in Madurai, running one-month courses where a single child enrols in four programs at once — and every assumption a School ERP makes gets in the way.
- SECTOR
- Skill training / after-school
- SCALE
- Three branches
- LOCATION
- Madurai, Tamil Nadu
- STACK
- Laravel, Livewire, MySql
- STATUS
- LIVE
Why our own product was the wrong answer
GegoSoft builds and maintains GegoK12, an open source school ERP used by institutions in several countries. When a training centre asks for a system to manage students, courses and fees, the commercially obvious move is to sell them that.
We did not, because a School ERP is not a neutral container for education data. It is a set of assumptions baked deep into the schema, and every one of them is wrong for a business running one-month handwriting and abacus courses across three branches.
Enrolment, promotion and reporting all hang off a yearly cycle.
Starting whenever a batch fills, ending independently of any calendar.
A child belongs to a class and a section, singular.
Handwriting and abacus and craft, running concurrently on different schedules.
Progression means moving up a grade annually.
Progression happens per program, at its own pace, several times a year.
Term fees derive from the class the student sits in.
Each course has its own price and instalment plan, running in parallel.
Enquiries concentrate around one intake period.
Enquiries arrive continuously and need a sales pipeline, not an admission form.
Forcing this business into a School ERP would have meant creating a fake academic year, duplicate student records per course, and a fee module that could not represent what the client actually charges.
So we built the thing the business needed, which turned out to be closer to a multi-branch CRM with course delivery attached than to school software at all.
The child is the student. The parent is the customer.
School software is built around the student because in a school the student is the unit of everything — attendance, results, reports, fees. Here that model breaks at the point where money is involved.
A parent with two children, each in two courses, has four enrolments, four fee schedules and one wallet. They do not want four reminders. They want to know what they owe. And when the centre chases a payment, it chases the parent, not the child.
So the parent is a first-class record rather than a contact field on a student. Fees roll up per parent as well as per enrolment, outstanding balances are visible at the household level, and every communication — reminders, completion notices, promotions — addresses the person who actually decides and pays.
Enrolment is the unit, not class membership
A child holds many enrolments, each with its own course, branch, level, start date, completion date and fee plan. Adding a fifth course creates an enrolment, never a duplicate child.
Courses vary by branch
Not every branch runs every program. Availability, and therefore what can be sold at each location, is defined per branch.
Instalments belong to the enrolment
Each course carries its own payment plan, so a parent may be mid-instalment on one course and paid in full on another.
Leads are continuous
Enquiries arrive all year with a source, an interested course and a branch preference, and are worked as a pipeline through to enrolment.
The owner stopped depending on branch reports
With three locations, the owner's picture of the business was assembled from what each branch reported, when they reported it. That arrangement is slow, and it makes the person accountable for a branch's numbers also the person producing them.
A consolidated dashboard replaced it — total and branch-wise collections, pending payments, outstanding receivables, active students, new enrolments and course-wise uptake, drawn from the same records the branches work in daily. Branch administrators run their own operations independently; the owner sees all of it without asking anyone.
Outstanding receivables is the figure that changes behaviour. Spread across three branches and hundreds of parallel instalment plans, it is effectively invisible on spreadsheets — and it is the number that determines whether the business is profitable this month.
WhatsApp doing three different jobs
Parents in this market read WhatsApp and largely ignore email. The platform uses it for three purposes that are easy to conflate and should not be.
Pre-enrolment bot
A Meta WhatsApp Flow assistant answers the questions the front desk fields dozens of times a week: which courses run, how long they take, suitable age groups, which branch, what levels exist. Structured menus rather than free conversation, because the questions are predictable and the answers must be right.
Operational messaging
Fee reminders, class updates and completion notices, sent to the parent from the same records that hold the balance. Automated reminders on delayed payments removed the most disliked task at the front desk.
Marketing campaigns
A separate interface for authorised staff to run promotional campaigns, new batch announcements and targeted follow-up to leads that never converted.
Keeping these separate matters commercially as well as technically. A fee reminder is a transactional message a parent expects; a promotional campaign is not, and mixing the two is how a business loses the channel altogether.
Certificates are the product, not the paperwork
For a short-course business the certificate matters more than it does in a school. It is what the parent shows relatives, what justifies the fee, and frequently what prompts enrolment in the next level. A centre running dozens of completions a month cannot be producing those by hand in a word processor.
Certificates and ID cards generate from configurable templates with student and course data populated automatically, so each program and level can carry its own design without anyone editing a document. Completion produces the certificate as a by-product of the record rather than as a separate administrative task.
What the platform covers
Design decisions
Most of the work on this project happened before any code, in modelling what the business actually does rather than what education software usually assumes.
Enrolment as the core entity
Not student-and-class. A child holds many enrolments, each independent in course, branch, level, dates and fees — which is the single decision the rest of the system follows from.
Parent-level rollup
Fees are tracked per enrolment but owed per parent, so a household sees one balance and the centre chases one person.
Local autonomy, central visibility
Branches operate independently on their own data while the owner reads across all of it, without either side needing the other to prepare anything.
Template-driven generation
Certificates and ID cards render from templates with record data injected, so new programs need a template rather than a developer.
Separated WhatsApp channels
Transactional and promotional messaging kept apart, because mixing them risks the channel the whole business depends on.
Role-scoped permissions
Branch staff see their branch, marketing sees the campaign tools, the owner sees everything. Parent contact data is not browsable by everyone.
How the team built it
GegoSoft engineers use Claude Code as standard daily tooling. Here it carried the breadth — a system this wide has a lot of ordinary CRUD, reporting queries and template rendering surrounding a small number of genuinely tricky areas, and moving quickly through the ordinary parts left more time for fee arithmetic and the reporting rollups.
The business process modelling, the enrolment-centric data design and the decision not to adapt a School ERP were the team's, worked out with the client. Every change passed normal review before merge.
What changed
Spreadsheets, manual fee tracking and disconnected messaging were replaced by one system shaped around how the business actually runs. Branch administrators work independently, the owner has consolidated visibility without asking for reports, reminders go out without anyone remembering to send them, and certificates are a by-product of completion rather than an afternoon's work.
Common questions
Should a training centre use a School ERP?
Usually not. School ERPs assume an academic year, one class per student, annual promotion and a fee structure tied to the class. If you run short courses, level-based programs or students enrolled in several things at once, every one of those assumptions creates workarounds. We build and sell a school ERP, and we still say this.
Can GegoSoft build a CRM for our coaching or activity centre?
Yes. The first conversation is about how you actually enrol and charge, because that determines whether an existing product fits or whether custom is genuinely cheaper over time. We will tell you if something off the shelf would do.
Why model the parent separately from the student?
Because the parent pays. With multiple children in multiple courses, fees only make sense rolled up to the household — one balance, one person to remind, one conversation about what is owed.
Can it handle multiple branches?
Yes. Branches run their own operations with their own course availability and staff, while the owner gets consolidated collections, receivables and enrolment across all locations without branches preparing reports.
Can you integrate WhatsApp for enquiries and reminders?
Yes. This platform uses a Meta WhatsApp Flow bot for structured pre-enrolment questions, automated transactional reminders, and a separate interface for marketing campaigns. Keeping transactional and promotional messaging apart is important to protect the channel.
Do you work with businesses in Madurai?
Yes. GegoSoft is based in Madurai, and while most of our work is for international clients, we build for local businesses too. This client is three branches in the city.
Related work
Been told your business is unusual by three vendors?
Tell us how you enrol, what you charge for and who pays. If an off-the-shelf product fits, we will say so — and if it does not, we can usually point at the exact assumption that breaks.
Start a conversation See all case studies