You have signed the lease, the new site has a name, and everyone is excited. Then the first Monday arrives and your Director of Studies is holding two timetables that disagree about where one teacher is supposed to be at eleven o'clock. Opening a second school campus is the point where administrative cost stops being linear: student numbers roughly double, the admin work more than doubles, and nobody tells you in advance which parts multiply and which parts do not.
This is an operations guide, not a business plan. By the end you will know which four systems break first, what has to be shared across sites and what should stay local, how to handle students and staff who move between campuses, and the access question you have to answer on the day the second site opens.
What multiplies, and what doesn't
Not everything doubles, and getting that distinction right in advance is most of the work.
Some things stay the same however many sites you run: your level framework, your curriculum, your pricing policy, your enrolment form, your terms and conditions. These are definitions, and defining them twice is something you do by accident, not a requirement of having two buildings.
Some things genuinely double — rooms to schedule, registers to take, front-desk cover, and the number of places a signed document can be sitting in when you need it.
And some things more than double: reconciliation, communication overhead and exception handling. They grow with the number of pairs of places where your data can disagree. One site has no reconciliation problem at all — the register is the register. Two sites have a permanent one. Every number you report now exists in a version at site A, a version at site B, and a third version that somebody assembles by hand on a Thursday afternoon and that nobody fully trusts.
That third version is the real cost of a second campus, and it is invisible in the projections.
The four things that break first
Timetabling stops being one puzzle and becomes two that overlap
Single-site timetabling is a constraint problem with two variables you already understand: rooms and teacher availability. A second site adds a third that most single-campus tooling does not model at all — travel time. A teacher cannot finish at 12:00 in the city centre and start at 12:15 across town, but a spreadsheet will let you write it down, and you find out when the students are already sitting there.
Academies running rolling intakes feel this first, because the timetable is rebuilt continuously as students arrive, change level and leave rather than once a term. Doing that across two sites by hand is where Directors of Studies lose their evenings, and it is one reason software designed for language academies behaves differently from software built around fixed terms.
Teacher allocation turns into a negotiation
With one site, a teacher belongs to the school. With two, they start belonging to a site — and the moment somebody is "site A's teacher", moving them to cover a gap at site B becomes a favour rather than a scheduling decision.
The failure is quiet, which is what makes it expensive. A teacher's hours are correct on site A's sheet, correct on site B's sheet, and wrong in total. Contract limits, overtime, availability and holiday entitlement are organisation-level facts tracked in two site-level places.
The rule that prevents it: one staff record per person, contracted at organisation level, allocated to sites. Never a staff list per campus. If you take one thing from this article, take that one — it is the hardest to unwind afterwards.
Reporting splits into two truths
Ask how many active students you have and a two-site operation will give you three answers.
The reason is rarely arithmetic. "Active" quietly means something different at each site: one counts a student from the date they pay, the other from the date they first attend; one keeps a student active through a two-week break, the other pauses them. Both are defensible. Together they are useless, because you can neither add them nor compare them.
Write your reporting definitions down centrally before the second site opens — what counts as an active student, when an enrolment starts, when a student has left, how a transfer is counted. Then build consolidated first and treat per-site as a filter on the same data, never the reverse. A group total assembled from two separately maintained reports is a number with no owner.
Processes diverge, and nobody decides to let them
Six months after opening, your two sites will handle enrolment differently. Nobody will have decided this. It happens because the new site opened with a manager who had to make fifty small decisions in their first fortnight with nothing to check them against, so they invented fifty reasonable answers. Collectively those answers are a second operating model.
The antidote is boring and it works: write down in advance the processes that must be identical, and make the new site's setup a configuration of the existing system rather than a fresh start. If the second campus begins with a blank spreadsheet, you have already chosen divergence.
The permission problem that appears on day one
With one site, everybody sees everything, and that is mostly fine. With two, it stops being acceptable and it stops being safe — and it happens on the first day, not gradually.
Site A's receptionist does not need the payment records of families at site B. The new site manager needs everything at their campus and nothing at yours. Your Director of Studies needs academic data at both and payroll at neither. Every one of those is a two-dimensional statement: a role that says what a person can do, and a scope that says where.
Almost nothing improvised handles both dimensions. A shared drive gives you per-folder access, not per-role access. A spreadsheet gives you all or nothing and in practice always gives you all. The workaround — a separate copy of everything per site — is the divergence problem wearing a different hat.
Decide this before you open. Retrofitting permissions onto a team that has had full visibility for a year reads to staff as lost trust rather than as the normal consequence of growth. Academic records, attendance and student data in a proper system carry a site scope from the start, which makes this a setup decision instead of a retrofit.
If your sites sit in different countries, access is also a data protection question. Write your access model down, keep it current, and check the specifics with your national data protection authority and your accrediting body.
What to share and what to leave local
A useful default: share every definition, localise every operation.
Shared across sites — level framework and curriculum, pricing and discount policy, staff records and contracts, student records, document templates, reporting definitions, the academic calendar skeleton.
Local to each site — class and room scheduling, teacher allocation to specific classes, front-desk workflows and opening hours, suppliers and facilities, local marketing, and calendar exceptions such as city holidays or a building closure.
Two deserve a note. Pricing should be shared, but sites will need exceptions for a competitive local market or a different cost base — make each one a recorded variation of the central policy rather than a local habit, or within a year you will not be able to say what your course costs. Calendars should be shared as a skeleton and local in the exceptions, because term dates, holidays and closures genuinely differ between cities, and forcing one calendar on both sites produces a fiction everybody ignores.
Finance sits slightly apart. Whether each site invoices separately depends on your legal structure, which is a question for your accountant. What is not optional is that the ledger consolidates: one view of income, arrears and outstanding balances across both sites, filterable to one. Payments, billing and family statements kept separately per site produce exactly the third-version problem above.
Students and staff who cross between sites
Students move between campuses more often than anyone plans for. A family relocates across the city. A level only runs at one site this month. Someone takes a morning course at one campus and an evening exam-prep class at the other.
One question determines how painful this is: when a student moves, is that a transfer or a new enrolment? If your setup forces a new enrolment, you have cut that student's history in half. Attendance, level progression, payments and documents now live in two places, and it first hurts when somebody asks for a certificate covering their whole stay.
The principle matches the staff one. The student is an organisation-level record; the enrolment is site-scoped. One student, one record, one history, whatever building they are sitting in. Test it before you open by moving a test student between sites and asking for their full history afterwards. If that takes more than a few seconds, you have found your first thing to fix.
For teachers working at both sites: one contract, one availability calendar with travel buffers, one payroll view, one named person responsible for arranging cover when they are ill. A shared teacher with two managers has, in practice, none.
What this looks like with a proper system
The pattern that works is treating the site as a dimension of your data rather than as a separate copy of your school.
One student record with a site attribute, not two student databases. One staff record with site allocations. Permissions expressed as role plus scope, so a site manager and a group finance lead each get exactly what they need. Reporting consolidated by default and filterable by site. A timetable that knows the same teacher cannot be in two buildings at once. Families using one app and one login regardless of which campus they attend.
Two institutions using KMPUS run exactly this shape of operation. NED College operates in Dublin and Limerick with around 1,500 students, and Erin School of English runs sites in Cork and Dublin with around 1,400. Both are two-city operations where the hard problems are the ones above rather than anything to do with buildings.
None of this requires you to buy anything before you open. It does require deciding, before you open, that the second site is a scope within one system rather than a second system sharing a logo.
Frequently asked questions
Should each campus have its own management system?
No. Separate systems give you clean local operations, no group visibility, and every consolidated number assembled by hand. The right structure is one system with campuses as a scope inside it, so local teams work in their own view while the group sees everything.
Should we move off spreadsheets before or after opening the second site?
Before, if you can. Migrating one site's data is a smaller job than migrating two, and the second campus can then be created as a configuration of an existing system rather than a fresh spreadsheet stack that diverges from day one.
Do students need different ID numbers at each campus?
No, and giving them one is among the more expensive mistakes available. Site-specific identifiers guarantee duplicate records and split attendance histories the first time somebody transfers.
How do we report group numbers when campuses use different calendars?
Report on dates rather than calendar periods. If one site's term ends in June and the other's in July, "students active on 1 June" is comparable and "students active this term" is not. Keep the calendars local and the reporting definitions central.
If you are opening a second site this year and want to see what these decisions look like once they are set up properly, start a free trial of KMPUS and configure both campuses before either of them needs it.
