← The Scoliom blog

Guides

School groups: running several schools without multiplying the tools

28 June 2026

As long as there is only one school, management fits into a few files and a great deal of habit. The head knows the pupil numbers by heart, the accountant knows who has paid, the morning register reaches the office without delay. Then comes the second school. Out of caution, what worked is reproduced there: the same spreadsheets, copied and then adapted, a payments desk run the way the new team prefers, an enrolment register specific to the site. Each school runs smoothly. Seen from the inside, neither poses a problem.

The difficulty appears when the group's management asks a simple question. How many pupils are enrolled to date, across all sites? What is the collection rate for the term? Two answers come back, each accurate in its own context, but impossible to add together. Fee categories do not carry the same names, cut-off dates differ, an “enrolled” pupil here matches a “pre-enrolled” one there. So the figures are recounted by hand, every month, with the doubt that always accompanies numbers pieced back together.

Why the figures stop being comparable

The cause is not negligence. It is duplication. Each site inherited a copy of the tools, then gave it a life of its own. A column added here, a category renamed there, a calculation method adjusted to a local situation. After two school years, the files have diverged without anyone having decided it. And the larger the group grows, the wider the gap: by the third school, the monthly consolidation becomes a job in its own right.

The opposite answer is just as risky: pouring everything into a single file. Data that ought to remain separate then gets mixed. Pupils from one site have no place in the other's lists, and every filtering mistake becomes an information leak between schools. Family confidentiality cannot be managed through precautions in a shared spreadsheet.

What should be shared, and what should stay with the site

The architecture that works is neither copying nor merging. It is one database per school, governed by rules defined once at group level. In practical terms:

• One database per school. A site's pupils, families and payments stay with that site. No mixing, no filter that must never be forgotten.
• Shared settings. Fee naming, invoicing calendar, enrolment statuses, document templates: all of this is defined once for the group. An “enrolled” pupil means the same thing everywhere.
• Indicators calculated the same way. Pupil numbers to date, collection rate, payment arrears: the formula is unique; only the data changes. Differences between schools become information again, rather than artefacts of calculation.
• A payments desk per site. Each site takes payments and closes its own payments desk, with its numbered receipts.
• Access rights per site. The secretary at one school works within that school, nothing else. Group management chooses its focus: one particular school, or the whole group.

That leaves what should never be standardised: teaching. Rhythms, projects and the way assessment periods are divided may differ from one site to another. A shared management framework does not impose identical schools; it simply makes their figures comparable.

Moving forward without replacing everything

A school group never stops. Enrolments carry on, the payments desk operates every morning, class councils meet on their scheduled dates. Changing every tool on every site at the same time, in the middle of the year, is not a project: it is a gamble.

The sensible approach starts from what already exists. First, align the vocabulary — fee categories, statuses, periods — because that agreement requires no management software, only decisions. Then connect the sites one by one, starting with the one whose data is cleanest. The school already connected works as normal while the next one migrates. At no point does a team lose its tool overnight; it sees its own take its place within a shared framework.

Every group has its own history: schools founded, others taken over, teams with well-established practices. Before moving anything, you need a map: which tools on each site, which data can be trusted, in what order to connect. That is what a remote assessment establishes, carried out on your records with your teams. Running a group does not start with a platform; it starts with that map.