Selling school software as a monthly or yearly service sounds straightforward: choose a platform, set a price, and find customers.
Then the first school asks who will import its records. Another asks about backups. A teacher needs help during attendance, and the accountant wants to know why a payment has not appeared.
These are part of the service you are selling. Planning for them early helps you make promises your team can keep.
Define the service before choosing a price
Describe what a school receives from you in plain language. Which workflows are included? Who hosts the system? How much training will you provide? Where should staff ask for help?
Separate the standard package from optional work. Data cleanup, extra training sessions, special reports, and new integrations can take time. Decide how you will quote them rather than leaving every request open-ended.
Also confirm that your software license permits your intended subscription model. Review the InstiKit SaaS Business Edition with your target market and expected client scope in mind.
Give hosting a named owner
Someone needs to know whether the application is running and what to do if it stops. That person might be on your team or part of a managed hosting arrangement.
Before launch, agree who handles:
- Server setup and access.
- Application monitoring and alerts.
- Backups and recovery checks.
- Software and server updates.
- Storage, capacity, and third-party service accounts.
A backup is more useful when you know how to restore it. Practise recovery in a separate environment and document the steps. Decide what information you will give a school if service is interrupted.
For InstiKit's self-hosted SaaS offering, the application runs on your hosting account. Discuss technical requirements and installation assistance before choosing the infrastructure.
Test separation between school accounts
When several schools use a service, each school expects its information to stay within the agreed access boundaries.
Ask how the selected setup separates school records. Test with sample users from two schools, including administrators, employees, and parents. Check permissions, reports, exports, and account access. Also distinguish a group of related campuses from separate customer schools; the required setup and license scope may differ.
Do not treat a successful login as the end of this check. Ask the vendor to explain the deployment model your business will actually use.
Make onboarding repeatable
Prepare one short checklist for every new customer. It can include school details, classes, fee structures, user roles, sample records, training contacts, and a proposed start date.
For example, you could begin a pilot with attendance and one fee workflow. Once the staff can use those comfortably, review the next agreed module. The scope should follow the school's priorities and the package you sold.
Keep a list of common questions from each rollout. Those questions can become short help notes for future customers. The partner onboarding guide covers the package and responsibility discussions to have first.
Before the pilot, use a focused school ERP demo to check the customer's priorities and agree what you will test.
Price support as real work
Your subscription needs to cover more than the software license. Allow for hosting, staff time, customer onboarding, updates, and the services you include in the package.
Track how much time a school needs during setup and after it starts using the system. Keep one-time implementation charges separate from recurring service charges when that suits your offer.
There is no useful universal margin to assume here. Your costs depend on the package, the customer requirements, and how much of the service your own team provides. Build the calculation from your actual quote and operating costs.
Decide how support reaches you
Give schools one clear way to report a problem. Ask for the affected workflow, the time it happened, and enough detail to reproduce it. Avoid asking them to send passwords or unnecessary student records.
Your team should know which questions it can answer and which faults need vendor help. Confirm the vendor support scope separately from the support hours you promise customers.
Launch with a manageable pilot
Start with a customer whose requirements you understand. Review setup time, support requests, recurring costs, and staff feedback before adding more schools.
If you want to build a service around InstiKit, send a partnership inquiry with your country, delivery model, and expected number of customers. That gives the team a useful basis for discussing licensing and launch responsibilities.