FAQ
Questions schools ask before they commit
Choosing, sequencing, migrating, budgeting, and getting staff and families to use it — plus a section collecting the questions where our answer is no.

40 questions
By topic
These are the cross-cutting questions that do not belong to a single module. Module-specific questions are answered on the module, integration, and comparison pages linked from each topic.
Choosing a platform
The questions that decide whether an evaluation reaches a good answer, rather than the ones a feature matrix can settle.
- How do we run an evaluation that actually tells us something?
- Bring three or four cases that do not fit a standard data model and ask to see them configured rather than described. The mid-year transfer with a partial academic history, the sibling discount that applies only to the second and third child, the student taking a subject with another year group. Every platform demonstrates the easy path well; these are where they differ. A demo that only follows the vendor script tells you the vendor can present.
- Who from our school should be in the evaluation?
- The registrar and one class teacher, at minimum, alongside whoever is deciding. A principal can judge whether reporting improved; only the registrar knows whether an admission got faster, and only a teacher knows whether marks entry is quick enough that they will stop keeping a spreadsheet. Those two roles determine whether the platform ends up holding the school record or merely appearing to.
- How much should the module count matter?
- Less than it appears to. Most schools run a dozen workflows daily; the rest of a long module list is unused configuration surface. Compare what you will use in term one, with your own data, rather than counting what exists. Where breadth genuinely is your requirement, some platforms in this category offer considerably more of it than we do and that weighs in their favour.
- What should we ask a reference school?
- About the first six weeks, not the year after. Every rollout looks tidy in retrospect; the useful window is when the office was still learning and families were being asked to change how they pay. Ask what broke, how long an answer took, which task got slower, and how much of the first term ran two systems in parallel.
- Is a longer requirements document a better one?
- Usually the opposite. A 200-line requirements matrix produces vendor responses that tick every line and tell you nothing, because almost everything is technically true of almost every platform. A short document naming your five hardest workflows and your go-live term produces answers you can actually distinguish between.
Rollout and sequencing
What order to adopt in, how long it takes, and which shortcuts get paid for twice.
- Which module should we adopt first?
- Whichever workflow currently costs your team the most hours — usually admissions or fees — but only after student identity and the academic calendar are configured. Those two are the denominator for everything else: attendance percentages, fee due dates, timetable slots, term boundaries on a report card. Configuring them after the fact means recalculating whatever has already been entered.
- How long does a full rollout take?
- Phased across three terms is the normal scope, not because the software takes that long to configure but because staff adoption does. Schools with clean data and a committed registrar move faster; schools migrating a decade of records move slower. Treat any single-weekend cutover proposal for a whole school with suspicion regardless of vendor.
- Can we run the new platform alongside our existing system?
- For a transition period, yes, and most schools do for at least a term. What to avoid is running both permanently for the same workflow, because the two records diverge and staff learn to trust whichever one they typed into. Set the date you switch the old process off when you plan the module, not afterwards.
- When should the parent portal open?
- After attendance and fee data are reliable, not before. The portal is the surface where errors in either become visible to families, and family confidence in a new platform is won once and lost once. A parent who checks a balance, sees a stale figure, pays the wrong amount, and has to sort it out with the office will not check again.
- What is the most common rollout mistake?
- Starting with the module causing the most pain before the roster is trustworthy. It is entirely understandable and it means the work gets done twice. The second most common is opening family-facing surfaces early to demonstrate progress, which converts an internal data problem into a public one.
Data migration
The part of the project that determines whether the first year is calm, and the questions nobody asks early enough.
- How much data cleaning should we expect before migration?
- More than you have budgeted for, and it is the highest-return work in the project. Duplicate students, guardians recorded under different spellings, and unclear payer-of-record are the three that cause the most trouble later. Run a trial import during evaluation specifically to find out which of these you have.
- What happens to historical academic records?
- That has to be decided before anything moves, not after. In several jurisdictions transcript retention for former students is a regulatory obligation rather than a preference, and a school that leaves historical records behind in a decommissioned system discovers this years later, when a former student asks. Establish where those records will live and who can issue from them.
- Why do duplicate records matter so much?
- Because they split everything downstream. A duplicated student appears in one class register and not another, receives one set of fee invoices, and carries half an academic history. By the time the pattern is noticed, months of attendance and marks exist against both records and merging them means deciding which history is real.
- What about fee balances?
- Agree the opening balance per family in writing before any financial data moves. This is the single most disputed dataset in a school migration, and the dispute is far cheaper to have in a spreadsheet in advance than with a parent afterwards.
- Can we get our data out again later?
- Yes, through the same Excel and CSV exports used day to day — roster, fees, grades, payroll, timetable, reports. Ask every vendor this question and be wary of an answer that routes through a support request. A platform that makes leaving difficult is telling you something about its confidence.
Cost and procurement
How the number is built, what it excludes, and why comparing headline prices is usually misleading.
- Why do you not publish prices?
- Because a published figure would mislead rather than inform: student count, campus count, and implementation effort move the number more than the module mix does. Some platforms in this category do publish itemised lists, and during budgeting that is a genuine advantage of theirs. What we will not do is publish an entry price that bears no relation to a working configuration.
- How should we compare vendor costs?
- Price the configuration you will actually run, not the entry tier. Where a platform prices modules separately, add every module you need — fee invoicing and finance are frequently add-ons — plus implementation at the published rate. Compare those totals. A headline price for a core module without fee collection is not comparable to a quote that includes it.
- What is usually missing from a first budget?
- Implementation and data preparation time from your own staff, which is the largest uncosted item in most school software projects. Payment gateway merchant onboarding also has its own lead time and sometimes its own fees. Neither appears on a vendor price list and both are real.
- Is open source cheaper?
- The licence is free; the deployment is not. Someone has to own upgrades, backups, security patching, and uptime, with allocated time rather than goodwill. If you have that capacity, the open source route is genuinely cheaper and gives you control a managed platform cannot. If you do not, the saving reappears as risk.
- What goes into a Schoolyi quote?
- Student count, number of campuses, which modules you adopt in phase one, and how much implementation and training support you want. We would rather scope that against your actual first term than quote a figure you then have to correct.
Data, security, and compliance
Where the data sits, who can reach it, and what a board or data protection officer will ask.
- Who can see a student’s record?
- Whoever the permission model allows, which is why the permission model is worth examining rather than accepting. The failure mode in schools is not a breach; it is a quiet slide into everyone being an administrator, starting with one person who holds two jobs and cannot be modelled. Reversing that means taking permissions away from colleagues, which is far harder than designing it correctly at the outset.
- Does any school data go to an AI provider?
- No. The optional AI assistant runs a local model on your own infrastructure, and there is no call to a hosted model provider in the product code. That costs capability — a small local model is materially weaker than a frontier hosted one — and it buys a clear answer to the question a board will ask.
- Can we keep data on our own infrastructure?
- Schoolyi is delivered as a managed platform, so no. Where self-hosting is a firm requirement, whether from a data residency rule or an institutional policy, an open source education ERP is the correct answer and we are not competing for that decision.
- Do you use single sign-on with Google or Microsoft?
- No. Sign-in is credentials, with magic-link email sign-in available for parents and students. If a mandatory SSO policy applies to your staff accounts, count this as absent rather than planned and weigh it accordingly.
- Can our IT team monitor platform activity in their own tooling?
- Yes. The activity log is available as an authenticated NDJSON feed and application errors can be posted to a webhook you nominate, so both route into whatever log pipeline you already run. There are no vendor-specific monitoring integrations, deliberately, because a generic feed works with the tool you already chose.
Go deeper
Staff and family adoption
The half of the project that is not technical, and where most platforms quietly fail.
- What makes teachers actually use the platform?
- Speed of marks entry and accuracy of the register. When either is poor, teachers do not complain — they use a spreadsheet, and the platform quietly holds an incomplete record while report cards get compiled from files on personal devices. Because the failure is silent and staff-led, it is often discovered a full term after it started. Time a real class set of marks during evaluation.
- How much training do staff need?
- Less for the workflows they perform daily and considerably more for the periodic ones — report card generation, promotion to the next academic year, examination entry. The daily tasks are learned by doing; the termly ones are performed under deadline pressure by someone who last did them three months ago, which is where written internal procedure matters more than training.
- How do we get families to use the portal?
- Give them a reason that recurs. Fee payment and results are the two that bring parents back; a notice board alone does not. Then make sure the data is right before you open it, because a family that finds a stale balance once will stop checking and tell other parents.
- What if a member of staff resists the change?
- Usually the resistance is specific rather than general — one task that got slower. Find out which, because it is often a configuration decision made without asking the person who does that task. Treating it as a training problem when it is a configuration problem is the fastest way to lose a registrar.
- Who should own the platform internally?
- A named person with allocated time, not a committee and not whoever is most enthusiastic. The role is real: deciding permissions, owning the academic calendar, being the person a teacher asks. Schools that leave this implicit end up with the registrar doing it on top of their job.
Curriculum and assessment
Where platforms differ architecturally rather than cosmetically, and where a mismatch cannot be configured away.
- Can one platform handle more than one curriculum?
- It depends on whether assessment is modelled or assumed. A platform that stores a percentage per assessment can present criterion levels only by converting them, which is lossy and pushes IB assessment back into teacher spreadsheets. Test your actual assessment model, with real criterion descriptors, rather than accepting a claim of curriculum support.
- What should an IB school check specifically?
- That criterion levels are stored as levels rather than converted through a percentage field, and that both can coexist on one record where you report criteria internally and a percentage externally. This is architectural rather than cosmetic, so it is rarely fixable by configuration after purchase.
- What should an IGCSE school check specifically?
- Per-student subject entry and tiering managed natively rather than in a spreadsheet alongside the platform. A cohort of two hundred students with individual subject and tier combinations tracked externally produces entry errors discovered when the series is already underway, and those consequences fall on individual students.
- How should GPA be configured?
- To match your published policy exactly, including how resits and non-academic subjects are treated, because the arithmetic encodes policy decisions. A GPA that disagrees with your handbook is a credibility problem rather than a rounding error, and correcting it later means restating figures already sent externally.
- Can a published result be corrected cleanly?
- Ask to see it done during evaluation, including what a parent sees before and after. This is the least glamorous test in an assessment evaluation and it prevents the most damaging category of problem, because a published mark that cannot be cleanly corrected becomes a formal complaint.
Where the answer is no
Collected in one place, because a school finding these out in month three is worse for both sides than reading them now.
- Does Schoolyi send automated SMS or WhatsApp messages?
- No. The SMS interface exists without a provider behind it, so SMS is not delivered. Fee follow-up builds a WhatsApp deep link a staff member sends from their own device, which is useful for defaulter chasing and is manual rather than automated. If automated messaging is a firm requirement, treat it as absent.
- Does Schoolyi post entries into our accounting software?
- No. There is no QuickBooks, Xero, or Tally connection. Fees, receipts, refunds, and payroll are held in Schoolyi with Excel and CSV export, and payroll produces Indian statutory formats. Moving those figures into your accounts is a file handoff your finance team performs.
- Are there mobile push notifications?
- No. The application installs as a progressive web app with an offline shell, which covers the "feels like an app" requirement but not the "buzzes the phone" one. Notifications appear in the application and by email.
- Is there an API for a third-party vendor to integrate against?
- Not as an integration surface. The application API is session-authenticated and documented, but there is no API key or OAuth client model for external systems. Programmatic data movement today means CSV and Excel. Raise it during evaluation if a partner needs to integrate on a timer.
- Do you publish customer numbers or named case studies?
- No count, and named references are provided on request during a shortlist-stage evaluation rather than listed publicly. Schools are careful about associating their name with a vendor, which is normal in this sector. There is also no aggregate rating markup on this site, because we have not earned one.

Question not here?
Tell us your workflow, your go-live term, and the two tasks costing your team the most time.
Already using Schoolyi? Sign in
