Routes, students, boarding and transport fees.

There is no parent app. Parents receive messages from the office on WhatsApp or SMS, including not-boarded alerts, delays and fee receipts, never from the driver’s own phone. A live position on the route screen needs a tracking unit fitted to the bus, which is bought and installed separately. Geofence, over-speed and panic-button alerts are not part of this software, and a tracking vendor would have to supply them.

Yes, as long as the attendant marks the trip. Any child not marked as boarded sends a message to the parent’s number on the record, which the office can read afterwards beside the trip.

The attendant opens the trip on a phone and marks each child by name, stop by stop, because no RFID or QR card is used at the door. It works through a web page and needs a mobile signal, so on a stretch without coverage children are marked when the signal returns. We say this before you buy.

Yes. Fee is raised per term by the distance slab of the child’s stop, and parents pay online, by transfer or at the counter. Anyone riding without paying appears on the dues list. The bus fee carries its own receipt series rather than appearing inside one combined bill with tuition, so accounts can read it separately.

Yes, beside it. Buses, routes, boarding and the transport fee stay here, while your school management system keeps admissions and tuition, with neither touching the other’s records. No built-in link to a school management system exists, so any exchange of student lists is quoted as its own piece of work.

No client is named on this page. Before you commit, you see a demo running one of your actual bus routes, with its stops, pickup order and fee slabs already in place.

Through your accountant, yes. Collections by term, route and payment mode export for your accounting package, and a direct connection to it is separate work.

Yes, often more so. Your school keeps the student mapping, boarding record and fee, while the operator runs the vehicles, and both work from the same trip list.

The school does. Access is by role, so a driver sees a stop list and not a database, and the proposal covers a full handover.

No price is published. Buses, routes and how much must change for your terms and slabs decide it, together with GPS devices, wallet or gateway links and accounts export. Students and buses to migrate add work. You see a demo on one of your own routes first.

Stops along each route, buses with their papers, drivers and attendants, and student-to-stop mapping are what a term depends on, so they are set up and used first. Boarding attendance and parent messages follow. Fee collection, trip logs, upkeep and the location feed come after. The proposal carries dates.

Share the route and stop list, fee slabs by stop, the student roll with parent contacts, and the bus papers register. A boarding sheet, a trip log and a fee receipt show how it runs today. The transport in-charge, an attendant, the front office and accounts should be available. Details of fitted GPS devices are needed.