What ClassForKids gives a website
ClassForKids is booking and management software for children's activity providers. From a website's point of view, two parts of it face the parent and need wiring up.
The booking journey. A hosted booking flow on ClassForKids' own domain, plus a widget you can place on your pages, showing your classes with their times, venues, age bands and remaining spaces, and taking payment for a trial or a term block.
The signup details. The fields collected at booking, which become the child's record and your register: parent contact, the baby's date of birth, medical notes and the consent ticks for your terms and photography policy.
Everything else the platform does happens after the booking and never touches your pages. Feature detail changes release to release, so confirm the specifics of any widget, link or embed option with ClassForKids before you build a page around it.
The rule: nothing loads until the parent taps Book
The common mistake is dropping the booking widget into the footer of every page, or worse, onto the home page above everything else.
A baby class site is mostly read, not booked. The parent reads the age bands, the first-class page, the venue and parking, the leader profile and the reviews, and only then books. Loading a third-party booking script on all of those pages slows down the pages that do the persuading, for the benefit of the one page that does the transacting.
So: one booking page carries the embed. Every other page links to it.
The booking page
/book, and almost nothing on it besides the embed, one reassuring line, the phone number and your term dates. Reserve the height before the widget arrives so the page does not jump while it loads, and preconnect to the booking domain in the head:
<link rel="preconnect" href="https://booking.classforkids.io">
<div class="booking-embed" style="min-height: 720px"><!-- ClassForKids widget --></div>Above the embed, three short lines that stop the messages you get most: what she will be asked for, which is her contact details and the baby's date of birth, that booking a trial does not enrol her in a term, and what happens if she joins mid-term. Below it, the illness and catch-up policy. Do not repeat the price table here. Link back to it.
Deep links from the class pages
Each age band page gets its own Book a trial button, pointed at that class in the booking flow rather than at a general timetable. The four to seven month page opens the four to seven month class. The crawlers page opens the crawlers class.
A parent who has just read a whole page about her baby's age band and then lands on a list of everything you run has been asked to do the work twice, and a share of them will not.
If a particular class cannot be deep linked, the button still goes to /book and the line above the widget names the class so she knows what to choose.
Configure ClassForKids before the site points at it
- Terms as blocks, with start and end dates, the weekly time and the venue, visible to the parent before she pays.
- Age bands set from date of birth, matching the bands published on your class pages exactly, so nothing the site says is allowed is refused at checkout.
- Capacity per venue, with a decision on whether a trial consumes a term space.
- Trial sessions priced and attached to a named week.
- Waitlists on full classes, with the join-waitlist option replacing the Book button on the page rather than the page looking broken.
- Prices matching the site table to the penny, including any sibling rule.
- Consent ticks worded identically to your photography and terms pages.
- Confirmation and reminder messages in your voice, linking to the first-class page with the parking and buggy answers.
- Notifications to a phone somebody actually watches, because a trial booked on a Sunday night needs the register updating before Tuesday.
Then book a test baby end to end from your own phone and cancel it.
Testing, especially in-app browsers
A large share of baby class traffic arrives from a link in an Instagram bio, and Instagram's in-app browser is not Safari. Test the whole flow there and in Facebook's, plus Safari and Chrome on iOS and Android: pick the class, enter the date of birth, tick the consents, pay, receive the confirmation.
If the widget misbehaves in an in-app browser, send those entry points to the hosted booking page instead. Repeat the test monthly and after every term rollover, because a broken booking page in the week a term opens costs a term.
Tracking
Add a booking_click event on every Book tap with the page and class as parameters, and a call_click on every tap-to-call. Once a month, compare taps by page against trials taken in ClassForKids. That tells you which age band page fills the class and which one is read and abandoned, usually the one whose price or venue is vaguest.
Common mistakes
- The widget on every page, slowing the photographs and the first-class page for everyone who is only looking.
- Prices in the platform drifting from the table on the site after a term price rise.
- Age bands on the page that do not match the bands configured in the platform.
- One general Book button rather than a deep link per class.
- No waitlist, so a full class simply looks unavailable.
Where this sits
ClassForKids is the platform we wire in most often on a baby class website, and the pattern is the one we use across childcare and family websites: one booking page, deep links from the class pages, the practical answers ahead of both, tracking on everything. The packages are on pricing. The platform holds the register. The site's job is to open it in one tap.