What an RFP should say about school management, ERP, and SIS

Write around school decisions

A useful way to approach what an RFP should say about school management software is this: Turn an RFP into comparable workflow, evidence, implementation, security, and commercial responses.

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.

Choose the next step for what an RFP should say about school management software

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.

Choosing a whole-school platform for what an RFP should say about school management software

For a school evaluating what an RFP should say about school management software, the useful test is whether the workflow has a clear owner, a shared record, and a next step that can be measured. Use one calendar and one roster to coordinate the school year across teams.

The failure worth guarding against here is buying by module count, then discovering the modules do not share a calendar or a roster. Decide what the student record and the academic calendar is, and hold every candidate to it.

Write down the point at which what an RFP should say about school management software becomes a school-wide concern rather than a team preference, then test that definition with another owner.

• List the systems that currently hold a student record.
• Note which of them disagree, and on what.
• Decide which one should win when they do.