Multi-campus operations
Running Multi-Campus School Groups: Centralised Control vs Campus Autonomy
Every school group eventually faces the same fork: centralise everything and choke campuses on head-office approvals, or grant autonomy and watch standards drift apart. The fork is false — but escaping it takes a governance model, not just a bigger ERP licence.
The false choice every group faces
Centralise everything, and the head office becomes the bottleneck: every concession, every refund, every timetable exception queues for someone two cities away who lacks the local context to decide well. Campus teams stop deciding and start escalating, and the group's pace becomes the pace of its busiest administrator.
Grant full autonomy, and drift sets in: each campus develops its own fee-head naming, its own definition of an active student, its own report formats. Nothing is wrong at any single campus — but at the group level, numbers stop adding up, and every board meeting begins with an argument about whose spreadsheet is right.
Most groups oscillate between the two poles, re-centralising after an audit scare, re-delegating after a bottleneck crisis. The oscillation itself is the cost: staff relearn processes, data models change mid-year, and institutional memory lives in workarounds.
What actually breaks at two campuses and beyond
The failure modes are remarkably consistent across groups, boards, and sizes. They are worth naming precisely, because a software evaluation should test against them.
- Definition drift: 'active student', 'defaulter', and 'admitted' quietly mean different things at different campuses, so consolidated reports silently compare unlike numbers.
- Reconciliation as a job description: someone at head office spends days each month stitching campus exports into one picture — and the picture is stale on arrival.
- Approval ambiguity: nobody can say, in one sentence, who may approve a concession of what size at which campus — so exceptions are either bottlenecked or invisible.
- Audit exposure: when records live in per-campus systems and spreadsheets, answering 'who changed this and when' takes an investigation instead of a click.
- Policy latency: a fee-policy change decided at the trust takes weeks to actually reach every campus's daily practice, if it fully arrives at all.
The model that works: policy at the trust, execution at the campus
The groups that escape the oscillation converge on the same structure. The trust level owns policy: fee frameworks, approval limits, academic calendar boundaries, data definitions, and access rules. Campuses own execution inside those guardrails: they run admissions, collect fees, mark attendance, manage staff, and make the local exceptions the policy explicitly delegates to them.
The connective tissue is accountability rather than permission-seeking. A campus does not ask head office to approve a routine concession; it applies the delegated rule, and the action lands on a shared, auditable timeline that the trust can inspect at any time. Escalation is reserved for genuine exceptions — which is what makes escalation meaningful again.
This is governance in the institutional sense: not surveillance of campuses, and not blind trust either, but delegated authority with visible execution. It is how well-run trusts already think; the problem is that most school software cannot express it.
What the model demands from software
Translate that governance model into system requirements and the vendor conversation becomes precise.
- One institutional data model: a student, a fee head, and a term mean the same thing at every campus, so consolidated numbers are aggregations — not reconciliations.
- Hierarchical, scoped access: trust administrators see the group, principals see their campus, and delegation limits are enforced by the system rather than by memory.
- Campus-level variation as configuration, not forks: where policy allows local difference, it is configured within the model — never by running a separate system.
- A single auditable timeline: every approval, override, and edit is attributable across campuses, so 'who changed this and when' is a lookup, not a project.
- Live consolidated visibility: the trust-level picture updates as campuses operate — attendance, collections, exceptions — without anyone preparing a pack.
Questions group leadership should ask any vendor
If you run or advise a multi-campus group, these questions expose in one demo whether a product models governance or merely multiplies logins.
- Show me a fee policy defined once at the trust and applied at two campuses with a permitted local variation. Where does the variation live?
- A campus admin tries to exceed their concession limit. What exactly happens — and what does the trust see afterwards?
- Show me group-level collections right now, then drill into one campus, one class, one student — without an export at any step.
- Add a new campus. What must be recreated from scratch, and what does it inherit from the trust?
- Show me the audit trail for one record that two different roles at two campuses have touched.
Where SquareCampus fits
This governance model is not a feature we added; it is the thesis SquareCampus is built on — trust-level governance with campus-level autonomy, on one governed system of record. Policies, approval chains, and data definitions are set once at the institution; campuses execute inside guardrails; and every action lands on the same auditable timeline that leadership reads live.
If your group is caught in the centralise-or-drift oscillation, the most useful demo is your own structure: bring your campuses, your fee frameworks, and your approval rules, and see the model expressed in software. And bring the five questions above — for us and for whoever else you evaluate.
See your group's structure in the system
Bring your campuses, fee frameworks, and approval rules to a guided demo — we will map trust-level governance with campus-level autonomy to how your group actually runs.