Product guides
School ERP vendor evaluation guide
A school ERP vendor evaluation guide for comparing demonstrations, evidence, implementation responsibilities, security questions, and total commercial assumptions.
Evaluate the connected workflow
Ask the vendor to demonstrate a single identity across admissions, roster, fees, attendance, assessment, and family visibility. Score whether the journey is complete, what requires approval, how errors are corrected, and what another team or family sees.
Repeat the test with an edge case. Use a duplicate applicant, a missing guardian contact, a class change, a fee concession, or an unpublished assessment. Real systems are judged by how they handle exceptions.
Separate evidence types
A screenshot, live workflow, configuration explanation, integration promise, roadmap item, and written contract clause are not equivalent evidence. Record which one supports each score and who still needs to verify it.
- Demonstrated now: observed by the evaluation team.
- Configurable: requires a defined setup and acceptance test.
- Integrated: depends on another system or provider.
- Manual: possible through a workaround with an owner and cost.
- Roadmap: not available for the phase-one decision.
- Unknown: blocked until the vendor or school provides evidence.
Ask security and data lifecycle questions
Ask what data is collected, where it is processed, who can access it, how staff access is controlled, how subprocessors are governed, how incidents are communicated, and how data is returned or deleted at contract end. Ask for appropriate independent assurance or documentation where relevant.
The school’s data protection officer and legal advisers should review the actual processing and contract. A content guide can organize questions but cannot certify compliance for a particular school or country.
Evaluate implementation as part of the product
Request a phase-one plan showing data ownership, migration checks, role setup, training, test cases, support, go-live criteria, and escalation. Ask who does the work and what the school must provide. A product that looks strong in a demo can still be a poor fit if the rollout model does not match the school’s capacity.
Make the recommendation auditable
Keep the evaluation pack, scores, recordings or notes, evidence register, commercial assumptions, risks, unresolved questions, and decision record. State why the selected option fits phase one and what remains a condition of approval. This gives leaders a basis for revisiting the decision when scope or evidence changes.
Assign an owner and due date to every unresolved question. A question without an owner tends to disappear into meeting notes; a question with a gate can stop a contract, configuration, or migration step until the school has a defensible answer.
Use the result after selection
The evaluation should become the implementation baseline. Carry the accepted scenarios, risks, roles, and evidence into configuration and testing. If the selected vendor proposes a different workflow, record the change and revisit the score rather than silently changing the requirement.
At the first review point, compare the promised workflow with the lived one. This closes the loop between buying content and operational reality, and it gives the school better evidence for the next phase or renewal decision.
Ask the implementation team to preserve the evaluation’s language for critical workflows. Shared wording reduces the chance that “supported” changes meaning between a sales demo, a configuration ticket, a training session, and a go-live decision.
A good evaluation record is also a training asset. New project members can see the reason behind a permission, approval, or data rule instead of treating the configuration as a collection of unexplained defaults.
When a requirement is deferred, document the interim process and its owner. “Later” is not an operating model; the school needs to know how the workflow works safely until the deferred capability is reconsidered.