Once you’ve defined your goals and mapped your current environment, the next step is looking at what’s available in the market.
Choosing a school management system (SMS) isn’t just about comparing features. It’s about finding a platform and a vendor that will support your school over the long term. Whilst there are often many moving parts, the process doesn't have to be overwhelming. With extensive experience helping schools make the switch to a system that better suits their needs, we've put together a guide to help ensure your school has smooth sailing ahead.
In Part 1 of this series, we explored why schools may switch systems, how to identify goals and priorities, and how to prepare for a new partnership.
In Part 2, we'll discuss how to research and evaluate your options, how to request more information from vendors, and what you'll need to make the final decision.
It’s easy to start with functionality. Does the system do what you need? Can it handle your workflows? But many schools find that what looks good on paper doesn’t always hold up in practice.
Features only matter if they are delivered, supported, and improved over time. It’s not uncommon for schools to deal with promised roadmap items that never arrive, or systems that struggle to keep up with changing requirements and compliance. Over time, this leads to frustration and extra work for staff. That’s why it’s important to look beyond the feature list and understand how the vendor operates.
There has been a clear shift in what schools expect from their technology providers, and our blog explains this well: Building Partnerships- Relationship Driven Technology. It is no longer enough to supply software. Schools want a partner who understands their environment, is invested in their success, and is committed to building lasting relationships.
This includes ongoing support, structured implementation, and a genuine willingness to listen to feedback. It also means having confidence that the system will continue to evolve in line with school needs.
At The Alpha School System, this is built into the way our platform is developed. Schools are involved through Special Interest Groups, customer forums, roadmaps, and events like TASScon. These channels give schools a direct voice in shaping the product and help ensure that development priorities reflect real-world needs.
By now, you should have a good sense of your functional requirements and priorities. These are often tied to the reasons you’re considering a change in the first place.
For many schools, this includes reducing the number of systems in use, improving integrations, saving time through automation, or moving to a more modern, cloud-based platform. Others may be focused on improving reporting, strengthening security, or delivering a better experience for staff, students, and parents.
Whatever your priorities are, this is the point where they should be formalised into clear selection criteria. This gives you a consistent way to evaluate different systems and avoids decisions being based on surface-level impressions.
With your requirements in place, you can start looking at what’s available in the market. It’s worth taking the time to explore broadly, rather than limiting yourself to systems that look like what you already have. One of the biggest mistakes schools make is trying to replicate their current setup, rather than thinking about what could be improved.
Building a shortlist of at least three vendors is a good starting point. Even if you already have a preferred option, comparing multiple systems helps you understand the broader landscape and may highlight features or approaches you hadn’t considered.
Once you’ve narrowed your shortlist, the next step is deciding how you want vendors to respond.
Some schools move straight to demonstrations, particularly if they already have familiarity with certain systems. Others prefer a more structured process to ensure a fair and consistent comparison.
There are a few common approaches.
Each approach has its place. If you are open to different ways of solving a problem, a proposal may give vendors more flexibility to present ideas. If you have very specific requirements, a tender may provide a clearer comparison.
One challenge in this process is that responses are rarely straightforward.
Functionality is not always a simple yes-or-no. A feature might be part of the core system, delivered through an integration, or available via an API. In some cases, it may not exist yet but be planned for future development.
This is where it’s important to dig a little deeper. Understanding how a feature is delivered can be just as important as whether it exists. For example, TASS combines strong core functionality with a modern API program. This means schools are not limited to what is built into the system and can extend it to suit their needs.
When reviewing responses, it can help to categorise answers more clearly. Rather than just yes or no, consider whether functionality is native, supported through integration, partially available, or dependent on future development.
It’s also worth being cautious with development commitments. If something is listed as planned, ask about timeframes and how consistently similar commitments have been delivered in the past.
If you are using a tender-style approach, how you structure your requirements makes a big difference.
It’s important to keep each requirement clear and specific. Combining multiple requirements into one line can make it difficult for vendors to respond accurately and harder for you to compare results.
Breaking requirements into smaller, more detailed components gives you a clearer picture of how each system performs. It also reduces the risk of misunderstandings later in the process.
Once you’ve reviewed responses and refined your shortlist, the next step is demonstrations.
This is where you start to see how the system works in practice.
Demonstrations, combined with your evaluation criteria, should give you a clear sense of which system is the best fit.
Before making a final decision, it’s worth understanding how the system will be implemented.
Your SMS sits at the centre of your school, and the transition needs to be carefully managed. This includes data migration, integration setup, and staff training.
With TASS, schools are supported by a dedicated Professional Services team that guides the implementation process from start to finish. This structured approach helps reduce risk and provides clarity throughout the project.
It’s also important to allow time for testing. Integrations need to be reconnected and validated, and many schools choose to run trial data migrations to ensure everything is working as expected.
By this stage, you should have a clear understanding of your options and what each system offers. The right choice is not just about features. It’s about finding a system that fits your school, supports your goals, and is backed by a vendor you can rely on. Taking a structured approach to evaluation helps you make that decision with confidence.
In Part 3, we’ll look in more detail at implementation and how to ensure your school gets the most value from your new system.