Product guides
Demo questions for school management, ERP, and SIS
The questions to ask in a school management software demo, organized around connected workflows, exceptions, permissions, implementation, support, and proof.
Prepare the demonstration
Send the vendor a small scenario pack and ask for the same demonstration every supplier will receive. Use controlled sample data and describe the school context, roles, campuses, calendar, family audience, and phase-one boundary.
Invite the people who own the work. Procurement can coordinate the session, but admissions, academics, finance, family support, IT, and leadership need to validate the workflows they will operate.
Questions about the connected record
Ask the vendor to follow one student from application through enrollment, roster, fees, attendance, assessment, report, and family visibility. Then ask what happens when the identity is duplicated, incomplete, corrected, transferred, or archived.
Ask how the demonstration data was prepared and whether the same behavior is available in the proposed phase. Request a written list of assumptions, required configuration, integrations, manual steps, and evidence that the school can reproduce after the meeting.
- Which record is the source of truth?
- Who corrects an error and how is it recorded?
- Which values are reused and which are derived?
- When does an approved value become visible?
- What does another team or family actually see?
Questions about permissions and publishing
Ask for view, create, edit, approve, publish, export, and administer scenarios for each critical role. Include a teacher, finance user, academic head, administrator, family, campus owner, and central owner where relevant.
Test a staff role change, leaver, campus move, corrected guardian, unpublished assessment, and pending payment. Negative tests reveal more than a successful tour.
Questions about implementation
Ask who owns discovery, data mapping, migration, configuration, testing, training, family communication, support, and go-live. Request acceptance tests, sample migration outputs, a timeline tied to the academic calendar, and a hold rule for critical failures.
Ask what the school must provide and what happens when it cannot provide a specialist. A realistic answer is more valuable than a short timeline that assumes unlimited school capacity.
Questions about security and data lifecycle
Ask what data is collected, how access is controlled, what subprocessors are involved, how incidents are communicated, and how data is returned or deleted at contract end. GOV.UK guidance recommends checking responsibilities, security measures, staff access, subprocessors, breach notification, and end-of-contract handling.
The U.S. Department of Education data governance checklist provides useful prompts on quality, access, security, sharing, disposal, and monitoring. The school’s privacy, legal, and security advisers must review the actual response and contract.
Questions about proof and boundaries
Ask the presenter to label each answer as available now, configurable, integrated, manual, roadmap, or unknown. Record the evidence and owner for every must-have. Do not convert a confident answer into an approved requirement without testing it.
Ask to repeat the scenario with a deliberately incomplete record and a user who lacks permission. Then ask what is logged, what the user sees, who receives the issue, and how the school confirms resolution. These tests expose the operating cost hidden by a smooth demonstration.
Separate product capability from implementation responsibility. A vendor may support a workflow while the school still owns data preparation, role design, approval policy, training, and reconciliation. Record both sides so that the demo does not become an incomplete project plan.
Close the demo properly
End with unresolved questions, commercial assumptions, risks, next evidence, and the decision date. Give each vendor the same opportunity to respond. The result should be a comparable record, not merely a set of impressions.
Send the written record to the people who own the affected workflows and give them a defined opportunity to correct it. Their review should confirm what was demonstrated, what was inferred, what remains unknown, and what must be tested before a selection decision.
