School ERP RFP Checklist: What to Ask Vendors Before You Buy

A school ERP RFP is the document that decides whether you compare vendors on facts or on sales presentations. Schools that skip it usually end up comparing demos built around each vendor's strengths, with price lists that cannot be lined up against each other. Schools that write a clear request for proposal get answers in the same shape, from vendors who understand what the school actually needs.

This guide is written for principals, bursars, IT heads and trustees who are about to buy or replace a school management system. It covers what to include, the questions that reveal real capability, and a simple way to score responses.

What is a school ERP RFP?

A request for proposal is a structured document sent to shortlisted vendors. It describes the school, sets out requirements, asks the same questions of every vendor, and explains how responses will be judged. For a school ERP, it typically covers student information, admissions, fees and finance, academics and exams, communication, HR and payroll, transport, and reporting.

An RFP is not a wish list. Every requirement should come from a real problem the school has today, so that the answers tell you whether the problem will be solved.

Why should schools write an RFP instead of booking demos?

Demos show what a product does well. An RFP forces each vendor to address what your school needs, including the awkward parts: sibling discounts, mid-year transfers, multiple curricula, Arabic or regional language reports, or a fee structure with twelve instalments.

It also protects the school. A written answer to "Can you import our last five years of fee history?" is part of the record. A verbal "yes" in a demo is not.

Finally, an RFP makes the internal decision easier. Trustees and management can see why one vendor scored higher, on criteria they approved before any vendor presented. That shared record matters when the contract runs for several years and the people who chose the system may not be the people who live with it.

For schools that are still at the shortlisting stage, our guide to the best school management software explains how to build a shortlist first.

What should a school ERP RFP include?

Keep it short enough that vendors answer properly. Twelve to twenty pages is usually enough.

1. About the school: curricula, number of campuses, students, staff, grades, academic calendar and growth plans.
2. Current systems: what you use today and what data must move.
3. Scope: modules required now and modules planned for later.
4. Requirements by module: written as tasks, such as "Bursar issues a fee reminder to all parents with balances over 30 days in two clicks."
5. Data protection and security: the laws you must follow and the controls you expect.
6. Migration and implementation: timeline, responsibilities and go-live window.
7. Training and support: who is trained, how, and support hours in your time zone.
8. Commercial questions: pricing model, what is included, and contract terms.
9. Evaluation method: weights, scoring scale and timeline.
10. Response format: a table vendors must complete, so answers line up.

Which questions reveal real ERP capability?

Ask vendors to show, not tell. These questions separate mature products from slideware:

• Fees: "Show a family with three children, a sibling discount, a staff concession and a mid-term transport change. Show the parent's statement."
• Admissions: "Show an enquiry becoming an application, an assessment, an offer, a fee payment and an enrolled student without re-entering data."
• Exams: "Show marks entry for one class, moderation, and a report card in our format."
• Attendance: "Show how an absence alert reaches a parent and how the register is corrected."
• Year-end: "Show a promotion preview and how fee balances carry forward."
• Reports: "Build a report of fee collection by class and month while we watch."
• Parent access: "Log in as a parent on a phone and show what they see."

Ask for these demonstrations on a sample of your own data where possible. It is the fastest way to see whether the product fits.

What data protection questions belong in a school ERP RFP?

Schools hold sensitive data on children, so this section deserves weight. The applicable law depends on where you operate. In India, the Digital Personal Data Protection Rules, 2025 were notified on 14 November 2025 with an 18-month phased compliance timeline. In the UAE, Federal Decree-Law No. 45 of 2021 concerning the protection of personal data has applied since 2 January 2022 and includes provisions on breach reporting, data protection officers and cross-border transfer.

Ask every vendor:

1. Where is our data hosted, and can we choose the region?
2. Who at the vendor can access our data, and how is that access logged?
3. How are roles and permissions set, and can we limit staff to the data they need?
4. Is there an audit trail of who viewed or changed a record?
5. How do we export one family's data to answer an access request?
6. How will you notify us of a breach, and how quickly?
7. What happens to our data when the contract ends, and in what format do we get it back?

Our guide to school data security lists the technical controls in more detail.

How should pricing be requested in a school ERP RFP?

Ask vendors to price against the same scenario, so totals are comparable. Describe your school: students, staff, campuses and modules. Then ask for:

Our school ERP cost guide explains each of these pricing factors in more depth.

How do you score school ERP RFP responses?

Agree the weights before responses arrive, so the scoring is not shaped by the most persuasive presentation. A typical weighting for a school:

• Fit to requirements and demos: 35 percent.
• Data protection and security: 15 percent.
• Implementation and migration approach: 15 percent.
• Support and training: 10 percent.
• Total cost over the contract term: 20 percent.
• References from similar schools: 5 percent.

Score each item on a simple 0 to 5 scale, with two or three people scoring independently before you compare. Call references yourself and ask about the first term after go-live, not the sales process.

What mistakes do schools make when writing an ERP RFP?

The most common problems come from treating the RFP as a formality rather than a decision tool.

1. Copying a template without editing it: generic requirements get generic answers. Write requirements from your own processes.
2. Listing features instead of tasks: "fee module" tells a vendor nothing. "Issue a combined statement for a family with three children" tells them exactly what to show.
3. Leaving out the hard cases: multiple curricula, campus transfers, sibling rules and staff concessions are where systems differ. Put them in.
4. No data migration detail: say which data must move and how many years of history you need. Migration is where timelines slip.
5. Ignoring the people who will use it: involve the front office, class teachers, the bursar and the transport coordinator in writing requirements and watching demos.
6. Scoring after the demos: agree weights first, or the most polished presentation wins.
7. Not checking references: speak to schools of a similar size and curriculum, and ask what went wrong as well as what went well.

Avoiding these makes responses shorter, sharper and easier to compare, which saves the selection team time.

What timeline should a school plan for the RFP process?

A realistic timeline for a single school is ten to fourteen weeks from RFP to signed contract: two weeks to write it, three weeks for vendor responses, three weeks for demos and reference calls, and two to four weeks for negotiation and approval. Then plan implementation, which our school ERP implementation guide covers step by step. Aim to go live at the start of an academic year or term.

Hudace responds to school ERP RFPs with a written answer to every requirement and a demonstration of Hudace SchoolOS on the tasks the school names, so the selection team can compare like with like. You can book a SchoolOS demo or read the SchoolOS product overview before you send your RFP.