A group running more than one kind of institution — a school, a college, a coaching arm — needs a separate product for each, because a school student, a degree candidate and a coaching enrolee are different objects with different rules. TurtleDock provides four products on one platform, with shared infrastructure and deliberately unshared student records.
A trust running several schools, all of them schools, is a simpler case — that is one product across campuses rather than three products.
Groups that have grown across institution types almost always try one system first, and it almost always fails in the same way. A platform good enough for the school is forced onto the college, where a semester is not a term, a credit is not a subject, and a moderated result is not a report card mark.
The instinct behind it is right — a group should not run four unrelated vendors. The mistake is concluding that one system means one data model.
This is the part groups push back on hardest, and it is worth being precise about why we hold it.
Separate data models do not mean four disconnected purchases. What is genuinely common is built once.
Group-level reporting works where the things being compared are genuinely comparable, and stops where they are not. We would rather show less than produce a number that misleads a board.
| Rolls up across the group | Does not, and should not |
|---|---|
| Collections against target, by institution | A combined "student count" across a school and a coaching arm |
| Enrolment against capacity, by institution | An academic performance figure spanning boards and universities |
| Staff headcount and vacancies | Attendance percentages computed on different bases |
| Outstanding receivables and ageing | A single retention rate across different enrolment models |
| Audit and access exceptions | One student record following a person between institutions |
One institution at a time, starting with the one in most pain, rather than all of them at once in a summer break.
Phrased the way they arrive, answered so each one stands on its own.
They exist as two records, deliberately. The same young person may be a Class XI student at your school and an enrolee at your coaching arm, and those are two relationships with different rules, consents and billing. Merging them would misrepresent both.
Yes — one contract, one invoice and one implementation lead across the group, with each product priced on its own basis, since a school student per year and a coaching student per month are genuinely different units.
No. That is one product across campuses, which is the SchoolDeck group configuration — definitions at the trust, values at the campus. This page is for groups spanning different kinds of institution.
Yes. Identity is shared even though records are not, so a finance head covering a school and a college signs in once with permissions scoped per institution, and every cross-institution access is logged.
Checked by the Implementations desk on 7 September 2026. Corrections go in the page, dated, rather than quietly.
Pricing is on the page, in the open, with the counting rule written next to it. Nobody has to book a call to find out what it costs.
See pricingForty minutes with an implementation engineer — your classes, your fee heads, your grading scheme, entered as we go. No slides, no sample school.