You have approved a request in your head, but now you need the system to reflect that decision cleanly. This page covers how to turn queue decisions into reliable records in Classia without creating duplicates or payment confusion. It is written for busy UK studio admins who might process ten to thirty requests in one sitting. Follow this sequence and your registers, billing, and parent comms will stay aligned.
Examples
A dance school in Leeds had 14 pending requests on Monday evening. Two were possible duplicates, one class was already full, and three requests were for children whose parent records were incomplete. The owner tried to approve everything quickly before teaching started. By Thursday, they were fixing linked records and answering payment queries they could have prevented.
The change that helped was simple: process each request through the same checkpoints, in the same order.
Checkpoint order before any decision
Use this order every time:
- confirm request is still processable
- clear duplicate match state if present
- confirm child-adult context for under-18s
- choose decision and reason where required
- verify payment profile fit before final approval
Skipping a step usually creates cleanup in week two.
Step 1: confirm the request is processable
Classia processes requests that are pending or waitlisted. If a request has already been processed, it should not be treated as a fresh queue item.
Practical tip: filter queue views by status first, then work oldest to newest so families are not waiting silently at the bottom.
Step 2: resolve possible duplicate matches
If Classia marks a request as a possible duplicate, do not approve yet. You need to resolve the match first.
You can resolve by linking existing:
- participant
- family
- responsible adult
If the request is genuinely for someone new, use the confirm-new path to clear the duplicate warning. This prevents accidental duplicate participant records later.
Friction moment: match resolution takes a few extra minutes, but duplicate cleanup later can take hours when siblings and payments are already attached.
Step 3: confirm child safeguarding context
For under-18 participants, approval is not only a data action. You must confirm responsible adult context is correct and in-family.
Before approval, verify:
- responsible adult exists
- adult belongs to the right family context
- participant age fits the class
If one of these is unclear, keep the request pending and resolve it. A delayed approval is better than a wrong safeguarding record.
Step 4: choose decision deliberately
Classia supports three queue decisions: approve, waitlist, reject.
Approve
On approval, select enrolment status as either active or trial. This is required for approval and it affects attendance and payment handling immediately.
If the class is at capacity, you can still approve by enabling capacity override. Use override only when you have a clear exception decision.
Waitlist
Waitlist keeps the request alive but not confirmed. Include a reason so families understand next steps.
Reject
Reject ends the request pathway for that class. Include a clear reason with respectful language.
Step 5: understand what Classia creates or updates on approval
Approval can do several things in one flow:
- link existing or create participant records
- link family and responsible adult where needed
- create or update enrolment record
- set request decision fields and processed metadata
- assign or infer payment profile where possible
- build or recalculate payment schedule
That is why approval should be treated as a controlled operation, not a quick queue tick.
Payment profile and billing implications
Payment setup should be checked before confirming approval, especially in term launch weeks.
UK guidance for staff notes:
- Direct Debit: explain submission and clearing timing in plain language.
- Card: explain that capture is immediate and failures need follow-up.
- Bank transfer: explain it is recorded once funds are received.
If a profile is incompatible with the enrolment type, fix that before approval. Otherwise payment schedules may fail and the family will receive mixed messages.
Examples
Example: Swim school handling capacity pressure
A beginner class had a cap of 12 and was already at 12 active/trial. Two new requests arrived. The admin approved one with override after owner sign-off and waitlisted one with a dated follow-up note.
Both families received clear, consistent communication and no silent queue drift.
Example: Martial arts club with duplicate risk
One request for a 10-year-old matched an existing child record by date of birth and email pattern. Staff resolved the match first, linked to the existing family, then approved as trial.
One clean participant record, no duplicated payment schedule lines.
Example: Music school with mixed enrolment types
The school processed 9 full-term requests and 4 single-class requests in one evening. They checked payment profile compatibility before each approval.
Fewer failed payment setups and fewer support messages on billing day.
Related feature
Avoid these slips
1. Approving while duplicate status is unresolved
This often leads to duplicate participants and messy family links.
2. Selecting active by default for every approval
Some learners should start as trial. Auto-default thinking creates later status corrections.
3. Leaving waitlist or reject reasons vague
Families then ask multiple follow-up questions and queue load increases.
4. Ignoring payment profile compatibility until after approval
This creates billing delays and avoidable arrears conversations.
5. Processing live requests in spreadsheets during migration
Two active systems produce contradictory records and poor audit confidence.
Related guides
Avoid these slips
1. Approving while duplicate status is unresolved
This often leads to duplicate participants and messy family links.
2. Selecting active by default for every approval
Some learners should start as trial. Auto-default thinking creates later status corrections.
3. Leaving waitlist or reject reasons vague
Families then ask multiple follow-up questions and queue load increases.
4. Ignoring payment profile compatibility until after approval
This creates billing delays and avoidable arrears conversations.
5. Processing live requests in spreadsheets during migration
Two active systems produce contradictory records and poor audit confidence.