Triage: a learning support referral system with a human decision

Once a request or referral arrives, someone has to decide what happens next. Triage is the part of a learning support referral system where that decision is made. In many providers that decision lives in one person’s head or inbox. Inclusion Studio is being built to make triage visible, quick to do and fair to review. This page describes the planned design for the pilot. It is in development and not yet available to try.

What is triage, and why does it matter?

Triage is the first decision about a support request: how urgent is it, who should talk to the learner, and what is the likely route? It matters because the first few days shape trust. A learner who hears nothing, or is asked to prove their need before anyone talks to them, may stop asking.

It also matters for fairness. If triage rules sit in individual habits, similar requests can get different answers. A visible record lets an inclusion lead check that urgent items are not waiting and that decisions are consistent.

What makes a good learning support referral system?

A good learning support referral system makes sure every referral reaches a person quickly, gets a clear decision and leaves a record of why. Referrals come from tutors, assessors, transition contacts, employers and learners themselves. Whoever refers, the system should show the learner’s own words, how long the referral has waited, the route chosen and who owns the next step. It should never let software accept or reject a referral on its own. In Inclusion Studio, referrals and self-requests start as support requests and land in one triage list.

How will triage work, step by step?

1. A new request appears in the triage list. The list shows the learner’s own words, course, any date pressure, such as an assessment or end-point assessment, and how long the request has waited.
2. A person reads it. The triage owner, usually from the inclusion team, reads the request and any attached information.
3. They choose an urgency and a route. Likely routes: arrange a first conversation, move to a support plan, link to an existing plan, refer to a specialist or another service, or signpost to other help. Providers will configure the list.
4. They record the reason. A short note explains the decision in plain language. This note is for staff and for audit, and the learner is told the outcome.
5. The first conversation is booked. The next owner is named and given a due date.
6. The learner is informed. The learner knows who will contact them and when.

What does a good triage rule of thumb look like?

The product does not decide thresholds for you, because they are a policy choice for each provider. Good practice often includes:

• Safeguarding concerns follow your safeguarding procedure, not the support workflow. Inclusion Studio is not a safeguarding system. See our safeguarding boundaries page.
• Time-limited events get priority. Examples include exams, assessment windows and end-point assessment dates. See end-point assessment reasonable adjustments.
• A conversation comes before paperwork. Do not hold a first conversation until a diagnosis letter arrives.
• A “no” is never silent. If the answer is not what the learner hoped, they hear it from a person with an explanation and alternatives.

Who sees what?

Triage involves sensitive information, so access is narrow. Permissions are enforced on the server, not by hiding buttons.

See permissions and roles.

What is in the prototype today, and what is being built?

In the prototype: a priority list for a fictional tutor shows learners ordered by what needs attention today or this week, with a status such as “New request”, “Awaiting tutor” or “Review ready”. You can switch between Today and This week and search by name, course, task or owner. That is a task list, not triage.

Being built for the pilot:

• A triage list with age, urgency and date pressure.
• Recorded route and reason for every decision.
• Reassigning and escalating to a named person.
• Reports for the inclusion lead showing how long requests wait at each stage.

Later or optional: AI-assisted summaries of long requests, if a provider chooses them. See AI drafts. Any such draft is labelled, reviewed by a person and optional.

Who is this for?

Inclusion leads and learning support managers who run the front door of support. Quality and compliance staff who need to show consistent, timely handling. See inclusion leads and quality and compliance.

What does this look like in practice? (fictional example)

Two requests arrive on the same Monday. One is from a fictional apprentice whose end-point assessment is in three weeks and who needs to discuss adjustments. The other is from a learner who would like help with note-taking, with no date pressure. The triage owner marks the first as urgent, routes it to a first conversation within two working days and links the assessment date. The second is routed to a standard first conversation. For both, the owner writes a one-line reason, the learners are told who will contact them, and the inclusion lead can see on the list that neither is waiting. This is a fictional example, not a real case.

Related guides and next steps

• Reasonable adjustments in further education
• Support requests and support plans
• Take part in the pilot.