Choosing learner support software: a buyer's guide for FE

Buying software that holds learners’ support needs is a different decision from buying a general business tool. The records are sensitive, the users range from learners to employers, and the consequences of a poor choice fall on people who are already facing barriers.

This guide helps you choose well. It is vendor-neutral. It tells you how to define what you need, what to ask every supplier, how to compare fairly, and how to avoid common buying mistakes. Near the end we are honest about where Inclusion Studio stands, since you should apply the same questions to us.

What should you decide before choosing learner support software?

Decide what problem you are solving and who will use the system. Software cannot fix a process you have not defined.

Write down, in plain terms:

1. Your support journey. From first request to review. Where does it break today?
2. Your users and their permissions. Inclusion team, tutors, assessors, learners, employers, managers, admin, quality and DPO.
3. Your must-haves. For example: a plan the learner can see, delivery records, missed support recovery, reviews, controlled evidence exports.
4. Your constraints. Budget, systems you must connect to, timelines, accessibility requirements and data protection rules.
5. Your risks. What happens if the system is unavailable, wrong or breached?

Bring in your data protection officer, IT lead, safeguarding lead and, importantly, learners and tutors. A short demo with real scenarios will tell you more than a feature list.

What are the key questions to ask any vendor?

Ask every vendor the same questions in writing and compare the answers. The seven areas below cover most of the risk.

1. Data location and processing

• Where is the primary database hosted, in which country and by which provider?
• Which other services process personal data (sign-in, email, file storage, analytics, monitoring, support tools, AI)? Where?
• Do you provide a current list of sub-processors, and how will you tell us about changes?
• How do you handle restricted transfers outside the UK? The ICO’s guide to international transfers sets out the mechanisms.
• Is any personal data used for product analytics, support or marketing?
• Be wary of absolute claims such as “all data stays in the UK”. Ask for the detail behind them and for it in the contract.

2. Roles, permissions and access control

• Which roles exist and can we define our own?
• Is access enforced on the server by organisation, relationship and field, or only hidden in the interface? Hiding a button is not a safeguard.
• Can an apprenticeship employer see only the workplace adjustments and their own actions, not the whole record?
• Can a tutor see support for their own learners only?
• Is every view, change and export logged? Can we see the audit trail?
• How are joiners, movers and leavers handled?

3. Security

• How is data encrypted in transit and at rest?
• What independent assurance exists? Ask for certificates or reports in writing, and check what they actually cover. Be cautious of badges with no scope.
• How do you handle vulnerabilities, incidents and breach notification?
• How are uploaded files stored, scanned and released?
• Compare answers to the NCSC cloud security principles, which cover areas such as protecting data in transit, separation between customers, identity and authentication, and audit information.
• Does the supplier support the DfE digital and technology standards your college is working towards? See the DfE guidance.

4. Accessibility

• Does the product meet WCAG 2.2 level AA? What is the evidence: an independent audit, a conformance report or an accessibility statement?
• Can learners with a screen reader, keyboard-only use, magnification or voice control use the learner-facing parts?
• What are the known issues and the plan to fix them?
• Is there a way to report barriers, and how quickly are they addressed?

The W3C’s WCAG 2.2 is the reference. See WCAG 2.2 for education software for how to test claims.

5. Exports, integrations and leaving

• Can we export all our data, in open formats (such as CSV or JSON), at any time, without a fee?
• Can we produce a controlled evidence export for an audit, funder or inspector, limited to a set of learners and a period?
• What integrations exist with your MIS, learner records, virtual learning environment or HR systems? Are they live, planned or custom?
• What happens when the contract ends? How long until our data is deleted, and will you confirm in writing?
• Is there an API, and who owns the data we create?

6. AI features

• What does the AI do, exactly? Draft text, summarise, suggest, classify, decide?
• Which provider and model are used? Where is the data processed?
• Is our data or learners’ data used to train any model, by you or anyone else?
• Is AI optional, can it be switched off for the organisation, and does the product work fully without it?
• Is AI output clearly labelled and always reviewed by a person before it is saved or shared?
• Does it ever diagnose, refuse support or make decisions about a learner? It should not.
• Has a DPIA been done on the AI feature, and can we see the summary?

The ICO’s AI and data protection guidance is currently under review, so check its latest status. See our guide on using AI safely in learner support.

7. Contract, price and support

• Who is controller and who is processor? Is there a written data processing agreement that meets the ICO’s expectations on controller and processor contracts?
• What is the full price over the contract term, including set-up, training, integrations, storage, extra users and renewals?
• What are the term, notice and exit conditions? What caps price rises?
• What service levels apply for availability and support response times, and what are the remedies?
• What happens if the supplier is acquired or ceases to trade?
• How are product changes communicated, and can you opt out of new features such as AI?
• What training and onboarding is included?

For our own position on price, see pricing.

What data protection steps should you take?

Run a data protection impact assessment during selection. Learner support records contain health information, which is special category data (see the ICO explanation), and some learners are children or adults at risk. The ICO’s DPIA guidance says a DPIA is needed where processing is likely to result in high risk. Your DPO should decide, and early involvement is cheaper than finding problems after signing.

See DPIA for learner support software, the DPIA screening checklist and special category data in education. None of this is legal advice.

How should you compare vendors fairly?

Use a weighted scorecard and the same scenarios for each.

The weights are an illustration; set your own. Run two or three scenarios with each vendor, for example “a learner declines part of a plan”, “support is missed twice in a month” and “an employer needs to see only workplace adjustments”. Watch what the product does, not what the slide says.

What are the common buying mistakes?

• Buying a feature list. Choose for fit with your process.
• Accepting claims without evidence. Ask for documents, scope and dates.
• Skipping the DPO. Late involvement means late surprises.
• Not testing with real users. Include tutors, a learner and an employer contact.
• Ignoring total cost. Add-ons, storage and integrations add up.
• Locking in without an exit. Test an export before you sign.
• Treating AI as the headline. The core records and permissions matter more.
• Assuming the software ensures compliance. Software supports a process. You remain responsible for your duties under the Equality Act, the SEND framework and UK GDPR.
• Moving real learner data into a pilot without agreed safeguards.
• Disparaging alternatives instead of testing. Spreadsheets, paper, existing case management and specialist systems each fit some providers. See the comparison with spreadsheets for how we think about that choice.

A vendor question checklist

• ☐ Primary hosting location and every other processing location listed.
• ☐ Sub-processor list received, with change notification.
• ☐ Role and permission model tested, with server-side enforcement confirmed.
• ☐ Audit log demonstrated.
• ☐ Security assurance documents received and scope checked.
• ☐ WCAG 2.2 AA evidence received and spot-checked.
• ☐ Full data export tested; evidence export tested.
• ☐ AI behaviour documented and switchable; product works without it.
• ☐ Data processing agreement reviewed by DPO.
• ☐ Full cost, term, exit and deletion terms agreed in writing.
• ☐ DPIA started.

Where does Inclusion Studio stand against these questions?

Honestly, it is early. Inclusion Studio is pre-pilot. A clickable prototype with fictional learners exists. The production application is in development and uses synthetic data only. There are no customers yet and no certifications yet. Launch prices are on our pricing page.

What we can tell you today: the design is built around the Understand, Agree, Deliver, Review journey for England FE colleges and apprenticeship providers. The primary application database is hosted in London (Neon, AWS eu-west-2), and some supporting services such as sign-in, hosting and file storage may process data elsewhere; each will be documented and assessed before real learner data is used. Permissions are designed to be enforced on the server by organisation, relationship and field. AI is optional, labelled and human-reviewed. Gemini on Google Cloud Vertex AI is the selected AI provider, tested with synthetic data only; the location for real learner data is not decided, and no real learner data has been sent to any AI provider. Read the detail on our trust pages, the subprocessors page, the assurance roadmap, the roadmap and the pilot page. Please put these same questions to us. If you want to take part in the pilot, get in touch. Our comparison pages look at spreadsheets, paper plans and general case management fairly, and the FAQ answers common questions about Inclusion Studio.