UK schools should evaluate EdTech software as a service (SaaS) as an operational, financial and governance decision, not as a feature demonstration. Before signing, a school should be able to explain the exact workflow being improved, the data being processed, the people who must approve the purchase, the evidence that will show whether it worked, and the practical route out if it does not.
That matters because the hardest part of buying school software often begins after the shortlist. The demo may be persuasive. The internal decision still has to survive the Data Protection Officer (DPO), information technology (IT) support, finance, accessibility review, staff who will use the system and the person who has to explain the purchase later.
The shortlist is not the decision
G2’s 2026 Buyer Behavior Report describes a wider B2B software pattern: evaluation is the longest buying stage for 40% of buyers, ahead of research at 36% and decision at 22%.[1] Its survey covered 1,038 global B2B software decision-makers, not UK schools, so those figures should not be treated as school-market statistics.[1] The useful lesson is narrower. Finding a product is becoming easier. Establishing that it is safe, affordable, implementable and worth renewing is becoming more important.
The Department for Education (DfE)’s Technology in schools survey gives us a better school-specific starting point. The 2025 wave covered 1,634 schools, including 795 leaders, 1,211 teachers and 489 IT leads. The survey was weighted to represent mainstream primary and secondary schools in England, and independent and special schools were outside its scope.[2][3]
The buying question for a school is therefore not simply, “Which platform has the most features?” It is, “Which supplier can help us improve a defined problem while giving us enough evidence and control to defend the decision?”
What the latest DfE data says about school technology buying
Three figures from the DfE survey deserve to be read together.
First, 49% of school leaders said their school or trust planned to invest in artificial intelligence (AI) tools for teachers over the next three years.[3] Second, only 22% said they had a formal evaluation plan or framework for monitoring the effectiveness of their technology.[3] A further 13% monitored effectiveness in other ways, taking the total with any plan or mechanism to 35%.[3]
Third, 86% of leaders were at least fairly confident in their school’s expertise to buy the right technology.[3] Confidence is useful, but it is not the same as having a post-purchase method for checking value.
A useful calculation hidden in the survey
The DfE figures produce a simple, transparent comparison. Stated intent to invest in AI tools for teachers was 27 percentage points higher than the proportion with a formal technology-evaluation plan.[3] Dividing 49 by 22 gives approximately 2.2 times as much investment intent as formal evaluation readiness.[3]
This is a survey-level calculation, not a new survey result. It does not show that the 49% and 22% describe different schools, and it does not prove that schools plan to buy AI without measuring it. It does show why evaluation should be written into the procurement decision before the contract starts. The public data contains more evidence of intended investment than of formal measurement infrastructure.[3]
A second calculation is also useful. The 86% of leaders who felt at least fairly confident buying the right technology was 51 percentage points above the 35% with any evaluation mechanism.[3] That is not evidence that confident buyers are making poor decisions. Buying and evaluating are different capabilities. The gap is a reminder to test both.
The practical implication is straightforward: a school should not approve a new EdTech subscription without agreeing what success will look like in the first term.
Start with the problem, not the product category
“Buy an EdTech platform” is not a useful requirement. It describes a category, not a school problem.
A better requirement has four parts:
- When does the problem occur? For example, during a pupil transition, an annual review, a parent meeting or a staff handover.
- What currently goes wrong? This might be duplicate entry, unclear ownership, missing evidence, weak search, late review activity or inconsistent documents.
- Who needs to do something differently? Include teachers, special educational needs coordinators (SENCOs), administrators, leaders, IT support, the DPO and the Designated Safeguarding Lead (DSL) where relevant.
- What evidence would show improvement? Define a baseline before the sales demo turns a vague pain into a vague promise.
For special educational needs and disabilities (SEND) teams, the distinction is important. A school may think it needs “SEND software” when the real problem spans several connected workflows: provision mapping, pupil passports, support plans, review evidence, reporting, handovers or the management of current records. Define which parts are failing, then test whether the supplier covers the whole journey rather than only one feature.
That does not mean every school needs a full management information system (MIS) replacement, a separate classroom-observation tool or a dedicated safeguarding system. Software cannot repair an undefined process. It can record one more layer of confusion very efficiently.
If the problem is specifically SENCO workload and repeated documentation, see our guide to how SENCO software should reduce paperwork without losing accuracy. This article goes one level earlier, to the decision about what kind of software a school should buy and how it should test the purchase.
Build the buying group before you build the business case
DfE’s digital leadership and governance standard says the senior leadership team (SLT) digital lead should connect technical staff, senior leaders, curriculum leads, the DPO, the DSL, business or finance professionals and trust IT leadership where relevant.[5] That is a useful description of the real school buying group.
The person who finds a product is not always the person who can approve it. A sensible EdTech procurement should identify:
- the operational champion who owns the problem;
- the SLT or headteacher who owns the strategic decision;
- the finance or business lead who checks value and contract terms;
- the IT lead who checks identity, access, support and resilience;
- the DPO who checks data processing and the Data Protection Impact Assessment (DPIA) position;
- the DSL where pupils can interact with the service or safeguarding information is involved;
- the SEND lead where accessibility or reasonable adjustment is material;
- the trust or local authority contact where the buying route requires wider approval.
This is not bureaucracy for its own sake. It prevents a common failure mode where a school chooses a tool on functional appeal, then discovers late in the process that it cannot approve the data flow, support the required users or export the records.
What to test in an EdTech SaaS supplier
1. Workflow fit
Ask the supplier to demonstrate the exact school workflow, not a collection of features. Use a realistic but non-identifying scenario and require the supplier to show what happens from the first action to the final record.
For a SEND management platform, that might mean importing an existing document, checking what mapped, reviewing warnings, creating or updating a support plan and pupil passport, mapping provision, assigning actions, completing a review and exporting the approved record. If the supplier can only demonstrate a clean new record, the test is too easy.
2. Data protection and data lifecycle
DfE guidance says schools should involve their DPO at the start of EdTech procurement, understand what personal and special-category data will be processed, assess the controller and processor relationship, identify sub-processors and agree security, deletion and return of data, breach notification and staff access control.[4]
Ask for a plain-English data map covering:
- what data enters the system;
- why each field is needed;
- where data is stored and processed;
- who can access it and under what role;
- which sub-processors are involved;
- how long data and backups are retained;
- what happens when a record is corrected, erased or exported;
- what changes when a new feature is introduced.
For AI features, ask how the supplier handles model training, prompts, outputs, moderation, inaccurate or biased content and human review. DfE guidance specifically expects suppliers to explain these areas.[4][8] The existing AI for SEND documents checklist covers those AI-specific questions in more detail. The point here is to make them part of normal procurement rather than a late technical appendix.
3. Interoperability and exit
A cloud product is not automatically a good cloud product. DfE’s cloud standard says schools should consider import and export before moving to cloud services. It expects secure encrypted transfer, export to an open or commonly used format, documented application programming interfaces (APIs) where relevant and a timely transfer process in a neutral format when a contract ends.[6]
Ask to see an export, not just a sentence promising one. Check whether the export contains the fields the school actually needs, whether documents remain readable, whether versions and dates survive, and whether the school could use the data without the supplier’s proprietary interface.
The same standard gives a useful reality check on availability promises. A service with 99% availability represents approximately 7 hours of downtime per month. At 99.9%, that is approximately 45 minutes, and at 99.99%, approximately 5 minutes.[6] A supplier’s availability target should be read alongside support hours, incident communication, planned maintenance, recovery arrangements and the importance of the workflow.
For SEND records, migration deserves particular attention because documents vary between local areas and schools. A supplier that claims every legacy file will convert perfectly is not being reassuring. It is avoiding the difficult part of the conversation. Read why unmapped content matters when schools import SEND documents before accepting a migration promise.
4. Accessibility and inclusion
DfE’s digital accessibility standard says accessibility should be included in technology strategy, procurement and support. It also expects schools to work with SEND leads, curriculum leads, admin staff, governors, IT support and the wider school community.[7]
Do not reduce accessibility to a statement on the supplier’s website. Test the workflows with the people who will use them. Ask about keyboard navigation, zoom, readable content, focus order, screen readers, captions, colour contrast, assistive technology and accessible exports where relevant.
Also ask what happens when accessibility features are enabled. DfE says systems should remain safe and secure when accessibility features are in use, and those features should not be blocked by generic security policies.[7]
5. Implementation and staff adoption
A cheap subscription that nobody uses is not good value. The DfE survey found that 61% of leaders felt technology had reduced staff workload over the previous three academic years, while 74% expected technology to reduce workload over the next three years. Those are perceptions, not controlled outcome measurements, but they point to the importance of implementation rather than purchase alone.[3] In the same survey, 71% of leaders with an evaluation plan or framework reported reduced workload, compared with 59% without one, a 12 percentage-point association.[3] That does not prove that evaluation caused the workload reduction. It may partly reflect better-resourced or more digitally mature schools, but it is another reason not to treat measurement as an administrative extra.
Ask the supplier to state:
- what the school must prepare before launch;
- which staff need training;
- how long a realistic first implementation takes;
- what data or sample records are needed;
- who owns configuration and permissions;
- how support is handled during the first term;
- how usage and value will be reviewed;
- what the supplier does not provide.
A serious supplier should be able to describe the first 30 days without pretending that implementation is frictionless.
Use a two-stage evaluation model
A school should evaluate the product twice.
Stage one: the procurement gate
Before signing, record the problem, users, data categories, required integrations, security questions, accessibility requirements, implementation assumptions, full cost and exit route. Ask the supplier to respond in writing so the decision is not based only on what was said in a demo.
Include the licence, implementation, training, support, storage, integration, migration and renewal costs. If the product uses usage-based or AI-related pricing, ask for a realistic low, expected and high scenario. Do not approve a cost model that the finance lead cannot explain to governors or trustees.
DfE says schools and trusts spend, on average, 20% of their budgets on non-staff costs and is developing further support around procurement of technology and other areas.[10] That is not a reason to cut every software purchase. It is a reason to make the value case specific and defensible.
Stage two: the first-term scorecard
Agree the scorecard before the pilot or contract begins. It should include a small number of measures such as:
- whether the intended staff can complete the target workflow;
- whether the current record is easier to find and identify;
- how much rework or duplicate entry remains;
- whether review dates, owners and changes are visible;
- whether staff confidence improves after training;
- whether support requests are resolved within the agreed service level;
- whether the data export and deletion process works as promised;
- whether the total cost still makes sense against the problem being solved.
Do not pretend that one term of usage proves improved attainment. The DfE and Office for Standards in Education, Children's Services and Skills (Ofsted) research on early AI adopters says evidence about long-term learning gains remains inconclusive, and it found that early adopters were curious but cautious rather than treating AI as a cure-all.[9]
AI needs a purpose, not a badge
The DfE’s Generative AI product safety standards tell suppliers to state the intended purpose and use cases of their products, avoid exaggerated claims, provide evidence, maintain appropriate privacy and data-protection arrangements, support permissions and activity logging, and address safety risks where relevant.[8]
That gives school buyers a practical test. Ask what the AI is for, what it is allowed to do, what it is not allowed to do, what data it receives, who reviews its output and how the school can detect a problem.
Ofsted’s early-adopter research interviewed leaders in 21 schools and further education (FE) colleges already using AI. It found that half of teachers responding to a DfE survey used generative AI, while among non-users 64% said they did not know enough about AI for their role and 35% were concerned about risks such as privacy, bias and safeguarding.[9] The study also found that AI leadership involved curriculum, IT, safeguarding, data management and teaching and learning, not one isolated department.
That is the sensible model for school SaaS. AI can be useful, but the product must make its purpose, controls and limits visible. A polished “AI-powered” label is not evidence of educational value, safe data handling or staff adoption.
Where MeritDocs fits
MeritDocs is a UK-based SEND management platform. Schools considering it should apply the same test described above: import a non-identifying sample, check the mapped content and warnings, run a real review workflow, and export the approved record. MeritDocs supports provision mapping, pupil passports, SEN Support Plans, profound and multiple learning difficulties (PMLD) plans, individualised education plans (IEPs), Assess-Plan-Do-Review workflows, reporting, migration and controlled records.
For example, ask a supplier to take a non-identifying pupil scenario from first review through to an approved plan, a visible review date and an export. That tells a school more than a feature list. Staff should still check the source information and approve the final record.
Schools should compare MeritDocs directly with their current platform on one real pupil journey: import existing records, create or update a plan and pupil passport, map provision, complete a review, inspect the history and export the result. The AI-powered SEND software buying guide covers the detailed product and governance questions, while this article covers the wider procurement, implementation and exit test.
A practical 30-day evaluation plan
Days 1 to 5: define the decision. Name the workflow, owner, users, current workaround, data categories, approval group and first-term measures.
Days 6 to 10: complete the evidence pack. Collect the Data Protection Act (DPA), data map, sub-processor list, security information, accessibility statement, support terms, pricing assumptions, export example and deletion process. Involve the DPO and IT lead early.
Days 11 to 20: test a real workflow. Use representative non-identifying data. Test the awkward parts: an incomplete record, a permission change, a staff handover, a correction, a review and an export.
Days 21 to 25: involve the wider buying group. Ask the operational champion, finance lead, IT support, DPO, DSL and relevant SEND or curriculum lead to record one unresolved concern each.
Days 26 to 30: make the decision and set the review date. Approve, defer or reject the purchase. If approving, record the baseline, owner, first-term review date, renewal decision date and exit requirements at the beginning, not when the contract is already renewing.
Questions to ask before signing
- What exact school workflow does this improve, and what is outside scope?
- What personal and special-category data does it process?
- Where is data stored and processed, and who are the sub-processors?
- Which access controls, audit records, backups and incident processes are included?
- What data can the school export, in which format, and with which version history?
- What happens to live data, backups and support access when the contract ends?
- What accessibility evidence can the supplier provide for the actual workflows?
- What must the school do to implement the system, and what support is included?
- Which measures will show value in the first term?
- What is the full cost under a realistic high-usage scenario?
These questions are not designed to create procurement theatre. They are designed to make the purchase explainable to the people who carry the risk after the demo.
Frequently asked questions
Do schools need DfE approval before buying EdTech SaaS?
The DfE publishes standards and guidance to help schools plan, procure and manage technology.[5][6] That is not the same as a blanket approval for every commercial product. The school remains responsible for checking fit, data protection, security, accessibility, implementation and value against its own requirements.[4][7]
Is cloud software automatically safer than software hosted on school servers?
No. DfE guidance describes potential benefits of cloud solutions, including resilience, maintenance and portability, but it also expects schools to check security, access, data protection, backup, availability and exit arrangements.[6]
Should every school buy AI-enabled software now?
No. A school should buy a tool because it solves a defined problem and can be governed, evaluated and afforded. AI may be useful, but the DfE and Ofsted evidence does not support treating an AI label as proof of improved learning outcomes.[8][9]
How will we know the software is worth keeping?
Ask what will be measurably better after one term and how the school will know. If the supplier cannot help define a sensible answer, the school is not ready to sign.
Final view
The best UK school EdTech SaaS purchase is not the platform with the longest feature list. It is the one that survives a realistic workflow test, a DPO and IT review, an accessibility check, a finance challenge, a first-term scorecard and a future exit.
The DfE evidence suggests that schools are confident enough to keep investing, especially in AI, but formal evaluation is less common than investment intent.[3] That is the gap worth closing. Buy less on promise. Test more of the real work. Put the evidence, ownership and exit route in place before the subscription begins.
Evaluating SEND management software for your school or trust? See how MeritDocs supports provision mapping, pupil passports, plans and reviews in one lean, AI-enhanced platform. Email contact@meritdocs.com or fill out the contact form.
Sources
[1] G2 buyer behaviour report; [2] DfE technology in schools survey; [3] GOV.UK technology survey data [3]; [4] Source 4; [5] Source 5; [6] Source 6; [7] Source 7; [8] Source 8; [9] Source 9; [10] Source 10.