What an RFP should say about exams, gradebooks, and report cards

State the RFP outcome

An RFP should say what the school needs to decide and improve: configure an assessment, collect evidence, calculate a result, moderate, approve, publish a report, answer a family question, correct an error, or retain history.

Describe schools, campuses, programmes, subjects, cohorts, grading scales, assessments, users, calendars, reports, integrations, devices, accessibility needs, languages, support windows, and meaningful exceptions. Avoid vague requests for an all-in-one platform.

Specify verifiable requirements

For each requirement, include priority, user, scenario, input, expected output, calculation, permission, audit event, evidence, acceptance test, limitation, implementation responsibility, and support route.

Require suppliers to distinguish available now, configurable, dependent on another product, roadmap, manual, unsupported, or subject to a local policy. Ask for observed demonstrations using school-like data that is anonymised and proportionate.

Cover risk and exit

Include privacy, safeguarding, security, records, accessibility, data residency where relevant, retention, deletion, backups, restoration, incident response, subprocessors, integrations, role changes, reporting, training, support, and exit.

The U.S. Department of Education data governance checklist covers quality, access, security, lifecycle, sharing, disposal, and monitoring. GOV.UK school guidance is a public reference, not a universal legal answer; obtain qualified local review.

Make scoring defensible

Score functional fit, calculation accuracy, moderation, exception handling, usability, accessibility, security, privacy, implementation, migration, support, reporting, total cost, internal capacity, and exit—not presentation quality alone.

Keep the evidence, assumptions, conflicts, unresolved questions, acceptance gaps, and decision owner. Revisit the RFP after demonstrations, reference checks, pilot tests, and at 30, 60, and 90 days after implementation.

Make the next improvement testable

Use this guidance to improve one bounded part of what an RFP should say about school exam and gradebook software. Name the owner, assessment or gradebook record, evidence, correction route, and review date.

Check an ordinary case and one meaningful exception. If either depends on undocumented knowledge, add the missing definition, validation rule, permission, training note, or support route.

Record what changed, what remains manual, and who reviews the result before the next marking or reporting cycle.

Keep the decision beside its evidence so the next teacher or administrator can understand the rule without relying on informal memory.

Use the review to decide whether the change should be expanded, repaired, narrowed, consolidated, or held.

Recheck the boundary when a subject, campus, grading scale, role, integration, calendar, or policy changes.