Configure
Fee heads, class structure, grading rules and the academic calendar set up against your documents, not a template.
Four systems we have built often enough to configure rather than start again. That is why a rollout is measured in weeks instead of quarters — and why the awkward parts, the ones a first build always gets wrong, are already handled.
One student record that follows the child from the admission enquiry to the leaving certificate, with the office, the staff room and the parent all reading the same data.
Fee receipts are the part schools care about most and the part an auditor looks at hardest, so that module was hardened before anything else. Part payments, concessions, cancellations and reprints all leave a trail a chartered accountant can follow without a manual tally.
Grading rules differ enough between boards and universities that they are configured per institution rather than written into the code. A group running several branches uses one instance and reports across all of them.
The old registers stay in use until the new system has been proved against them. Nobody is asked to trust a migration on the strength of a demonstration.
Fee heads, class structure, grading rules and the academic calendar set up against your documents, not a template.
Student, staff and fee history imported and reconciled line by line against your existing registers.
Two to three weeks with both systems live, so any disagreement is found while the old one is still authoritative.
Sessions by role — office, faculty, head of institution — given to the people who will use it rather than to their manager.
Parent access is switched on last, once the data behind it has been checked, because that is the audience least able to forgive an error.
Each is configured to your process and extended where your process is genuinely unusual. Where it is not, you get the shorter timeline instead of a bespoke build you would have to pay to maintain.
A pipeline built around the stages your team already talks about, rather than a vendor’s idea of a sales process.
Enquiries arrive from the website, a phone log or a WhatsApp Business number and land in one queue with an owner and a next action attached. Nothing sits unassigned, and the ageing report makes it obvious when something has.
Ticketing with an SLA clock that stops for the right reasons, so the monthly report survives being read closely.
Intake from email, telephone and the web arrives in one queue. Priorities, pauses for customer response and out-of-hours windows are configured against your actual service agreement rather than a default, and escalation follows a matrix you have signed off.
A storefront with real inventory behind it, built on the assumption that one day you will run a sale.
Stock is held at checkout rather than at dispatch, so a busy hour does not oversell the shelf. Gateway settlements reconcile against orders automatically, and a return raises a credit note instead of an email to the accountant.
The distinction matters, so it is written here as plainly as it appears in the agreement.
Licensing is per instance — per campus for the school system — and renews annually alongside the maintenance contract. The licence covers upgrades, security patching and the modules listed in your agreement.
Everything you put in, and everything built specifically for you on top of the platform, belongs to you outright. A full export in an open format is available at any time, not only at the end.
We will load a sample of your fee structure, catalogue or ticket queue before the call, so you are looking at your own institution rather than a fictional one.