ShikkhaOS — School Management System

The build

Ask any school office what runs the institution and the answer is the same: a leather register, a spreadsheet, and whoever remembers to send the SMS pack. The data is real but the intelligence is not — absentees reach parents by memory, fee dues live in a notebook, and the report-card season eats a week of every teacher. ShikkhaOS is that office rebuilt as software the office can actually use: register-fast attendance, a fee lifecycle on real payment rails, a results engine that respects board grading rules, and parent messaging that never needs a human reminder — deployed on the school's terms, with an exit door that always stays open.

What we handled

• Attendance in register speed — tab order, shortcuts, offline-tolerant — with automatic parent notifications
• Fee lifecycle: invoices, bKash/Nagad payment links, receipts, overdue reminders, month-end reconciliation
• Results engine: per-board assessment splits and GPA rules, instant flagging, auto typeset report cards
• Bangla-first parent app as an installable web app — no store approvals, works on the phone they already own
• Admissions queue with document checklists — birth certificate, TC, NID — every pending paper visible at a glance
• The school owns the data: their server or ours with full export, formats documented, no hostage formats

The register is not the problem — the memory is

Almost every school in the country already keeps perfect data somewhere: the attendance register, the fee notebook, the mark sheets in the teacher's drawer. The failure is never collection — it is between the columns. A student is absent at 10:15 and the parent learns at 6 p.m., if ever. A fee is due on the 10th and chasing is a personal favor the office does on Fridays. Results week turns four teachers into a typesetting department. None of that is a digitization problem; the records are digital-adjacent already. It is a wiring problem.

So ShikkhaOS was scoped as wiring, not replacement: keep the register's speed and the office's habits, and let the system do what memory does badly — notify, remind, reconcile, typeset, audit. Every module has to pass one test: would a head clerk with a shared desktop and no training use it on day three? Anything that needs a manual is not done.

Five modules the office opens every day

Attendance is the spine. The class teacher enters exactly the way the paper register worked — roll numbers down the column, P/A/M for present, absent, marked-late — with keyboard-first flow and offline tolerance, because half the corridors lose signal between periods. The moment a student is marked absent, the parent message queue fires automatically; the reply — “hospital, certificate coming” — attaches to the student's row, not to someone's recollection.

Fees, results, communications and admissions sit on the same student graph: one fee invoice knows every sibling in the school; one late mark sheet blocks publishing but never punishes the other subjects; the admissions queue tracks documents (birth certificate, TC, parent NID) with the same checklist discipline the reception counter already uses. The office console is role-scoped — head clerk, accounts, class teacher, principal — each seeing one screen that fits their job, not an admin panel with nine hundred buttons.

The fee lifecycle is the actual ROI

Schools do not buy software for attendance; they buy it because of the fee notebook. ShikkhaOS puts the whole money loop on rails: invoices generated per class and sibling bundle, payment links over bKash, Nagad or SSLCommerz, receipts auto-issued, and the overdue list maintained by rules the school sets — grace days, reminder cadence, who gets the call. Month-end reconciliation matches gateway settlements against the ledger and shows the two rows that do not agree, because that is exactly where cash goes missing.

Collections are where a term pilot wins the staff over: the accounts teacher who spent Friday chasing slips finds the dashboard already knows who paid. That single conversion — from notebook anxiety to a progress bar — is why we quote the fee module in every pilot and why delinquency figures are something we measure with the school's own last-year numbers instead of quoting anyone else's.

Parents get one Bangla-first surface

The parent app is an installable web app, not a store download — no iOS bill, no Play review delay, and it opens on the mid-range Android every guardian already owns. Homework submitted, attendance at 96.2%, a fee card with one bKash button: three cards, Bangla and English in the same voice. It is deliberately shallow — notifications, confirmations, payments — because deep parent portals go unread; the parent will open a message that arrives, not a login they must remember.

Tone is engineered as carefully as flow: absent-student messages state facts and next steps, never blame; reminders are polite until they are firm, on the schedule the school chooses. A Bangla-speaking editor signs off every template before deployment — support register at a school is not a translation problem, it is a respect problem.

The school's data stays the school's

Deployments run on the school's own server room machine or on ours — their choice, in writing. The database is documented Postgres with a full export story: every table, every format, an annual fire-drill export the office can run without calling us. Report cards typeset server-side to printable PDF because that one artifact has to survive the software — in ten years the paper still has to match the database.

This is also our answer to the local ERP aisle, where the real product is the lock-in. We compete by making leaving cheap and staying convenient — and we are upfront that the offline-tolerant design has costs too: sync conflicts are resolved by keeping the register as the last word, and some cross-module analytics wait for connection rather than pretending.