Enrolment to alumni
Online registration, document checklists, verification, roll numbers, batch allocation, promotion, transfer and alumni records — one continuous student file.
Multi-tenant · one database per school
Run the whole school
Run the whole school
on one platform.
Admissions, academics, attendance, exams, fees, payroll, transport, library and parent communication — in a single system, with every school's records held in its own isolated database.
Arabic and English interface, right-to-left ready from day one.
The platform
One system instead of six disconnected tools
Most schools run admissions in one place, fees in another, timetables in a spreadsheet and parent messages in a chat group. Everything here lives in the same record, so a change in one place is visible everywhere it matters.
Fees that reconcile
Fee heads, groups, structures, concessions, late fees, instalments, partial and head-wise payments, receipts, cancellations and a day-closure ledger.
Academics and exams
Courses, batches, divisions, subjects, timetables, lesson plans, assignments, online classes, exam schedules, grades, marksheets and certificates.
Staff and payroll
Employee records, designations, work shifts, timesheets, leave allocation and requests, salary templates and structures, and payroll processing.
Daily operations
Transport routes and vehicle records, hostel allocation, mess menus, inventory and stock, library circulation, gate passes, visitors and enquiries.
Reaching parents
Announcements, email, SMS, WhatsApp and push messaging with delivery logs, plus a guardian portal, helpdesk tickets and complaint tracking.
Admissions
From enquiry to enrolled, without re-typing anything
A reception enquiry becomes an online registration, then a verified student record with a fee structure already allocated. Each stage is a permissioned action with its own audit trail.
- Public registration form with document upload, qualification history and guardian details.
- Staged review — verify, assign fee, request edits, reject with reason, or undo a rejection.
- Registration payment through a configured gateway, or skipped and recorded manually.
- Automatic roll numbers and batch/division allocation on approval.
Coverage
34 modules, grouped by the job they do
The number beside each module is how many API endpoints it exposes — a reasonable proxy for how deep the module actually goes. Nothing here is a roadmap item; these ship in the product today.
Student
265
Employee
200
Academic
167
Core
132
Exam
116
Finance
115
Transport
95
Inventory
76
Reception
73
Resource
53
Library
39
Hostel
30
Tasks
30
Communication
26
Helpdesk
21
Approvals
19
Assets
18
Calendar
18
Mess
18
Contacts
17
Blog
16
News
16
Authentication
16
Activities
15
Guardian
13
Forms
12
Recruitment
12
School site
10
Posts
10
Gallery
9
Chat
8
Discipline
6
Devices
5
Misc
4
Permissions
Everyone sees their own school, not everyone else's data
17 roles ship configured out of the box, each holding a specific permission set that is enforced on the server — not by hiding menu items. Roles are scoped to a campus, so a branch accountant never sees another branch's ledger.
School admin — 644 permissions
Full control of the school's own account: configuration, users, roles, academic setup, finance, payroll, backups and the public school website. No visibility into any other school.
Principal — 468 permissions
Academic and staff oversight across the campus: timetables, exams, attendance, discipline, approvals and reporting, without the finance and system-configuration surface an admin holds.
Teacher / staff — 80 permissions
Attendance marking, marks entry for assigned subjects, lesson plans, assignments, student diary and learning material — limited to the batches and subjects they are in charge of.
Accountant — 73 permissions
Fee collection, receipts, concessions, ledgers, transactions and day closure. Sensitive academic and HR records stay out of reach unless explicitly granted.
Guardian — 29 permissions
Their own children only: attendance, results, fee dues and payment, timetable, announcements, diary, leave requests and helpdesk tickets.
Student — 29 permissions
Timetable, assignments, learning material, online classes, exam schedule and results, library issues, leave and service requests.
Tenant isolation
Every school gets its own database. Not a shared table with a filter.
Most school platforms put every customer's students in one set of tables and rely on the application remembering to filter by school on every query. One forgotten condition exposes another school's records. Here the school is resolved from the hostname and the database connection is switched before authentication runs, so a missed filter has nothing to leak into.
- Database per tenant. The physical database is the boundary. Application bugs cannot cross it.
- Resolution before authentication. Unknown, unverified or suspended hosts fail closed rather than falling back to a default.
- Tenant-scoped everything. Cache keys, locks, rate limits, queued jobs, file paths, broadcasts and exports all carry the tenant identifier.
- No universal super-user. Platform operators use a separate guard; support access is time-limited, scoped, approved and fully audited.
- Custom domains verified by DNS before they route, with exact normalized host matching.
- Per-school backup and deletion. Offboarding removes one database and one storage prefix, not rows scattered across shared tables.
Availability, recovery-time and certification claims are deliberately absent from this page until monitoring, restore drills and an external security review produce evidence to support them.
Groups and branches
One account, many campuses
A school group signs up once. Inside that account it can run several campuses, each with its own staff, students, timetable and ledger — while group leadership sees the consolidated picture.
Account
The billing, legal and security boundary. One isolated database, one subscription, one set of custom domains. This is what a competitor can never see into.
Organisation
The education-domain grouping inside the account — a trust, a group, or simply the single school. Holds shared configuration and reporting.
Campus
A school, college, institute or branch. Users are assigned per campus and switch between the ones they are entitled to; permissions are evaluated per campus.
Mobile
A companion app for parents, students and staff
The mobile client is built on the same permissioned API as the web app, with local storage for reading attendance, timetables and announcements when the network drops.
- Arabic and English with full right-to-left layout.
- Local cache and an outbox so actions taken offline are queued and replayed.
- Per-school storage partitioning — one device can hold two schools without their data mixing.
In development — not yet released
We are not publishing store links, screenshots or offline guarantees until the client builds cleanly, passes its two-school isolation tests and completes a field trial. This section will state a release date once it exists.
Pricing
Priced per school, by size
Every plan includes all 34 modules, the guardian and student portals, Arabic and English, and an isolated database. Plans differ on capacity and operational commitments, not on withholding core features.
Placeholder figures.
These tiers illustrate the structure only. Replace every price, limit and currency with commercially approved values before this page goes live — publishing unapproved pricing creates a contractual exposure.
Pricing is not published yet. Contact us and we will quote against your campus count and student numbers.
Getting started
What the first term actually looks like
No school switches systems mid-year on a whim. This is the sequence we work through, and roughly where the effort sits.
Scoping call
Campuses, student and staff counts, academic calendar, fee structure complexity, and which existing systems have to be imported.
Provisioning
Your account, database, subdomain and first campus are created automatically. You get an owner login and a setup checklist.
Import & configure
Students, guardians, staff and fee structures are imported with a dry run and a validation report before anything is written.
Pilot then go live
One grade or one campus runs live first. Once attendance, fees and reports reconcile against your old system, the rest follows.
Questions
Frequently asked
Where is our data stored, and who can see it?
Your school gets a dedicated database. Other schools on the platform run against different databases and have no route to yours. Platform staff authenticate against a separate system and have no standing access to school data; support access requires an approved, time-limited, audited session.
Can we use our own domain?
Yes. You start on a subdomain such as yourschool.intellschool.com. A custom domain can be added once DNS ownership is verified; until verification completes, the domain does not route.
Does it work in Arabic?
Arabic and English are both first-class, including right-to-left layout throughout the interface, printed documents and the parent-facing portal. Users choose their own language independently of the school default.
Can we run several campuses under one account?
Yes. One account can contain an organisation with multiple campuses. Staff are assigned per campus and switch between the ones they are entitled to; group leadership can report across all of them.
What happens if we stop paying?
Access moves to a defined grace period, then to a read-only state that still allows export and billing. School records are not deleted because an invoice failed. Deletion only happens through an explicit, confirmed offboarding process after the retention window.
Can we get our data out?
Yes — structured exports by domain, with a manifest, schema version and checksums, so the export can be verified and re-imported rather than just downloaded.
How does it integrate with what we already run?
The platform exposes a permissioned REST API covering every module. Payment, SMS, WhatsApp and email providers are configured per school rather than shared across the platform.
See it running against your own numbers
Bring a fee structure, a timetable and a class list. We will show you what they look like in the system.