Start here when you are preparing your first live term in Classia. It covers setup order, launch checks, and the points where week one usually goes off track. You will not find generic advice here. You will find specific actions that help when time is short and classes are already scheduled. If your next term starts soon, this is the page to follow in order.
Friday-night reality first
A common moment is finishing your social post and wanting to publish all classes immediately. The pressure is understandable. It is also where many avoidable errors start.
When teams publish before setup is complete, the first backlog appears quickly:
- pending requests with missing parent details
- payment questions staff cannot answer consistently
- register issues because enrolment records are incomplete
The fix is not “work faster.” The fix is a setup order that keeps records clean.
Setup order that saves time later
Step 1: Confirm account details your team will actually use
Set your account-facing details before anything else. Keep name, contact details, and public-facing identity consistent.
Concrete example: if your website says “Northside Dance Academy” but Classia says “Northside Dance,” parents will ask if they are the same provider. That is a preventable support loop.
Step 2: Create your first term with final dates
Create one term with clear start and end dates. Use practical naming such as “Autumn 2026.”
Concrete example: a school that updates term dates after class setup often spends hours checking generated sessions by hand. The same school can avoid that by locking dates first.
Step 3: Build one complete draft class
Create one class with:
- day and time
- studio
- teacher
- capacity
- age range
- draft status
This class becomes your reference model. Do not clone a half-checked class across your timetable.
Step 4: Confirm child-related assumptions early
If you teach children, align your team on guardian expectations before requests start. Under-18 data needs clear adult context.
Concrete example: one studio approved 14 requests in a day, then spent the next day fixing responsible adult links. They could have prevented it with a 20-minute team check before launch.
Step 5: Finish payment readiness before public links go out
Confirm payment setup at class level. Decide which classes allow Direct Debit, card, or both. If you accept offline bank transfer, decide who records it and when.
Concrete example: “We’ll sort payments next week” almost always creates week-one arrears confusion.
A practical launch checklist
Use this checklist the day before launch:
- Every launch class links to the right term.
- Class age ranges match delivery reality.
- Staff know who owns request decisions each day.
- Payment method language is clear and written.
- Under-18 classes have clear guardian expectations.
- Only reviewed classes are published.
If two items fail, pause launch and fix them first.
Examples
Example: Dance school with 96 pupils and three age bands
The school starts with six classes out of 14. They publish beginner and junior classes first. Senior groups stay in draft for four days while teacher cover is confirmed.
Request quality stays high, and staff answer parent questions quickly.
Example: Martial arts club, 12 classes, one admin lead
The admin lead uses one reference class and replicates it across weekday sessions. He sets Direct Debit for term plans and keeps card for single sessions.
Fewer payment surprises and cleaner first-week approvals.
Example: Tuition centre with spreadsheet legacy
The centre moves active maths and English groups first. Historic one-to-one records stay outside Classia for month one.
Current term runs cleanly while old data is migrated in controlled batches.
What to prepare for your team before launch day
Even strong setup fails if the team starts launch week with mixed assumptions. Create one short internal brief and share it before first public links go out.
Include:
- Daily request review time and owner.
- How to handle unclear guardian information.
- Which classes are live now, and which remain draft.
- Payment language staff should use with families.
- Escalation route for safeguarding uncertainty.
Do not write a long process document. One clear page is enough when people are tired and teaching all day.
Parent-facing messages to draft early
Most week-one pressure comes from communication gaps, not system failure. Draft these messages before launch:
- enrolment received and pending review
- approved with next payment step
- waitlisted with what happens next
- rejected with respectful reason language
Keep messages plain. Keep times specific. If Direct Debit is involved, state submission day and expected leave-account timing.
Concrete example: “Collections are submitted Tuesday. Your bank usually shows the debit by Thursday.” That line prevents back-and-forth messages.
First fortnight review plan
The first two weeks are where quality either settles or degrades. Use a fixed review rhythm:
End of day review (10-15 minutes)
- oldest pending request age
- repeated parent questions
- classes with the most edits
End of week review (30-45 minutes)
- approval consistency across staff
- payment confusion trends
- any safeguarding escalations
If one class keeps generating admin load, review that class setup first. It is often a configuration issue, not a team performance issue.
Lived-experience warning signs
Studio owners often describe the same warning signs when launch week drifts:
- “We keep answering the same three payment questions.”
- “Two staff members made opposite decisions on similar requests.”
- “I cannot tell which records are live and which are old imports.”
If you hear those lines, pause expansion and stabilise what is already live.
A practical handover format for small teams
At the end of day, nobody wants to read a long update. Keep handover notes to five lines:
- What changed today.
- What is still pending.
- Which parents need reply tomorrow.
- One payment note.
- One safeguarding note, if relevant.
That five-line habit keeps your setup quality from slipping as workload rises.
When to pause and escalate
Stop setup and escalate internally if any of these appear:
- staff disagree on guardian requirements for similar requests
- payment timing language changes by team member
- repeated edits to the same class within one day
Escalation does not mean failure. It means you are protecting launch quality before confusion spreads to parents. It also protects staff from rushed guesswork.
Safeguarding-sensitive setup points
When children are involved, avoid these shortcuts:
- approving incomplete guardian context “for now”
- giving broad admin access to temporary helpers
- publishing class details before internal review
You can recover from a late timetable update. Safeguarding repairs are harder and slower.
Payment language for UK families
Keep wording concrete:
- Direct Debit: tell families when collection is submitted and expected to leave their bank account.
- Card: state when card checkout is used instead of Direct Debit.
- Bank transfer: if accepted offline, tell families where evidence should be sent and when records update.
Avoid vague lines such as “payment will be processed soon.” Parents read that differently.
Related guides
- First 30 minutes
- Set up your first term
- Common first-week errors
- Connect an AI assistant to Classia
- Term planning and class setup
- Public pages and enrolment requests
- Payments and billing (UK)
Related feature
FAQ
How long should getting started take for a small studio?
Most teams can complete first launch setup in a few focused sessions over two to five days.
Should we invite all staff before setup is complete?
Invite core staff first. Expand access after launch roles are clear.
Do we need every class ready before opening enrolment?
No. Start with launch-ready classes only.
Can we change term dates later?
Yes, but changes should be deliberate and followed by session review.
What should we review daily in week one?
Request queue age, payment questions, and any recurring parent confusion.
Which page should we open next?
Open Set up your first term.