A vendor opens the meeting with a slide deck: twelve modules, a dashboard screenshot, a client logo wall. Forty minutes later, the head teacher still doesn't know whether the system can produce a fee statement in the format their bursar already uses, or whether a mid-term transfer between classes needs a support ticket or three clicks. This is illustrative, not a description of any named vendor meeting — but it is how most school-software demonstrations run, and it is why so many schools sign a contract before finding out whether the product fits their actual term.
A useful demonstration does not follow the vendor's script. It follows the school's. This article gives head teachers, bursars, and school owners a repeatable way to test one real workflow — using fictional data — before comparing prices or committing to anything.
Name Your School Before You Compare Products
Before any vendor conversation, write down four things a generic feature list cannot capture:
- Country and regulatory context — the examination board, government reporting requirements, and payroll deduction rules that apply to your school specifically.
- School type and size — primary, secondary, or combined; day, boarding, or both; single campus or several.
- Academic calendar — term structure, billing cycle, and the dates that actually drive your admissions and fee collection.
- Decision team — who needs to see the demonstration before a decision is made: typically the head teacher, the bursar, and at least one teacher who will use the system daily.
A demonstration built around these four points will look different for a three-term day school than for a two-semester boarding school. If a vendor's demo doesn't ask about any of them, that itself is useful information.
Build a Fictional Learner Journey
Prepare one journey before the meeting, entirely fictional and clearly labelled as such: a new learner admitted, placed into a class, and carried through the opening of a term. Bring this scenario to the vendor rather than letting them bring their own.
Ask the vendor to demonstrate, using your scenario:
- Admission — how the learner record is created, and what information is required versus optional.
- Class placement — how the learner is assigned to a class, stream, or section.
- Term opening — how fees are generated for that learner under your school's own billing structure, not a generic example.
Watching a vendor work through your scenario, rather than their rehearsed one, is the single fastest way to see where the product's assumptions diverge from your school's reality.
Test the School's Own Billing Period, Attendance, and Reports
Once the learner exists in the system, extend the same fictional scenario through the tasks that repeat every term:
- Billing period. Does the system generate fees on your school's actual cycle — termly, monthly, or otherwise — with the fee items your school actually charges?
- Attendance recording. Can a teacher record attendance for your scenario's class in the way your staff would actually do it, on the devices they would actually use?
- Report output. Can the system produce the specific report your bursar or head teacher needs — a fee statement, an attendance summary, an examination result sheet — in a format your school can actually use?
A feature that exists in principle but produces a report your school can't use without reformatting is, in practice, a feature your school doesn't have yet.
Include One Exception and Ask Who Resolves It
Every real term produces exceptions: a learner transfers between classes mid-term, a fee entry needs correcting after the fact, a payment arrives late. Pick one and put it in front of the vendor during the demonstration.
The answer that matters isn't just "yes, the system supports that." It's who in your school is authorised to make that change, what approval or audit trail is left behind, and whether that person is the bursar, the head teacher, or a role your school doesn't currently have. A system that handles the happy path well and the exception badly will generate support calls every single term.
Check Roles, Export, Training, and Support With the People Who Will Use It
Before scoring anything, bring the actual users into the room — or the review — not just the decision-makers:
- Roles. Can access be restricted appropriately: a teacher sees their own classes, a bursar sees financial records, a head teacher sees the whole school?
- Export options. Can your school get its own data out in a usable format if you ever need to switch systems or share records with a government body?
- Training. What training is included, for which roles, and how long does it take a new staff member to become productive?
- Support and data handover. Who do you call when something breaks during the first week of term, and what happens to your data if you ever end the relationship?
These questions matter as much as any module list, and they are the ones a slide deck never answers on its own.
Score Every Requirement — Don't Just Remember Impressions
After the demonstration, walk through your list of requirements and score each one honestly:
- Demonstrated — shown working, against your own scenario, to your satisfaction.
- Partly demonstrated — shown in principle, but not against your specific case, or with a caveat.
- Not demonstrated — not shown, whether or not the vendor claims it exists.
- Follow-up required — needs a second demonstration, a reference check, or a written confirmation before it counts as resolved.
A scorecard filled in this way, on the day of the demonstration, is worth far more than a memory of how confident the presenter sounded.
A Term-Specific Demo Scorecard
| Requirement | School role | Sample record | Scenario | Expected result | Observed result | Exception | Evidence | Follow-up |
|---|---|---|---|---|---|---|---|---|
| e.g. Generate term fee statement | Bursar | Fictional learner, Class 3 | Term opening | Statement matches school's fee structure | ? | Late payment | ? | ? |
Bring this into the demonstration room, filled in as you go — with any real student information replaced by the fictional scenario throughout.
Where This Fits With Chwezi's Software Services
Chwezi's software team, including the Academia Pro school management platform, works from exactly this kind of term-specific scoping before recommending a configuration. A vendor's published feature list — including our own — describes the offer. It does not, by itself, prove fit for your school's calendar, examination format, or exception handling. That is what a demonstration built around your own scenario is for.
If you're comparing school-management systems, request a demonstration of one school term using fictional records and the scorecard above through Chwezi's software services.
Frequently Asked Questions
How long should a school-software demonstration take?
Long enough to walk one fictional learner through admission, class placement, term opening, one billing cycle, and one exception. A well-structured session usually needs 90 minutes to two hours, and may be split across more than one meeting.
Should the decision team include teachers, not just the head teacher and bursar?
Yes. The people who will use the system daily — a class teacher recording attendance, an exams officer entering results — should see the demonstration test their actual workflow, not only the administrative view.
Can national curriculum or exam-grading formats be assumed to transfer between countries?
No. Examination formats, government reporting requirements, and payroll deduction rules are country-specific and need to be confirmed for your country before you rely on them.
What if the vendor can't demonstrate our specific exception scenario?
That is valuable information, not a dealbreaker on its own. Mark it "not demonstrated" or "follow-up required" on the scorecard, and ask directly how the vendor's other clients currently handle that situation.
Two related articles are in preparation and will be linked here once published: a guide to preventing duplicate student records during admissions, and a guide to attendance follow-up that gives teachers and parents a clear next step.
