In development
Triage and referrals
How a learning support referral system can help inclusion teams sort new referrals and requests by urgency and next step, with a human decision and recorded reason.
Platform · Understand
A support request system for your college: one way in for learners and staff
A support request system for colleges and training providers: one way for learners, tutors and employers to ask for support, so no request is lost in email.
In short
A support request is the start of a learner's support record in Inclusion Studio. It captures who is asking, what they need and when, and passes it to triage. It is in development for the pilot.
A learner who needs support often has to ask more than once: to a tutor, then the front desk, then by email. Inclusion Studio is being built as a support request system for colleges and training providers, giving every request one clear starting point and a named owner. This page describes the planned design. It is in development for the pilot and is not yet available to try.
What problem do support requests solve?
In most providers, requests arrive through many doors. A learner mentions something to a tutor. An employer emails the apprenticeship team. A parent rings reception. Each route works for someone, but together they leave gaps: no record that the request was made, no one clearly responsible, and no way for the inclusion lead to see how long learners wait.
Delay matters. Under the Equality Act 2010, education providers have a duty to make reasonable adjustments for disabled learners, and that duty looks ahead rather than waiting for each individual to ask. How quickly and clearly a provider responds is part of whether support is effective. Read more in our guide to reasonable adjustments in further education.
Why does a college need a support request system?
A college needs a support request system so that every request is recorded, owned and answered, whichever door it came through. Without one, the inclusion team cannot see how many learners are waiting, how long they have waited or which requests have gone quiet. A single route also makes referrals from tutors, transition contacts and employers consistent, which helps when you later need to show how quickly support started.
How will a support request work, step by step?
- Someone raises the request. A learner can describe in their own words what they find hard or what they think would help. A tutor, assessor or other staff member can raise one on the learner’s behalf and say so.
- The system captures the basics. Who is asking, who it is about, course or programme, how the learner prefers to be contacted and any urgent date, such as an assessment or end-point assessment window.
- The learner’s words are kept. What the learner says is stored as their voice, not rewritten. See learner voice.
- An owner is assigned. The request goes to a named person, usually the inclusion lead’s team, with a due date for first contact.
- The request moves to triage. The owner decides what happens next. See triage.
- The requester is told. Acknowledgement is sent so the learner knows it has been received and who will be in touch.
What should a request form ask?
Less than most providers currently do. A good request asks what the learner finds hard, what they think would help, whether it is urgent, and how they want to be contacted. It does not demand a diagnosis, medical evidence or a parent’s signature as a condition of a conversation. Evidence can be gathered after a first discussion where it is actually needed.
Our support request form template shows a short version you can use today in any system.
Who sees what?
Server-side permissions, applied by organisation, relationship and field, decide who sees a request. The intended pattern:
| Role | Intended access |
|---|---|
| Learner | Their own requests and status |
| Inclusion lead and their team | All requests in their organisation that fall in their remit |
| Tutor or assessor | Requests they raised, and basic status for learners they teach |
| Apprenticeship employer contact | A request they raised about a workplace matter; not other requests about the learner |
| Organisation admin | Configuration, not request content by default |
Details of the request, such as health information, are treated as sensitive. See permissions and roles and our guide to special category data in education.
What is in the prototype today, and what is being built?
In the prototype: a fictional learner, Sam W., appears as a “New request” with a quote about managing course deadlines and a next step to arrange a first conversation. You can see how a new request looks in a priority list and in the learner summary. There is no form to create one.
Being built for the pilot:
- Learner, staff and employer request routes, switched on per provider.
- A short request form that works on a phone and with assistive technology.
- Acknowledgement messages, owner assignment and first-contact due dates.
- A request list for the inclusion lead showing age and ownership.
Not planned for the first pilot: automatic decisions on who gets support. People decide.
Who is this for?
Inclusion leads who want to know what has been asked and how long it has waited. Learners who want one clear way to ask. Tutors and assessors who want to pass concerns on without losing track. See the pages for tutors and assessors and inclusion leads.
What does this look like in practice? (fictional example)
Sam, a fictional Level 3 creative media learner, tells a tutor that deadlines are hard to manage and asks to talk about what could help. The tutor raises a request on Sam’s behalf and notes that Sam asked for it. The request records Sam’s words, the course, a preferred way to be contacted and no urgent date. It is assigned to a learning support adviser with a due date for first contact, and Sam is told who will be in touch. No diagnosis or evidence is asked for at this stage. The conversation comes first, and any evidence is discussed afterwards if it is needed. This is a fictional example, not a real learner.
Related guides and next steps
- Reasonable adjustments in further education
- Triage and support plans
- The pilot page explains how to take part.
Frequently asked questions
Who can raise a support request?
The intended design lets learners raise their own, and allows staff, such as a tutor or assessor, to raise one on a learner's behalf. Employer contacts could raise a workplace-related request. Providers will configure which routes they switch on.
Is a support request the same as a diagnosis or an EHCP?
No. A request does not require evidence of a diagnosis. Asking for support is separate from proving a condition, and providers should not ask for a diagnosis before a conversation.
Is this available in the prototype?
Not yet. The prototype shows a new request, for example a fictional learner who has asked to talk about course deadlines, but it has no request form.
Is this a referral system as well as a request form?
Yes. Staff can raise a request on a learner's behalf, which works like a learning support referral, and the learner can ask directly. Both go to the same triage list.
What stops a request being missed?
Every request gets an owner and a due date for first contact. Requests without an owner are visible to the inclusion lead. This is part of the design for the pilot build.
Sources and further reading
Official guidance changes. Check the source before relying on any detail, and take professional advice for individual cases.
Help shape the pilot
We are working with a small number of England FE colleges and apprenticeship providers first. Tell us about your learner support and we will be in touch.