Answers to the questions that come up

Yes. Enquiries, applications, document collection, seat allotment and admission confirmation are tracked in one pipeline, so a candidate's status is visible without a register or a spreadsheet.

Once an application is confirmed, the student profile is created from the details already captured, so nothing is re-entered by the office.

Where an institution runs multiple branches, admission enquiries and seats are managed per branch with the group able to see consolidated numbers.

Yes. Records are imported from your existing files rather than typed in again, and the module supports moving student data in bulk.

Grade advancement promotes students to the next academic level in one step, and the full academic and fee history stays attached to the same profile.

Roll number formats are configurable per institution, and ID cards are generated from the student profile.

Three: a single daily marking for the whole day, session-wise marking where the day has multiple sessions, and subject-wise marking for individual periods.

Attendance can be marked offline and syncs to the system when the device is back online.

Parents see attendance through their own login and receive notifications for absence and late arrival, so the office does not have to call home.

Academic sessions are defined first, then course groups, courses, batches and subjects are built under them, which is what every other module then reads.

Yes. Class teacher and subject teacher are configured separately, so a teacher can own a section and teach a subject in another.

Class timings and timetables are configured per batch with teachers, subjects and slots assigned to each period.

Yes. Examination configuration and grading are customisable, so grades, marks and pass criteria follow your institution's scheme rather than a fixed one.

Report cards are produced from the marks already recorded against each student, so the same entry feeds the card, the progress view and the analytics.

Progress tracking, topper reports and exam analytics break results down by student, subject and class, and can be exported.

Yes. The period grid is defined once for the academic year, then a subject, teacher and room are assigned per period for each class and section, so sections can differ.

Overlapping assignments are visible while the grid is being built, so a clash is caught before the timetable goes out rather than after.

Timetables are kept by academic year, so a question about a previous year stays answerable.

Each document is a template you design, so the school can issue bonafide, transfer, conduct, completion and any other certificate it uses.

Yes. Certificates are generated in batch for a class, and large print runs queue in the background rather than holding the browser open.

Every certificate issued is recorded against a reference, a date and the student, so a reprint or a query can be answered from the register.

Yes. Clubs and houses are set up with a coordinator, and membership rosters are kept current by academic year.

Prizes, positions and participation are logged against the pupil who earned them, so a pupil's history is complete in one place.

Participation can be summarised by class, by club or across a year.

Access is limited to the roles that need it, so a pupil's record is not general reading.

Yes. Each entry carries what happened, who reported it, the action taken and who was informed.

The incident history for a pupil can be exported for a parent meeting or a review.

Each certificate carries a unique reference printed on it. Anyone can confirm it from the public verification page without an account.

A revoked certificate fails the verification check immediately, which is what makes the check worth anything.

No. It confirms whether the document is genuine without revealing the student's record to the person checking.

Lesson plans, study notes and assignments are published for a class or batch, so students see the material for their own course.

Resources are attached to the subject and batch they belong to, so they follow the academic structure set up in the system.

Material published for a subject is available to the sections taking that subject, so it does not need publishing again for each section.

Fees are built from fee groups and fee heads, then allocated to students, programmes or transport routes, with concessions applied per student.

The fee due report lists outstanding balances, and the fee summary, transaction summary and daybook reports reconcile collection for the period.

Yes. Income, expenses and account-to-account transfers are recorded against accounts, so both sides of the ledger sit in the same system as collection.

Yes. Fee collection handles what parents owe; this keeps the school's own books — income and expenditure under the heads the school accounts by.

Income, expenditure and the position for any period can be printed or exported as a ledger.

Each entry can carry a numbered voucher, so the printed record matches what is in the system.

Yes. Components — basic, allowances and deductions — are defined once per grade and reused each month.

A run can cover every member of staff, or a subset when someone joins partway through a month.

A payslip is generated per employee and a full run can be printed together rather than one at a time.

Enrolment, fee collection, outstanding dues, attendance and academic performance are reported together, per branch and consolidated for a group.

Reports are exportable to Excel and PDF, which covers board submissions, trust reporting and audit requirements.

Reports are generated from the data already recorded by the other modules, so figures are current rather than prepared at month end.

Books are catalogued in the system with issue and return tracked against the borrower, so availability is known without checking the shelf.

Fines are recorded against the borrower's record on return, and overdue items are visible in the library view.

Issue history is kept against the student, so borrowing patterns are visible along with the rest of the student record.

Store items, purchases and issues are recorded in the module, covering stores, laboratories and general institutional supplies.

Issues are recorded against the requisition and department, so consumption can be traced back rather than guessed at stocktake.

Maintenance and repair of institutional assets are recorded alongside the asset, keeping service history with the item.

Vehicles and drivers are registered first, then routes and stops are created against them, and students are allotted to a route.

Transport is one of the fee allocation bases in the finance module, so a student's route determines the transport fee charged.

A student's route and stop form part of their record, which parents can see through their own login.

Visitor entries, enquiries and gate passes are recorded at the desk, so a visitor's arrival and departure are logged rather than kept on paper.

Enquiries taken at the desk are passed into the admissions pipeline, so a walk-in enquiry is followed up instead of being lost.

Gate passes are issued from the front office and recorded against the student, giving the office a record of early departures.

Yes, down to the individual bed — blocks, rooms and beds are all defined.

The bed is freed and can be handed to the next pupil without a gap in occupancy.

Occupied and free beds are shown together, so nobody has to count.

Blood group, allergies and ongoing conditions, held against the pupil's record.

Yes. A visit logged at reception reaches the same health record rather than a separate book.

Access is limited by role, and a record can be produced when it is legitimately asked for.

In folders, the way the office already keeps them, and each document carries a title, a type, an owner and the file.

Yes. A document is attached to the record it belongs to — a pupil, a member of staff, or the school.

Documents, contracts and certificates that are due to lapse are listed, so renewals are not missed.

A gate pass is issued for the pupil and closed when they return, so the gate and the office agree on who is out.

The on-site register shows staff and visitors together as they currently stand.

Card taps can record entry and exit automatically, and credentials are issued and managed per person.

Employee profiles, ID cards, department and designation, employee groups, categories and supporting documents all sit against one staff record.

Yes, attendance and leave management are part of the module, configured by employee category and group.

Payroll recording is driven by the pay heads configured against the employee, using the attendance and leave data already in the system.

Circulars and alerts reach parents, students and staff through the app, SMS, WhatsApp and email, chosen per message.

Messages are addressed by class, section or group, so a circular goes to the families it concerns rather than the whole institution.

Sent messages are logged against the recipients, so the office can confirm what went out and when.

Yes. A question set is built once and can be published more than once.

A survey can be published to a class, a section, the staff or the whole school.

Yes. Responses can be collected without attributing them, which is often the only way to get an honest answer.

Who they are, the year they left, what they went on to do, and their current contact details.

Donations are recorded against the alumnus who made them.

The register can be searched by name, year or batch and exported.

No. Every suggestion waits in a review queue for a person to accept, edit or reject it, and the system does not send, publish or change a record by itself.

Yes. Each generation is recorded along with who reviewed it and what they decided.

Read a paper document to pre-fill a record, draft a notice or letter from a short prompt, and surface patterns in the school's own data.

No. A dashboard shows only what the person opening it is permitted to see, and views are shared with a role rather than with everyone.

Views are saved and named, so a frequent report does not have to be rebuilt each time.

A view can be exported as a file for a meeting or a board pack.

The school profile, the academic year and its terms, classes and sections, subjects, grading bands and the holiday calendar — everything else builds on those.

Yes. The holiday calendar is published once and the rest of the system respects it.

Grade bands and the pass mark are configurable, and results are reported against them.

Yes. A backup of the school's data can be taken and restored when needed.

The licence screen shows the licence in force and exactly which modules it covers.

English, Arabic, Hindi and Malayalam.

Student billing is based on the number of active student records in the system. Records you archive at the end of a year are not billed. Parents, teachers and administrative staff accounts are never charged for separately.

Billing is monthly, and most institutions commit to an academic year so that pricing is fixed across the term. Exact contract terms are confirmed by the sales team.

Yes. Modules are switched on for your institution without migration work, because every module reads the same student record. Moving up a plan takes effect for the following billing period.

Prices are listed in US dollars. Invoicing in INR, AED and OMR is available for institutions in India and the Gulf — ask the sales team for local rates.

Your institution can export its complete records to Excel and PDF at any time, and a full data extract is provided at the end of a contract. Ownership of your institution's data always stays with you.

Yes. Modules are switched on as you need them, and because they share one student record, adding admissions or examinations later does not require re-entering anything.

Attendance and marks entry are built for a staff room: a teacher sees their own sections and subjects, nothing else. Onboarding and staff training sessions are part of implementation.

Student data is imported from your existing files rather than typed in again, and the import is done with you during onboarding.

Examination configuration and grading are customisable, so grades, marks, credit weightings and pass criteria follow your scheme rather than a fixed one.

Library cataloguing, issue and return with fines is a module, and hostel charges are handled as part of fee allocation. Hostel room allocation as a standalone module is not part of the current suite.

Staff records, designations, departments and employee groups are configured, so a department head sees their own staff and students while the office sees the institution.

Admissions run continuously rather than in a single window, and a mid-year enrolment joins an existing batch without disturbing its schedule.

Parents see their own child's marks and attendance through their own login, and can receive results by message when the test series closes.

Multiple centres run under one administration with branch-level roles, so each centre sees its own batches while management sees consolidated enrolment and collection.

Yes. Fee groups and heads are configured per branch or shared across the group, so a deliberate local variation is possible and an accidental one is visible.

No. Branches are added as they are ready; the consolidated reporting simply reflects the branches that are live.

Tenant data is isolated with role-based access and logged changes, and hosting and residency arrangements are agreed during onboarding.