Why Inclusion Studio: support that learners recognise

This page explains the thinking behind Inclusion Studio. Everything here is a design goal, not a measured result. We have no customers yet, and we will not claim outcomes until real use supports them.

What problem are we trying to solve?

In many providers, support for learners follows a familiar pattern. A request is made, a meeting is held and a plan is written. Then it is filed. Weeks later, a learner says the adjustment never happened, a tutor says they did not know, or an employer says nobody told them. At review, the discussion relies on memory.

The gap is not goodwill. It is the follow-through: who does what, whether it happened, and whether it helped. That is hard to see across many learners, tutors, courses and employers, using documents and email.

What do we think good support looks like?

• It starts with the learner’s own words about what helps.
• The learner sees the plan, and disagreement is not hidden.
• Each action has an owner and a time.
• Delivery is recorded, including when it slips and how it was recovered.
• The learner is asked whether it helped, and support is kept, changed or stopped.
• Only the people who need to know see the details.

None of this is new. Good inclusion teams already work this way. Our guides on person-centred support planning and reviewing whether support worked describe the practice. The software is an attempt to make it easier to do consistently.

Why build for further education and apprenticeships first?

Because the problem is acute there and the duties are specific. FE and apprenticeship providers serve learners aged 16 and over with a wide range of needs, many with an EHCP or a history of support from school. Apprentices spend most of their time at work, so adjustments often depend on an employer who should not see the learner’s full history. We begin with England FE and apprenticeship providers and will validate separately before any school edition.

What makes this approach different?

We do not say it is better than every alternative. We say what it is built around:

1. The learner’s voice is the first thing in the record, not the last.
2. Agreed and disputed are both recorded, so a plan shows what was not agreed.
3. Missed support is a normal event with a recovery step, not a hidden failure.
4. Employers get a narrow view of workplace adjustments and their own actions.
5. Permissions are enforced on the server, not by hiding buttons.
6. AI is optional, labelled and human-reviewed, and the journey works without it.
7. Every capability is labelled honestly, as in the prototype, in development, planned or later.

What are the limits?

• The product is pre-pilot. The prototype holds fictional data only, and the production application is in development.
• Software supports a process. It does not make a provider compliant, improve inspection outcomes or calculate an inclusion score.
• It will not replace safeguarding, your student record system or professional judgement.
• A spreadsheet, a paper plan or a general system may be the right choice for you. We compare them honestly: spreadsheets, general case management and paper plans.

How will we know whether it works?

By measuring real use during the pilot: whether staff find it quicker, whether agreed support is delivered more reliably, whether learners say it helps, and whether it is accessible in practice. We will share what we learn, including what does not work. Recognition or awards are something evidence might support later, not something we claim.

How can you judge us?

Read the platform overview and see what is labelled as built. Try the prototype. Read our trust pages for security, data protection and AI principles, including what is not yet in place. Then ask hard questions: our guide to choosing learner support software lists some. If you want to help shape the pilot, start with the pilot page.