What ClassForKids gives a website
ClassForKids is club and class management software, and from a website's point of view there are two parent-facing pieces worth wiring up.
Booking. A hosted booking flow on the platform's own domain, plus a widget or link you can point at from your pages. The parent chooses sessions, gives the child's details and pays.
Registration and payment handling. The child record, the consent and medical details, and the payment routes, all held in the platform rather than in your inbox.
Everything else it does happens after the booking and never touches your pages. Feature detail changes release to release, so confirm the exact widget and linking options with the vendor before you design a page around them.
The rule: nothing third-party loads until the parent taps Book
The usual mistake is dropping the booking script into the site template so it loads on every page. A club site is mostly read rather than booked: the programme pages, the fees page, the photographs, the staff page. Loading a third-party booking script on all of them slows the pages doing the persuading for the benefit of the one page doing the booking.
So: one booking page carries the embed. Every other page links to it.
The booking page
Give it a plain address such as /book, and put nothing on it but the embed, two reassuring lines, the phone number and your opening hours. Reserve the height before the widget arrives so the page does not jump as it loads, and preconnect to the platform's domain in the head:
<link rel="preconnect" href="https://booking.classforkids.io">
<div class="booking-embed" style="min-height: 820px"><!-- ClassForKids booking widget --></div>Above the embed, three lines that stop the calls you get most: what the parent will be asked for, what happens if they are paying from a childcare account rather than by card, and when bookings close. Below it, the cancellation window. Do not repeat the price table here; link back to the fees page.
Link from every programme page
Each holiday or term page gets its own Book button, pointed at the right week where the platform's links allow it. The October half term page opens October half term. The breakfast club page opens the term-time morning sessions.
Where a specific week cannot be deep linked, the button still goes to the booking page, and the line above the widget names the week so the parent knows what to select.
Configure the platform before the site points at it
- Sessions set up as your real units: breakfast, after-school, late finish, half day, full day, week, inset day cover.
- Capacity per age group, not per site, so the junior places cannot be oversold.
- Registration and consent fields, required before the first session and reused for every booking after.
- Payment routes, including whatever route you use for money arriving from childcare accounts or voucher operators, with a reference format that identifies the child.
- Sibling discounts applied automatically rather than by a code parents have to find.
- Booking cut-offs and the waiting list, with cancellations releasing places back automatically.
- Confirmation and reminder templates in your own voice, carrying the dates, the entrance, the arrival window and what to bring.
- Registers exported or viewable on a phone, with medical flags and collection notes visible to the staff on the session.
Then book a test child, end to end, on your own phone, and cancel it.
The header does not change
The platform does not reorganise the site. Every page still carries the phone number, Book, and a link to the current programme. On phones, a slim bar fixed to the bottom with Call and Book.
A parent who is anxious about whether you take their eight-year-old with an epipen wants the page about staff and safeguarding first, then the button, in that order.
Testing, especially in-app browsers
A lot of club traffic arrives from a link in an Instagram or Facebook bio, and those in-app browsers are not Safari. Test the whole flow in both, plus Safari and Chrome on iOS and Android: pick the week, add a second child, apply the sibling discount, complete registration, pay, receive the confirmation.
If the widget misbehaves in an in-app browser, point those entry points at the hosted booking page instead. Retest before every holiday programme goes live, not only at launch.
Tracking
Add a booking_click event on every Book tap with the page and the week as parameters, and a call_click on every tap-to-call. Once a month compare taps by page against completed bookings. That tells you which programme page fills the week and which one is read and abandoned, usually the one whose price or finish time is vague.
Common mistakes
- The widget loading on every page, slowing the programme pages for everyone who is only browsing.
- Prices in the platform drifting away from the fees page after a rate rise.
- Capacity capped at site level, so one age group oversells.
- A booking page with no line about childcare account payments, so those parents ring instead.
Where this sits
ClassForKids is one of the platforms we wire in most often on an after-school and holiday club website, and the pattern is the one we use across childcare websites generally: one booking page, links from every programme page, the fees and safeguarding pages ahead of both, tracking on everything. Packages are on pricing. The platform holds the register. The site's job is to get a working parent into it in one tap.