Documentation

Set up your first term

Create your first full term in Classia with practical checks for enrolments, payments, and safeguarding.

Open this guide when setup becomes real: term dates are near, classes are being built, and launch pressure is rising. It explains how to set up a first term that can handle live requests, not just look tidy in a table. You will learn the checks that stop first-week queue problems before they start. The guidance is practical and UK-specific, including payment language that families understand.

Start with the mistake most teams make

Most teams do this once: they build every class first, then discover term dates need edits, payment rules are unclear, and public copy is inconsistent. The result is a long correction session and anxious launch day.

A better route is slower for one afternoon and faster for the rest of term.

Build your term in layers

Layer 1: Term record

Set term name and final dates. Keep names simple and repeatable.

Good: “Autumn 2026”

Less helpful: “Phase B cycle 4”

Layer 2: One reference class

Create one class in draft and validate every field. This class becomes the model for others.

Check:

  • timetable details
  • teacher and studio link
  • age range
  • capacity
  • class visibility status

Layer 3: Session review

After class creation, scan generated sessions. Confirm day and timing are correct. If closures are known, record cancellation reasons clearly.

Layer 4: Payment readiness

Before publishing, confirm each launch class has the right payment profile and method rules.

Layer 5: Launch ownership

Assign who will review requests each day in week one.

Practical term setup checklist

Use this checklist before sharing any public link:

  1. Launch classes are linked to the right term.
  2. Capacity reflects real room limits.
  3. Child classes have clear age boundaries.
  4. Public descriptions are parent-readable.
  5. Payment method and timing language is agreed.
  6. Queue owner is named for each launch day.

If one item is unclear, hold launch.

Examples

Example: Dance school with 18 classes across three days

The school publishes eight classes first. Children’s beginner classes go live first, senior classes follow after teacher cover is finalised. They keep request review at 15:30 daily.

Example: Martial arts academy with shared hall bookings

The academy sets realistic capacity by room, not by demand. Two children’s classes are capped at 20 due to mat space, even though demand could exceed 30.

Example: Music school offering trial and term enrolments

The school assigns card checkout for single trials and Direct Debit for full-term plans. Staff are briefed on how to explain each route in plain language.

UK payments language that prevents confusion

Use specific wording in all launch communications:

  • “Direct Debit collections are submitted on Tuesday and usually leave accounts by Thursday.”
  • “Card checkout is used for single-session enrolments.”
  • “If you pay by bank transfer, we mark it once received and reconciled.”

Avoid broad lines such as “payment will be taken soon.”

Safeguarding checks before publish

If children are in scope:

  • confirm age ranges are accurate
  • confirm staff understand guardian expectations
  • confirm request handling is consistent across shifts

If the team is split across evening sessions, use a short daily handover note. It reduces decision drift.

First 72 hours after publishing

Treat the first three days as a monitored launch window.

Day 1 focus:

  • request quality
  • missing fields in submissions
  • repeated parent questions

Day 2 focus:

  • approval consistency across staff
  • payment method confusion
  • queue age and response time

Day 3 focus:

  • classes creating most manual corrections
  • any safeguarding concerns raised in approvals
  • what should stay draft for a few more days

This review window catches small faults before they become routine admin burdens.

Related guides

Common mistakes to avoid

1. Bulk class creation before one class is validated

Small setup mistakes are copied everywhere.

2. Capacity set by demand, not delivery limits

This creates queue pressure and dissatisfied families.

3. Publishing before payment wording is agreed

Staff then improvise explanations under pressure.

4. No named queue owner in launch week

Pending requests age quickly and parent trust drops.

Contact

Questions about Classia or need a hand? Get in touch.