Owned productEducation SaaSAI/MLWeb & mobileWhatsApp Business APIPaymentsOffline-first
Skoo: Building an AI school platform for payments, communication, and unreliable connectivity
Skoo is Xenova’s AI-powered school management platform for Pakistani schools. It brings administration, fee collection, learning workflows, parent communication, and multi-campus visibility into one system designed around local realities, not imported assumptions.
The problem
Schools often operate across disconnected registers, spreadsheets, messaging groups, and generic software. The fragmentation creates practical failures:
- Fee teams follow up after a payment is missed rather than identifying risk early.
- Parents are asked to check portals they rarely open.
- Staff lose access when connectivity drops or power is unreliable.
- Digital payments and school ledgers require manual reconciliation.
- English-only interfaces exclude users who work more comfortably in Urdu.
- Separate campus systems prevent leadership from seeing one accurate operating picture.
The challenge was not simply to digitise records. It was to design an operational platform that remained useful under the actual constraints of its market.
The solution
Xenova designed Skoo as a connected school operating system. Core workflows span admissions, student records, attendance, timetables, examinations, fees, accounting, HR, library, transport, parent communication, and multi-campus reporting.
The product combines those foundations with differentiated capabilities:
Early fee-risk support
An ML-assisted workflow analyses payment-history patterns and flags accounts that may need intervention before the next due date. Administrators can review risk and send a targeted reminder rather than treating every family the same.
Official WhatsApp automation
Attendance alerts, fee reminders, payment receipts, and results can reach parents through the channel they already use. Message templates, status handling, consent, and failure paths are treated as product workflows, not as a bulk-message shortcut.
Offline-first school operations
Selected mobile workflows continue when connectivity is unavailable. Local changes are protected and synchronised when the connection returns, reducing the chance that attendance or fee work stops at the moment it is needed.
Local payment methods
JazzCash and EasyPaisa support sits alongside cash, bank transfer, and cheque workflows, connecting payment events to the school ledger and parent receipt process.
Bilingual use
Urdu and English support is designed into interfaces and data entry, including local names, addresses, and remarks, rather than added as an afterthought.
A representative workflow
- 01The system reviews authorised payment-history signals on its scheduled cycle.
- 02A school administrator sees accounts grouped by risk for review.
- 03The administrator chooses an appropriate follow-up rather than automatically penalising a family.
- 04An approved WhatsApp template sends the reminder in the appropriate language.
- 05A parent follows a supported payment path.
- 06The confirmed transaction updates the ledger and triggers a receipt.
- 07Staff retain an auditable history of the workflow.
This is the value of joining AI to operations: the model does not sit in a dashboard for effect. It supports a specific decision and connects to the action that follows.
Architecture decisions
Design for intermittent connectivity
Offline-first does not mean storing everything everywhere. The team had to identify which workflows must degrade gracefully, how local data is protected, how queued changes are retried, and how duplicate or conflicting updates are resolved.
Keep communication event-driven
Attendance, invoices, payments, and results generate communication events. Separating those events from channel delivery makes status, retries, templates, and future channels easier to manage.
Treat payments as reconciled states
A click on “pay” is not a completed fee. The system must distinguish initiated, pending, confirmed, failed, reversed, and manually recorded transactions and apply idempotent updates so callbacks do not duplicate ledger entries.
Put humans around prediction
Fee-risk output helps an authorised administrator prioritise outreach. It is not presented as certainty and does not trigger punitive action without review. Model inputs, evaluation, drift monitoring, access, and retention sit under documented governance.
Build localisation into the system model
Bilingual interfaces affect layout, content, templates, search, exports, and support. Local payment types, phone formats, and school terminology are product requirements, not translation tasks.
Technology and delivery
laravelreactnext.jspostgresqlpython · mlreact mobile app
Skoo runs as a multi-tenant web platform. The application backend is built in Laravel with PostgreSQL as the system of record, a fit for the relational, audit-heavy data a school generates: enrolments, attendance, invoices, ledger entries. The web experience is built in React and Next.js, and school staff use a React-based mobile app for the offline-capable workflows described above.
The fee-risk prediction workflow is built in Python, kept separate from the main application so the model can be evaluated, retrained, and monitored without touching the operational system. The same team that designed the platform operates and releases it continuously.
Infrastructure specifics (hosting, queueing, and monitoring) are shared in technical discussions rather than published here.
Security and operations
Skoo runs with role-based permissions and auditable records of sensitive workflows such as fees and results. Security and compliance statements on this page are deliberately conservative: we publish specific claims (hosting architecture, backup and restore practice, and any regulatory alignment) only after internal security sign-off defines their scope and evidence.
Results
The product is live and publicly demonstrable. That alone is stronger proof than a concept screen: you can inspect a working platform, its feature depth, pricing, and onboarding route.
We publish customer metrics only with a source, a measurement window, and an accountable owner. Until then, the honest evidence is the product itself.
What this proves for clients
Skoo demonstrates that Xenova can combine product discovery, multi-role SaaS, mobile and web delivery, applied ML, payments, WhatsApp automation, localisation, offline operation, and ongoing product support in one production platform.
For a client, the transferable lesson is more important than the vertical: robust software comes from designing the full operating loop, including the exceptions that appear after launch.
See our software development services →Next case study: Xenwap →