RFP requirements for school management, ERP, and SIS

Write an RFP around school decisions

An RFP should help vendors respond to the school’s actual work. 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 the school context: campuses, grades, day or boarding model, academic calendar, family audiences, current systems, constraints, and phase-one boundary. Vendors need enough context to answer honestly, while the school needs enough structure to compare responses.

Requirements for connected workflows

Ask vendors to demonstrate priority journeys such as admissions to enrollment, student record to roster, attendance or assessment to family visibility, and fees to payment, receipt, and reconciliation. Include incomplete and corrected records.

Require a description of how the system handles identity, required fields, duplicates, approvals, publishing, exports, and audit history. Score evidence separately from a vendor’s statement that a feature exists.

• Native behavior available now
• Configuration required
• Integration or third-party dependency
• Manual workaround and owner
• Roadmap item
• Unknown or evidence still required

Requirements for data and access

Include data inventory, migration, validation, correction, retention, export, deletion or return, and ownership. The U.S. Department of Education data governance checklist frames lifecycle, quality, access, security, sharing, disposal, and monitoring as connected responsibilities.

Define role scenarios for teachers, academic leaders, finance, administrators, IT, families, and central or local campus teams. Ask who may view, create, edit, approve, publish, export, and administer each relevant record.

Requirements for implementation and support

Require a named plan for discovery, mapping, migration, configuration, testing, training, communication, support, and go-live. Tie dates to the academic calendar and state the critical failure that holds launch.

Ask for support coverage, escalation, documentation, update communication, incident handling, and responsibilities when the school cannot provide a specialist. A product response without an operating model is incomplete.

Requirements for privacy and security

Ask what data is collected, for what purpose, who processes it, where it moves, who accesses it, how subprocessors are governed, how incidents are communicated, and how data is returned or deleted. GOV.UK procurement guidance recommends involving the data protection officer early and reviewing security, access control, subprocessors, breach notification, and end-of-contract handling.

The RFP should request evidence without implying that a general certification or statement settles the school’s legal review. Local advisers determine the requirements for the school and its jurisdictions.

Requirements for commercial responses

Ask vendors to itemize campuses, users, modules, onboarding, migration, integrations, payment costs, support, training, renewal, data export, and changes caused by growth. Require assumptions, exclusions, variable charges, and the term on which each price is based.

Require the commercial response to map each cost to a requirement and an owner. Ask whether a charge is triggered by a user, student, campus, transaction, integration, storage threshold, support tier, or contract event. This makes growth and exception costs visible before the preferred supplier is selected.

Make the RFP scoreable

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 that a vendor is a fit; it gives the school a defensible way to find out.

Ask for a response against each acceptance test, not only a narrative overview. A useful answer names the configuration, data supplied by the school, expected user, exception handling, evidence available during evaluation, and recurring responsibility after go-live. Score an unknown as an unresolved risk rather than silently treating it as a yes.