CPR Class Scheduling Software and Booking Calendar

A scheduling system for CPR classes has more jobs than a calendar, because every class is a small piece of inventory with rules attached. At minimum it has to hold a course catalog where BLS, ACLS, PALS, Heartsaver, and renewal versions are separate products with their own price and format. It has to publish sessions with a date, a time, a location, and a seat cap set per session, since the cap is decided by manikins and instructors, not by the room. It has to show students only the sessions that are really open, with live remaining seats, and stop selling the moment a class is full.

Then it has to finish the job without a human. Payment taken at booking, through the processor you already use, matched back to the seat it paid for. A confirmation to the student with the date and the address, an alert to you, and an event on the instructor's calendar. Phone bookings entered against the same sessions so the roster stays the single source of truth. And because a CPR card expires, the student and the course they took have to be saved somewhere a renewal reminder can find them in two years.

That is the checklist we built this booking calendar against, because it is what our own CPR company needed. If a scheduling tool you are evaluating cannot hold seat caps per session, take payment at booking, and write the class to the instructor's calendar, it is a sign-up form, not a scheduling system.

The honest test is whether the tool knows what a certification is. A generic scheduler treats a BLS class like a haircut: a time slot with a name attached. It has no idea the class has a seat cap tied to manikin count, that the same course sells in three formats, that the student walks out with a card that expires in two years, or that the instructor is the real inventory. Look for a system that models course, session, seat, instructor, payment, and expiry as separate things. That is the difference between a calendar that takes bookings and a system that runs the business. We built ours for our own CPR company first, which is why those objects exist in it.

You embed the booking widget directly in a page on your own domain instead of linking out to a scheduler. Two things improve immediately. Conversion goes up because students never hit an unfamiliar branded page and pause to wonder if they are still buying from you. And ad tracking stops breaking, because the gclid that came in with the click is still on the page when the booking happens, so the sale can be attributed to the keyword that paid for it. Redirecting to a third-party domain drops that thread. If you run Google Ads at all, on-domain booking is worth more than the conversion lift alone.

Yes, and you need all three because they answer different questions. The instructor view answers staffing: who is teaching Saturday, who is double-booked, who has a free morning you could sell into. The course view answers demand: BLS renewal is filling five days out while Heartsaver has empty seats every week, so move the schedule. The day view is what you actually work from on class day, with rosters and seat counts. One combined month grid hides all three. Views are filters on the same booking data, so nothing is duplicated and nothing drifts.

That is the ops dashboard, which is a separate piece that reads the same booking data. The calendar answers class-day questions: who is enrolled Saturday, which instructor, how many seats are left. It does not answer whether the week is on pace, because that needs leads, revenue, and unpaid students sitting next to the schedule. We kept them apart deliberately so the booking calendar stays the thing you embed and the dashboard stays the thing you open in the morning. If you want the wider view, see how the ops dashboard works on its own page, linked below. Our own business runs around 137 bookings a month across both.

No, and you should be suspicious of anything that says otherwise. You keep your existing Square or Stripe account and payments settle directly to you. Nothing routes through us and we never hold your revenue. The widget hands off to your processor at checkout, then matches the completed payment back to the booking so the confirmation, the seat, and the calendar event all reflect money that actually arrived. Platforms that insist on becoming the merchant of record are solving their problem, not yours.