Enrolments and status management

A parent is asking why one sibling is active while the other is still pending. You have eleven requests left in the queue and a class that has reached capacity. Use this guide in that situation. It explains how Classia enrolment decisions, status changes, safeguarding checks, and payment expectations fit together so your team gives consistent answers under pressure.

Start with one real-world rule

Most enrolment issues are not caused by one wrong click. They come from inconsistent decisions by different staff on different days. Use one consistent approach: agree one decision model and follow it every time.

A reliable model has four rules:

1. Requests are reviewed in fixed windows, not randomly.
2. Status labels are defined in plain team language.
3. Child approvals never bypass adult linkage checks.
4. Payment timing is explained at approval, not chased later.

If you apply those four rules, support load usually drops within one term.

Enrolment lifecycle flow in Classia

Use this as your operational map.

1. A request is created and starts as pending.
2. If Classia detects a possible duplicate, the request must be resolved before approval.
3. A reviewer chooses one decision: approve, waitlist, or reject.
4. Approval moves the request to approved and sets enrolment status to active or trial.
5. Waitlist and reject decisions require a reason and set decision status accordingly.
6. Approved records then move through normal enrolment statuses: active, trial, paused, inactive, or back to pending when needed.

Enrolment lifecycle flow (structured text asset hook)

• Input: public or staff-created request with participant details, relationship, class, and enrolment type.
• Validation gate: account scope, class assignment, duplicate match state, child/adult linkage rules.
• Decision gate: approve, waitlist, reject.
• Record gate: create or link participant, family, responsible adult, and enrolment.
• Payment gate: assign or infer payment profile, build or recalculate payment schedule.
• Ongoing operations gate: attendance, status changes, arrears follow-up, and communication updates.

You can hand this text directly to a designer later if you want a visual flow diagram.

Queue ownership that works in small studios

In a typical UK dance school with one owner and one admin assistant, queue quality falls fastest when both people review "when they get a chance". Requests then sit for days, and parents receive mixed explanations.

Try fixed windows instead:

• 10:00 first review
• 15:30 second review
• 20:30 final pass for same-day submissions

If you only have one admin block per day, do one high-quality pass rather than many rushed checks.

During each pass, review in this order:

1. oldest pending requests
2. possible duplicate matches
3. classes at or near capacity
4. child requests missing responsible adult context

That order prevents the two messiest problems: stale requests and unsafe child records.

What approval really does

Approval is more than a status badge. In Classia it can create or link core records and trigger payment schedule creation. That is why rushed approval creates expensive cleanup.

When approving, reviewers should confirm three things first:

1. match state is clear
2. class capacity decision is deliberate
3. starting enrolment status is correct (active or trial)

If a class is full, Classia can still approve with a capacity override. Use that only when you have an explicit exception decision, not because the queue is busy.

Concrete friction moment: admins often tick override late to clear backlog, then spend the next day moving children between classes because the register is over capacity.

Waitlist and reject decisions that parents trust

Waitlist and reject are not soft outcomes. They should be explicit and explainable.

For both outcomes, include a clear reason. A short honest reason prevents repeated "just checking" emails.

Good waitlist language:

• "Class is full at 16 places. You are next in line if a place opens."
• "Age band is full this half-term. We will review again on 14 October."

Good reject language:

• "Requested class is for ages 7-9. Based on date of birth, next suitable group is ages 5-6 on Thursday."

Avoid vague wording like "not suitable right now". It creates follow-up questions and frustration.

Status control through the term

After approval, your team still needs disciplined status changes. Classia supports pending, active, trial, paused, and inactive.

Treat these as operational states, not notes.

• active: regular attendance expected.
• trial: short assessment stage before full commitment.
• paused: temporary break with expected return.
• inactive: participation ended for now.
• pending: requires active decision before regular participation.

When teams use these labels consistently, attendance and payment conversations are calmer because everyone is working from the same record state.

Safeguarding checks in child enrolments

Where children are involved, enrolment speed cannot outrun safeguarding checks.

Before approving an under-18 request, confirm:

1. responsible adult is present
2. responsible adult belongs to the same family context
3. class is suitable for age and supervision realities

If any of those are unclear, keep the request pending and resolve it first. A same-day delay is safer than a wrong approval.

Also keep permissions tight. Decisioning should stay with staff who are authorised for that account. Avoid sharing screenshots of child records in informal chat channels when clarifying decisions.

UK payment language to use at decision time

Studios lose time when payment expectations are explained late. Set it out when the request is approved.

Useful UK wording:

• "Direct Debit instructions are submitted on Tuesday and usually show by Thursday."
• "Card payment is immediate; if card fails, we will contact you with next steps."
• "Bank transfer is logged manually after funds arrive."

Where arrears appear, separate two different issues:

1. overdue scheduled amount
2. failed checkout attempt

Parents respond better when you explain which one applies.

Operational scenarios

Example: Dance school, 18 classes, 142 pupils

The school had 37 pending requests by week two. Two admins used different rules for trial versus active. They introduced fixed review windows and a one-line status definition sheet.

Within ten days, pending count dropped to 11 and register corrections reduced sharply.

Example: Martial arts club, 64 active students, class cap 20

One beginner class sat at 20/20. Admins approved three extra requests with override during a busy evening. Next week, coaches could not safely run sparring groups.

They changed policy: override requires same-day owner sign-off plus a note. Capacity decisions became consistent and complaints reduced.

What this is not designed for

This process is not designed for informal decisioning without traceable reasons. It is also not designed for bypassing child-adult linkage checks just to clear a queue faster. If your studio needs exceptions, document them explicitly and keep owner approval visible.

Related guides

• Enrolment statuses in practice
• From request to enrolment records
• Trials, pauses, and deactivations
• Public enrolment step by step
• Approve, reject, waitlist, and match resolution
• Payment schedules, arrears, and offline payments

Related feature

• Term-based enrolment software

FAQ

How often should we review pending requests?

At least once daily. Two or three fixed windows work better than ad hoc checks.

Can we approve from waitlisted status?

Yes. Classia allows processing of pending and waitlisted requests, as long as duplicate match issues are resolved first.

Should every rejection include a reason?

Yes. Clear reasons reduce repeated contact and help your own team stay consistent.

When do we choose active versus trial on approval?

Choose active for regular attendance from the start. Choose trial for defined short assessment participation.

What if a class is full but we need to place one learner?

Use capacity override only with an explicit exception decision and clear internal note.

Does approving a request affect payment setup?

Usually yes. Approval can trigger payment schedule creation, so payment profile choices should be correct before final approval.

Which page should we read next?

Read From request to enrolment records for the detailed approval-to-record sequence.