Enrolment opens, the form goes out, and the questions start the same afternoon. Is there a place left on the Tuesday session. Did the payment go through. Can somebody switch from in person to online. Has the confirmation been sent yet, because nothing has arrived.
None of those questions are about the form. They are about what happens after it. A course registration form is easy to build and the enrolment behind it is where the work actually sits, so the useful question is not which builder to use but which of these jobs the tool is going to do and which ones are staying on your desk.
What the form has to collect
Start with the fields, because everything downstream is shaped by them. A course registration form that works tends to carry six groups.
Who they are. Full name, email address, phone number. Email is the one that has to be right, because every message afterwards depends on it. Marking it required and validating the format at submission catches most of the typos that otherwise turn into an undeliverable confirmation and a person who never hears from you.
Which course, and which session. If the same course runs more than once, the session belongs on the form as a distinct question rather than buried in a free text box. It is the field the roster gets sorted by, and picking it from a list rather than typing it means the roster sorts cleanly.
Eligibility. Prerequisites, prior qualifications, a student or staff number, an age confirmation. Anything that decides whether the registration can be accepted at all belongs here, because checking it later means going back to the applicant.
Payment and invoicing. Whether they pay individually or their employer is invoiced, a purchase order number, a billing address. Even when payment is handled elsewhere, the form is where the invoicing details are cheapest to collect.
Practical needs. Accessibility requirements, dietary requirements for in person sessions, whether they need a recording if they cannot attend live. Asking once on the form is less work than three rounds of email a week before the course.
Consent. Terms, cancellation policy, how their details will be used, whether the session is recorded. A checkbox with a link, stored with the response, so the record of agreement sits with the registration rather than in a separate log.
Two decisions about presentation matter more than people expect. Requiring registrants to create an account before they can apply loses a share of them at the door, and most course registrations do not need one. And a long single page form is harder on a phone than the same questions shown one at a time, which is how a good number of registrations arrive.
Capacity is the part the form does not handle
This is where most course registration setups break, and it is worth being clear about why.
A form collects. It does not count. A basic form builder will happily accept the thirty first registration for a course with thirty places, because nothing in the form knows how many places there are. Some tools offer a hard cutoff that closes the form at a number, which sounds like the answer and usually is not, because the moment the form closes the waitlist closes with it.
What most course administrators actually want is different. Keep accepting registrations past capacity, mark the ones past the line as waitlisted, and promote from that list when somebody cancels. That is not a form feature. It is a status on each registration, which means it needs somewhere for the status to live.
The spreadsheet version of this works until two people edit it. Then the twenty ninth place is offered twice, or the promotion from the waitlist is recorded in one copy and not the other. The failure is not dramatic and it is not immediately visible, which is what makes it expensive.
There is a second counting problem underneath. Registrations and attendances are different numbers. People register and do not turn up, register twice under two email addresses, or register for the wrong session. Any roster that treats submissions as the headcount will be wrong, and the gap is usually large enough to matter for room booking and catering.
Group bookings and duplicate registrations
Two situations turn up on almost every course and are rarely designed for.
The first is the employer booking four people at once. The person filling in the form is not the person attending, and a form built around one registrant per submission forces them either to submit four times or to type four names into a text box. Submitting four times is usually the better outcome, because it produces four rows that can each carry their own status, but it has to be said explicitly on the form or the text box wins. When the booker and the attendee genuinely differ, a separate pair of fields for the person to invoice is worth adding, so the confirmation goes to the attendee and the invoice goes to the booker.
The second is the same person registering twice. It happens when somebody is unsure whether the first submission went through, and it happens when they change their mind about the session and re register rather than asking. Both produce two rows, and neither is obviously a duplicate at a glance if the second one used a different email address.
Tools that group responses by email address will collapse the first case automatically and miss the second. The practical defence is to sort the roster by name before enrolment closes and look for repeats, which takes five minutes and prevents both a double invoice and a place held for somebody who is already counted. Doing it once, at the close of enrolment, catches nearly everything.
The states an enrolment passes through
Naming the states is the fastest way to work out what the tool has to support. For a typical course, a registration passes through something like this.
Registered. Payment pending. Confirmed. Waitlisted. Withdrawn. Completed.
Six states, and every one of them changes what message the person should receive next. A registration sitting at payment pending needs a reminder. One sitting at waitlisted needs to hear when a place opens. One at withdrawn needs to stop receiving joining instructions, which is a failure that annoys people out of proportion to its size.
If those states live in a colour on a spreadsheet, nothing enforces them and nothing acts on them. If they live as a status on each registration, the roster can be filtered by state, and the question "who still owes payment" takes a click rather than an afternoon. Tools that carry status and an owner per response are described in these use cases, and course enrolment is one of the shapes they are built around.
Free builder, ticketing platform, or course platform
Three categories of tool get used for this, and they assume different things about the job.
| General form builder | Event ticketing platform | Form tool with response management | |
|---|---|---|---|
| Cost shape | Often free to use | Per ticket sold | Per person using the workspace |
| Collects payment | Not directly | Built in | Varies |
| Capacity and waitlist | Usually a hard cutoff | Built in | By status on each registration |
| Status per registrant | No | Limited | Yes |
| Where the roster lives | A linked spreadsheet | The platform | The response list |
| Emails to registrants | Add ons or manual | Built in | Built in |
A general form builder such as Google Forms is free with a Google account and writes every response into a spreadsheet. For a single course with a fixed roster and no payment, it is enough, and the spreadsheet is the roster.
A ticketing platform earns its place when money is involved and the course is effectively an event. Eventbrite charges nothing for free events, and applies a 3.7% plus $1.79 service fee per paid ticket alongside a 2.9% payment processing fee. That is a good deal for a one off paid workshop and an expensive one for a term of weekly free sessions with high volume, which is exactly the kind of arithmetic worth doing before choosing.
A form tool with response management sits in between. It does not usually take the payment, and it does give every registration an owner, a status, and a reply sent from the same screen. Pricing on tools in this category is often per member of the workspace rather than per response, so a course with eight hundred registrations costs the same as one with eighty. Where that matters, the pricing page is the thing to read, because the cost curve is the real difference between the three columns.
The messages you will send, whether you planned to or not
Every course enrolment generates the same set of outbound messages. Counting them in advance tells you how much of the job the tool needs to carry.
The confirmation goes out at submission and should repeat what the person entered, because that is the message they will search for later when they cannot remember which session they booked.
The payment reminder goes to a subset, filtered by status, usually a week before the deadline.
The waitlist offer goes to one person at a time, with a deadline attached, because an open ended offer means the place sits unclaimed.
The joining instructions go to everybody confirmed, a day or two before the start, with the room or the link. This one is nearly always sent in bulk, and it is the one most likely to go to somebody who withdrew, unless the send is filtered by status.
The follow up goes after the course: attendance record, certificate, feedback form.
That is five sends, four of them to a filtered subset of the roster rather than to everybody. Any setup where the roster and the mailing list are separate systems will drift between those five sends, and the drift always shows up as the withdrawn person receiving the joining instructions.
Keeping the roster usable after enrolment closes
The form stops mattering the day enrolment closes. The list carries on for the length of the course, and what it has to hold is not the answers to the form.
It has to hold what the team recorded afterwards. Whether the payment cleared. Whether they attended each session. Whether the assignment came in. Whether the certificate was issued. None of that was on the registration form, because none of it was known at submission time.
Tools differ sharply here. A spreadsheet handles it by adding columns, which works and is fragile. Some form tools let the team define internal fields that appear as columns in the list and in the export, which keeps the recorded information attached to the registration rather than in a parallel file. Whichever route you take, the test is the same: when the finance team asks who has not paid, or the tutor asks who missed two sessions, can the answer come from the same list the registrations landed in. If it needs a second file and a lookup, that is the part to fix. The features worth checking for are status, owner, internal fields, and an export that carries them.
What to change first
Write down the six states your registrations pass through, then check whether your current tool can hold them on the registration itself. If it cannot, that is the gap, not the form. See how Halict shows a registration list with stages before adding another column to the spreadsheet.
Q1. How do you stop a course registration form from overbooking?
Closing the form at a set number stops overbooking and also stops the waitlist, which is rarely what you want. The usual approach is to keep accepting registrations and mark everything past capacity as waitlisted, which requires the tool to hold a status on each registration rather than just a count of submissions.
Q2. Should registrants have to create an account to enrol?
For most courses, no. Requiring an account before the form can be submitted loses people at the door, and the registration details are all you need. An account only earns its place when registrants have to come back and manage their own booking.
Q3. What is the minimum set of fields for a course registration form?
Name, email, phone, which session they want, and consent to the cancellation policy. Everything else depends on the course. Eligibility questions, invoicing details and accessibility needs are worth adding when they exist, because collecting them later costs a round of email per registrant.
Q4. Can a spreadsheet handle course enrolment?
For one course with a fixed roster and no waitlist, yes. It starts failing when two people edit it at once, when the same person registers twice, or when messages need to go to a filtered subset such as everybody who has not paid. Those three are the signals that the roster needs somewhere better to live.
Q5. How do you track attendance separately from registrations?
Attendance is not a form answer, so it has to be recorded against the registration after the fact. Either add columns to the export, or use a tool that lets the team define internal fields that show up in the list and in the CSV alongside the original answers.
Q6. What happens to registrations when a session is cancelled?
Every registration on that session needs a status change and a message, and the message has to go only to that session. That is straightforward if the session was a separate question on the form and a filterable field on the list, and painful if it was typed into a free text box.