What all-in-one should actually mean
Most systems that call themselves all-in-one are bundles: several modules under one login and one invoice. That is convenient, and it is not the point. An all-in-one school platform earns the name when information moves from one part to another without anyone retyping it: from curriculum planning to assessment, from assessment to reports, from attendance to the family portal, from a student record to every place that student appears.
You may see the same idea written as an all in one school platform or an integrated school platform. The words differ and the test does not: enter it once, and see it wherever it belongs.
The capabilities an international school may need
The list is long, and no school needs all of it on day one. A modern international school platform may include:
- Curriculum planning, in the terms of each framework the school teaches
- LMS functions: courses, assignments and homework
- Assessment and a gradebook that understands the school's grading scheme
- Student portfolios and reflection
- Reports and transcripts
- Attendance, timetable and calendar
- Communication with families: announcements and messages
- Admissions and enrolment
- Fees and invoicing
- Staff workflows, from records to leave and payroll
- Analytics for leaders
Why consolidation helps, and where it does not
Separate specialist tools create duplicate student records, separate logins, spreadsheet exports and disconnected reports. Consolidation helps by removing the seams, and the honest measure of it is how often staff re-enter the same information before and after.
It does not help everywhere. A single supplier is a single point of failure. No platform is the strongest available version of every module it contains, so a school with a beloved LMS and a working finance system may be better served by keeping both and connecting them. Depth matters as much as breadth, and the benefit depends on how well the modules share data, not how many there are.
What is different for an international school
International schools carry complications that a single-country school does not. They may run more than one curriculum framework, so planning and assessment have to cope with each in its own terms. Families are spread across countries, languages and time zones, which raises the bar for communication and translation. Fees may be paid in several currencies. Staff move between schools and countries, so handover matters. And data protection duties can come from more than one jurisdiction at once.
So the useful question is not whether a platform has a module for each of these, but whether it handles the difference: a unit in each framework you teach, a message in the language a family reads, a record that is easy to hand over and to erase.
Where skodle fits
This section names our own product, so weigh it accordingly. The test below is the one to put to us as well as to anyone else.
skodle is a single web platform with one login page, one session and role-based portals for staff, students and families. Behind it sit curriculum planning with IB programme structures, assessment and a gradebook, portfolios, reports and transcripts with a draft, approval and publish flow, daily attendance, timetable and calendar, behaviour and wellbeing, announcements, messaging and community forums, homework and courses, parent-teacher meetings, staff professional development, a general ledger and analytics for leaders, with AI drafting and a read-only copilot on top. See the product overview and the IB Engine.
Applied to skodle, the one-record test gives a mixed result. Modules do read the same roster: a student overview brings together attendance, released MYP grades, portfolio activity, published reports, behaviour, concerns and meetings. But the student is a reference by roster id rather than a database relationship, so a rename does not reach every module; a family is linked through one guardian email on the roster row; grades are held in more than one place (MYP tasks, course gradebooks and the school gradebook), and the cross-module views count MYP grades only; and one email address is one role in one school, so a teacher who is also a parent needs a second address.
The limits, in the order they are likely to matter. Fees and payroll are the newest parts: fee plans, invoices, manual payments and pay runs exist. A student is billed through the email on their roster row, so a student with no email there cannot be invoiced and a parent sees a child's invoices through that same link; payroll needs a salary structure created for each person; and card payments need the school's own Stripe Connect account. Confirm all three flows in a demo. Admissions is a stage-by-stage lead tracker, not an application record with documents. There is no period-by-period attendance, no library, transport, canteen or inventory module, no leave-approval screen and no native mobile app. Integrations with other systems are not working connectors, so anything you keep runs beside skodle with manual exports. A Cambridge syllabus is not modelled the way an MYP unit is, so IB, Cambridge and CBSE schools share the school structure and the assessment, attendance and reporting layers.
Pricing is per user, per month: $2 per user for up to 150 users, $3 from 151 to 500 users and a custom plan above 500, with parents at half the rate and every feature in every plan. Every new school starts with a free 30-day trial, so the fair test is your own data. See pricing.
The one-record test
The fastest way to test an all-in-one claim is to change one thing and watch where it lands. Change a student's class, or a guardian's email, and see which places update. Record an absence and see whether it reaches the family portal and the report. Create a unit and see whether its objectives appear in the assessment. If a change in one place must be repeated in three others, the product is a bundle, however tidy the login.
- Change a guardian's contact details once: where does it update?
- Mark an absence: who sees it, and where does it count?
- Record a grade: does it reach the report without an export?
- Add a portfolio entry: can it be found from the report and the unit?
How to evaluate, step by step
Start by mapping the tools you use now and what each does. Then identify the duplicate workflows: the same student data entered twice, separate gradebooks, several communication tools. Ask each vendor to demonstrate the flow of one real scenario across modules, from a plan to an assessment to a report to a family message. And compare total operational effort, the licences plus the staff hours spent moving information, rather than licence price alone.
If you are weighing a move, the project view is in school software consolidation, and the IB-specific comparison is in the IB school software buyer's guide.
What it really costs
The subscription is the visible part. The rest is migration, training, the term of reduced productivity while staff learn a new system, the cost of data you cannot export, and the cost of the systems you keep running in parallel. A cheaper licence that leaves three systems in place can cost more than a dearer one that replaces them, and the reverse is also true. Ask each vendor for a worked total for a school of your size.
Warning signs
A long feature list with no demonstration of data moving between features. Separate logins behind one brand. Integrations that turn out to be exports. Modules that share a menu and not a database. Unclear ownership of your data and no clear export. And a reluctance to say what the product does not do, which is usually a sign that the list is longer than the product.
