Who Should Own Your School's Systems? Defining Roles Before Go-Live
Why unclear ownership causes downstream chaos - and how to assign system accountability across IT, admin, and academic teams before a platform goes live.
One of the most common causes of long-term system underperformance in schools is not poor configuration or inadequate training - it is unclear ownership. When no one knows who is responsible for a system, everyone assumes someone else is handling it. Data goes unchecked, permissions accumulate without review, and support requests pile up because there is no internal first point of contact.
This article helps school admins and IT managers define system ownership before go-live, so that accountability is clear from day one. The principles apply whether you are launching ManageBac+, OpenApply, Atlas, SchoolsBuddy, or any combination of platforms.
System ownership is not about technical skill - it is about accountability. The system owner does not need to know how to fix every problem. They need to know who does, and to ensure that problems get resolved.
What System Ownership Actually Means
System ownership is the designated accountability for a platform's health, accuracy, and use. It is distinct from day-to-day administration or technical support. A system owner is responsible for:
- Ensuring the platform is configured appropriately for the school's current needs
- Coordinating with FariaSupport on issues, upgrades, and new features
- Overseeing user access - who has what permissions, and whether those permissions are current
- Communicating platform changes to relevant staff
- Serving as the internal escalation point when something goes wrong
Ownership does not mean doing all of these things alone. It means ensuring they are done, and knowing who is responsible for each component.
Recommended Ownership Structure by Platform
Different platforms serve different functions and therefore sit most naturally within different parts of the school. Use the table below as a starting point and adjust based on your school's size and staffing.
| Platform | Primary Owner (Recommended) | Technical Support Partner | Key Stakeholders |
|---|---|---|---|
| ManageBac+ | Registrar or Academic Coordinator | IT Manager | Heads of Department, Teachers |
| OpenApply | Admissions Director or Registrar | IT Manager | Finance, School Leadership |
| Atlas | Curriculum Coordinator or Deputy Principal | IT Manager | Heads of Department, Teachers |
| SchoolsBuddy | Activities Coordinator or Operations Manager | IT Manager | Finance, Pastoral Team, Parents |
In smaller schools, one person may own multiple platforms. If that is the case, document it explicitly - a shared but undocumented assumption is the same as no ownership at all.
Separating Ownership From Administration
It helps to distinguish between three types of system involvement, which are often conflated:
System Owner
Accountable for the platform overall. Sets priorities, communicates with FariaSupport, reviews access, and ensures the system is serving the school's needs. This role is typically held by a senior admin or coordinator.
System Administrator
Handles day-to-day configuration, user management, and technical tasks within the platform. Often IT, but may be an advanced admin user. Works closely with the system owner and FariaSupport.
Platform User
Uses the system to complete their own tasks - entering grades, processing applications, managing activities. Not responsible for configuration or oversight, but their feedback is essential for the system owner to understand how the platform is performing in practice.
These three roles can exist in one person in a very small school, or across many people in a large one. What matters is that each role is explicitly assigned, not assumed.
What to Document Before Go-Live
Before a platform goes live, create a simple ownership document that captures the following for each system:
| Field | What to Record |
|---|---|
| System Owner | Name, role, and contact details |
| System Administrator | Name, role, and access level |
| Backup Owner | Who covers when the primary owner is unavailable |
| FariaSupport Contact | The designated point of contact for support tickets and escalations |
| Review Cadence | How often ownership and access will be reviewed (recommended: annually) |
| Key Dependencies | Other systems this platform connects to, and who manages those connections |
This document does not need to be elaborate - a single shared spreadsheet or wiki page is sufficient. What matters is that it exists, is accessible, and is reviewed when staff change roles or leave the school.
Tips and Considerations
- Revisit ownership at the start of each academic year - staff roles change, people leave, and ownership that was clear in September may be ambiguous by the following January
- Avoid single points of failure - always name a backup owner so that if the primary contact is unavailable during a critical period, someone is empowered to act
- Include ownership in onboarding for new senior staff - a new registrar or IT manager should know from day one which systems they are responsible for
- Make ownership visible - a simple intranet page or shared document listing system owners removes the "I did not know who to ask" problem entirely
In Summary
- Every platform needs a named system owner before go-live - shared or assumed ownership leads to gaps in oversight and accountability.
- Separate the roles of system owner, system administrator, and platform user so responsibilities are clearly assigned at each level.
- Document ownership in a simple, shared format and review it annually or whenever staff change.
- Always name a backup owner to avoid single points of failure during critical periods.
Clear ownership structures make ManageBac+, OpenApply, Atlas, and SchoolsBuddy significantly easier to manage and support. FariaSupport works most effectively when there is a clear internal contact at your school to collaborate with.