Questions to ask in a school platform demo

What decision must this demo help the school make?

Begin with one decision and one ordinary school-day scenario, and send both to the vendor before the meeting. A broad request to “show the platform” hands the agenda to the presenter and leaves the school with little it can compare across vendors. The question to answer is narrow: does what we saw justify a controlled pilot?

Decision

Whether a controlled pilot is justified, and for which workflows.

Scenario

A teacher records an absence, an authorised person corrects it, a parent or guardian sees the permitted update and an administrator produces the follow-up record.

Conditions

Year group, devices, connection quality, languages and the people involved.

A purchase is not a working workflow; anchor the demo to the problem. If the vendor cannot run the scenario as written, that gap is itself the first finding.

Is the vendor showing a concept, a demo configuration or a released workflow?

Ask the presenter to label every important item with one of four statuses before the school scores it. A polished screen can communicate an idea without proving that a school can use the workflow today.

Released in this offerConfigured for the demoIllustrative conceptPlanned, with a date

For anything called released, ask for the product name, version or release date, package or licence level, dependencies and written documentation, then have a second person repeat the action in the same configuration. For anything called planned, record the dependency and proposed date separately from the purchasing decision, and do not score it as if it exists.

The output is a claim register with evidence behind each line, not a folder of screenshots without context. Easy Edu’s guide on how to evaluate a school platform before you buy sets out the full status check, and the guide to checking which label is true gives the evidence for each label and three tests to run in the meeting.

Can the vendor show the same record through each relevant role?

Choose one sample record and follow it through each role view the vendor says is available. The school defines the roles it needs; the vendor demonstrates how the proposed configuration handles them. Use the grid below as the test script.

Then ask what happens when a student changes class, a staff member changes duties or an administrator delegates work temporarily. Easy Edu’s guide to evaluating teacher, student, parent and administrator access goes deeper on each role.

How are accounts created, changed, recovered and closed?

Ask for four short account tests, run live in the proposed configuration. Include temporary staff, leavers, transferred students and changed parent or guardian relationships, because these are the cases a prepared demonstration can leave out.

1. CreateAdd a user with the minimum intended access and show what they can and cannot open.
2. ChangeMove that user to a different role and confirm the old access has gone.
3. RecoverRestore a lost sign-in without bypassing the approval the school requires.
4. CloseEnd the account while keeping any record the school must retain.

For each test, note which tasks need a central administrator, which can be delegated and what evidence remains afterwards: the configured permission, the change history, who approved it and the result when a user attempts an action outside the agreed role. A verbal assurance is not evidence; a repeated test is.

What data, export, retention and deletion answers belong in the record?

Ask the vendor to name the data categories used in the scenario, their purpose, who can access them and where each answer is documented. Then ask for these answers in writing:

• A live export showing format, attachments, identifiers, timestamps and anything excluded.
• Who can request an export, how long it takes and whether a fee or service window applies.
• What event starts each retention period, and who approves deletion.
• How archived and backup copies are treated, and what evidence confirms deletion.

Malaysia’s Personal Data Protection Department publishes seven personal-data-protection principles and lists six data-subject rights in its public FAQ. They are general context: they do not decide which organisation holds which legal role in a proposal, so take advice on the actual contract. Easy Edu’s data ownership, export and deletion questions expand this list. Google for Education’s privacy and security centre shows the kind of administration and data-ownership topics a vendor can document publicly.

Does each claimed integration work in the proposed configuration?

A logo, marketplace listing or standards badge does not prove that the exact versions in the proposal work together. For every claimed integration, fill in this register during the demo:

Systems

The sending and receiving products, with versions.

Data and direction

Which fields move, in which direction, on which trigger.

Identity

How the same person is matched in both systems.

Failure

A safe failure caused on purpose: the error shown and who retries or reconciles it.

Maintainer

Who keeps it working after either product changes.

If a vendor names an interoperability standard, ask which version and services each product supports and request evidence for that exact combination. Do not infer support from a product category. An integration the vendor cannot run live during the demo stays marked as open in the register, however often it appears in the brochure.

What should the school record before agreeing to a pilot?

Close the meeting with one evidence register. For each important claim, capture the exact wording, status, product and package, evidence link or file, date, limitation, owner and next test. Mark unanswered questions as open; a verbal “yes” is not a confirmed capability. Ask the vendor to correct the record in writing if the school’s notes do not match what was intended.

Then define the pilot gate from that register:

• The workflows the pilot will test, taken from the claims marked released.
• Who may use sample data, and whether any real data is allowed.
• How issues are logged and who decides their priority.
• What counts as acceptable performance, and what stops the pilot.

A demonstration can justify further testing. It cannot prove implementation quality, user adoption or future service. The school software onboarding checklist picks up from here.