Toolkit
5 phases

Multi-Campus Implementation Toolkit

Running a multi-campus school group introduces a new layer of complexity to school management: data must be kept separate where necessary (each campus has its own students, fees, and staff) but aggregated where useful (group-wide enrolment statistics, consolidated financial reporting, and unified parent communication). RedeemOS supports multi-campus configurations through a hierarchical organisation structure, allowing a central administrative view alongside campus-level operational management. This toolkit guides the central IT or administrative team through planning, configuring, and launching RedeemOS across all campuses in a coordinated rollout that minimises disruption and ensures data integrity.

For: School group proprietors, executive directors, and IT managers responsible for implementing a single RedeemOS account across two or more physically separate school campuses operating under the same brand or group.

Before You Start

  • 1.RedeemOS Group/Multi-Campus subscription activated — confirm with the RedeemOS account team that your subscription tier includes multi-campus features
  • 2.A Central Implementation Coordinator (CIC) appointed at the group level who will own the rollout across all campuses
  • 3.A Campus Implementation Lead (CIL) designated at each campus — typically the campus administrator or deputy head
  • 4.Complete campus inventory: a list of every campus with its name, location, current student count, number of staff, and class structure
  • 5.Decision made on which data will be shared across campuses (e.g., common subject list, common grading scale) versus which will be campus-specific (fee structures, class groups)

Implementation Phases

Phase 1
Week 1

Group Architecture Planning

Before any configuration begins, the group must decide how RedeemOS will be structured across campuses. Decisions made now determine what is possible later, so they must be deliberate and documented.

Tasks

  • Map the organisational hierarchy: identify the group level (e.g., "Sunrise Schools Group") and all child campuses (e.g., "Sunrise Schools – Accra Campus", "Sunrise Schools – Kumasi Campus")
  • Decide on shared versus campus-specific configurations: which subjects, grading scales, and report card templates will be uniform across campuses, and which will vary
  • Define the reporting structure: which group-level reports does the Group Director need, and who at the campus level can generate reports for their own campus only
  • Define the permission model: which staff roles exist at the group level (Group Finance Manager, Group Academic Director) versus campus level only
  • Produce a one-page Configuration Blueprint document: organisation chart, shared elements list, campus-specific elements list, and user role matrix
  • Review the Configuration Blueprint with the Group Director and Campus Heads before any RedeemOS configuration begins

Tools / Modules

  • ·RedeemOS Group Management settings (review available options before planning)
  • ·Configuration Blueprint document (Word or Google Docs)
Phase 2
Week 2–3

Group-Level Configuration and Pilot Campus

Configure the group-level settings first, then fully implement and test on one pilot campus before rolling out to all remaining campuses. The pilot campus should be the smallest or most technology-ready location.

Tasks

  • Set up the group organisation in RedeemOS: create the parent organisation (group), configure the group logo and branding, and create each campus as a child organisation
  • Configure shared group-level settings: common subjects, common grading scale, shared report card template, and group-wide public holidays
  • Select the pilot campus and complete its full setup: class groups, campus-specific fee structure, staff accounts, and student enrolment
  • Run the pilot campus in live production for at least two weeks before beginning other campuses — use this period to discover configuration gaps
  • Document all issues encountered at the pilot campus and resolve them before proceeding
  • Get sign-off from the pilot Campus Head confirming the system is operating correctly for daily use

Tools / Modules

  • ·RedeemOS Group Management
  • ·RedeemOS Settings (campus-level)
  • ·RedeemOS Student Information System (SIS)
  • ·RedeemOS Finance Module
Phase 3
Week 4–8

Phased Campus Rollout

Using the pilot campus as a tested blueprint, roll out to each remaining campus in sequence — ideally no more than two campuses launching in the same week to avoid overloading the central support team.

Tasks

  • Clone the pilot campus configuration template to each new campus to replicate shared settings without manual re-entry
  • For each campus, complete campus-specific configuration: class groups, fee structure, staff accounts
  • Train the Campus Implementation Lead at each campus before student data entry begins — a four-hour training session per campus is recommended
  • Enrol all students at each campus (by CSV import if student data is available in spreadsheet form)
  • Verify fee invoices, class assignments, and staff permissions at each campus before declaring it live
  • Stagger go-live dates by campus: Campus 2 launches in Week 5, Campus 3 in Week 6, and so on — do not launch all campuses simultaneously

Tools / Modules

  • ·RedeemOS Group Management (campus templates)
  • ·RedeemOS Student Information System (SIS)
  • ·RedeemOS Finance Module
  • ·RedeemOS HR Module
Phase 4
Week 7–9

Group-Level Reporting and Dashboards

Once all campuses are live, configure the group-level management dashboards and reporting so that the Group Director and central team have the consolidated visibility they need.

Tasks

  • Configure the Group Director dashboard: set up consolidated enrolment overview (total students across all campuses), group-wide attendance summary, and group fee collection summary
  • Set up group-level finance reports: total fee revenue by campus, consolidated outstanding balance report, and group payroll summary
  • Configure cross-campus comparison reports: enrolment by campus, attendance rate by campus, and fee collection rate by campus
  • Set up automated weekly summary report to be emailed to the Group Director every Monday morning
  • Train the Group Director and central administrative team on using the group dashboard and requesting campus-level drill-down reports

Tools / Modules

  • ·RedeemOS Group Management Dashboard
  • ·RedeemOS Analytics and Reporting Module
  • ·RedeemOS Finance Module (group-level reports)
Phase 5
Week 10–12

Stabilisation and Continuous Improvement

The final phase focuses on resolving post-launch issues, establishing governance processes for the multi-campus configuration, and laying the groundwork for ongoing improvement.

Tasks

  • Conduct a 30-day post-launch review meeting with all Campus Implementation Leads to surface and resolve lingering issues
  • Establish a monthly multi-campus review call: Campus Leads, Central IT Coordinator, and the Group Director review system usage, data quality, and open issues
  • Document the configuration of each campus in a Master Configuration Register — this is essential when new campuses are added in future
  • Define a process for adding new campuses in future: who approves, who configures, who trains, and what the minimum lead time is
  • Review and update user permissions across all campuses: remove permissions for staff who have left, and add permissions for new staff
  • Schedule an annual group-level configuration review to align campus settings, update fee structures, and prepare for the new academic year

Tools / Modules

  • ·RedeemOS Group Management
  • ·Master Configuration Register (internal document)
  • ·RedeemOS HR Module (staff permissions audit)

Success Criteria

All campuses live on RedeemOS with correct student enrolment, staff accounts, and fee structures configured independently per campus

The Group Director can view a consolidated enrolment, attendance, and fee collection report spanning all campuses from a single dashboard

No cross-campus data contamination: students at Campus A cannot be seen or edited by staff with Campus B-only access

Each campus can independently process fee payments, take attendance, and generate report cards without requiring central support

The pilot campus has been operational for at least one full term with zero data integrity issues before the final campus goes live

A documented process exists for onboarding additional campuses in future without repeating the full planning phase from scratch

Frequently Asked Questions

Related Resources

Get expert implementation support

Our implementation team supports schools through every phase of this toolkit — book a demo to get started.