Product guides
What an RFP should say about school management, ERP, and SIS
What an RFP should say about school management software: workflows, data, permissions, implementation, support, security, evidence, and commercial clarity.
Write around school decisions
Avoid a long list of module names that invites generic yes-or-no answers. Describe the workflow, actors, record, decision, exception, output, and acceptance test. State campuses, grades, calendar, family audiences, current systems, constraints, and phase-one boundary.
Ask vendors to demonstrate admissions to enrollment, student record to roster, attendance or assessment to family visibility, and fees to payment, receipt, and reconciliation.
Require evidence and boundaries
Require responses to label native behavior, configuration, integration, manual work, roadmap, and unknowns. Ask who owns migration, validation, correction, permissions, training, support, incidents, exports, and contract-end data.
- Data inventory, mapping, validation, and retention
- View, create, edit, approve, publish, and export roles
- Normal, incomplete, corrected, and denied-access tests
- Support, escalation, updates, and incident handling
- Assumptions, exclusions, growth, and variable charges
Include privacy and security
Ask what data is collected, for what purpose, who processes it, where it moves, which subprocessors are involved, how access is controlled, and how data is returned or deleted. GOV.UK guidance recommends early attention to data protection, access control, security, suppliers, breach notification, and end-of-contract handling.
The U.S. Department of Education data governance checklist offers a useful structure for quality, access, security, sharing, disposal, and monitoring. It does not replace local legal review.
Make scoring defensible
Publish the scoring method before responses arrive. Weight must-have workflows and control requirements separately from preferences. Keep evidence, risks, commercial assumptions, unresolved questions, and decision rights in one record.
A strong RFP narrows ambiguity. It does not guarantee fit; it gives the school a disciplined way to find out.
Make the next step specific
Use this guidance to improve one bounded part of what an RFP should say about school management software. Name the person who owns the decision, the record or workflow affected, the evidence needed, and the date for review. Keep the test small enough for operators to complete and specific enough for a later audit. Record the result, next action, and condition that would make the team revisit the decision.
Check the result against an ordinary case and one meaningful exception. If either case depends on undocumented knowledge, add the missing definition, training note, permission rule, or support route before calling the change ready.

