How to run a 30-day pilot of school management software

When the walkthrough is over

A good demo answers one question: could this software run our office? It cannot answer the next one: will our people actually use it on a busy Monday, with the phone ringing and a queue at the fee counter? That is what a pilot is for.

Why pilots drift

Many pilots end without a clear answer. The software is set up, a few people sign in during the first week, and then the old registers win, because nobody decided what the pilot was meant to prove or when the decision would be made. Thirty days pass and the honest verdict is "we did not really try it".

Often the software was never really the question: the pilot had no plan.

A pilot is a test plan with a date

Treat the pilot as a short test plan: a list of tasks each desk must do in the new system, a way to check the results against what you already know, and a decision meeting on a fixed date. Everything below follows from that.

Before day one

• Decide the scope. Choose the modules, the classes and the desks. A pilot of two or three classes and one fee desk, done properly, teaches more than a half-hearted pilot of everything.
• Name two owners. One person at the school decides; one person at the vendor answers.
• Write a success test for each desk. For example: teachers mark attendance in the system on every working day; the accounts counter issues every receipt from the system; the front desk records every new enquiry.
• Ask the data questions first. Where will the pilot data be stored, who can see it, and what happens to it if you decide not to continue?

Week 1: set-up and logins

• Import the student list, staff and fee plans for the pilot classes, then check a sample of records against the registers.
• Give each person their own login. No shared passwords, even for a pilot: our guide to role-based logins explains why.
• Train each desk on its own work, not on every screen.

Check at the end of the week: can every person in the pilot sign in and find their own work without help?

Week 2: the daily work

• Teachers of the pilot classes mark attendance in the system every working day.
• The front desk records each new enquiry and its next follow-up.

Check: compare the system's monthly attendance for the pilot classes with the paper register. If they differ, find out why: it is often a rule, such as how a half day or a holiday counts, that the school had never written down.

Week 3: money and marks

• The accounts counter records the week's payments and issues receipts from the system.
• If a unit test falls inside the pilot, enter the marks in the grid and print a report card for checking.

Check: does the overdue list match what the accountant believes is owed? Can any balance be explained from the ledger, payment by payment?

Week 4: reports, exports and the decision

• Run the reports the principal actually reads.
• Export data as files, to prove you can get it out.
• Ask each desk for three lists: what worked, what had to change, what is missing.

On day 30, decide: continue, extend with one named fix and a new date, or stop.

What to count

Count things you can check yourself: on how many working days attendance was marked in the system, how many receipts were issued from it, how many corrections had to be made, and how many questions each desk could not answer from it. Be wary of percentages supplied by anyone else, including us.

How a Campus One pilot works

These are the terms and steps from the Campus One price list and brochure:

• A 30-day free pilot before any payment, for founding schools.
• It starts with a walkthrough of about 45 minutes, followed by a written plan of the modules your school needs first.
• Set-up: the team imports student, fee and staff lists from your registers or spreadsheets and trains the office and teachers. Set-up and data import are free with yearly prepayment.
• Modules go live in phases, each one as it is ready.
• After the pilot, founding schools pay only for modules that are ready to use, with 50% off the first year and today's price locked for three years. Prices are in Indian rupees and exclude GST at 18%.

What there is to test, honestly: admissions and records, attendance, exams and report cards, inventory and the exam paper generator are built; fees work without online UPI payment; parent messages are simulated, so nothing reaches parents; payroll, transport tracking, the parent app and the school website are planned. The admissions reports export as CSV files, and the fee importers let you download the rows that failed, fix them and import them again.

One more point matters before any pilot on real records. Campus One runs today with a made-up demo school, and real school data is loaded only after it moves to a server in India. The timing of a pilot on your own records depends on that move, so ask us about it for your school.

The takeaway

Agree the scope, the owners, a success test for each desk and the decision date before day one, and count only what you can check. The founding schools page sets out the Campus One terms, how it works shows the set-up steps, and our checklist for choosing school software helps you decide what to pilot in the first place. When you are ready, ask us for a walkthrough and a written plan.