Registration systems and data structure
Event registration confirmation workflow
Delegates register and then wonder if it worked: no email, a payment pending, or a message that says confirmed when it is not.
Opens WhatsApp with a draft you can edit before sending. Nothing is sent automatically.
The short answer
A confirmation workflow links each registration state to one message and one owner. A delegate should always be able to tell from the last message whether they have a place, what is still needed and when they will hear next.
Define the states first, then write the messages. Do not call a registration confirmed until every condition you set, such as verification or payment, has been met.
States and the message for each
Use the state names from your status definitions so the system, the team and the delegate mean the same thing.
| State | Meaning | Message to the delegate | Owner |
|---|---|---|---|
| Received | Form submitted, nothing checked. | We have your registration. This is not yet a confirmed place. State what happens next and when. | System |
| Pending verification | Waiting for member or student evidence. | What we need, how to send it, by when. | Secretariat |
| Pending payment | Place offered, payment outstanding. | Amount reference, payment route, deadline and what happens if missed. | Finance |
| Confirmed | All conditions met. | Reference number, category, event date, venue, how to change or cancel, what to bring. | System |
| Waitlisted | Capacity reached. | Not a booking, how offers are made, and for how long. See waitlist rules. | Secretariat |
| Cancelled | By delegate or organiser. | What was cancelled, refund position as your policy states, how to register again. | Secretariat and finance |
What a confirmation must contain
- A reference number the delegate can quote and the check-in team can find.
- The category and any session choices exactly as registered, so errors are caught early.
- The date, venue and a note that practical details will follow, where they are not yet fixed.
- How to change details or cancel, in line with your change request process.
- A reply route that is monitored by a named person.
Timing and delivery
Decide how quickly the first message should arrive and who is alerted if it does not. Plan for messages that land in spam, bounce or go to a shared mailbox: ask delegates to check, and have a way to resend.
Reminders are a message too. Decide who receives them, when, and what stops them once a delegate has acted.
Test it from the delegate's side
- Register as a test delegate for each route: member, non-member, student, group and waitlisted.
- At each state, read the message on a phone and ask: what do I know, and what do I do next?
- Check that no message says confirmed while a condition is still open.
- Force a bounce and a resend, and cancel one registration to read the cancellation message.
- Record results in your test log.
Worked example · Fictional example
A secretariat fixes a confirmation that was sent too early
Fictional organisation and figures, written to show the level of detail that is useful.
Persatuan Fiktif Pegawai Pembelian tests its flow and finds the student route sends a Registration confirmed email straight after the form, before evidence is checked. A delegate reading it would reasonably assume a place is held.
The secretariat changes the message to say received, not yet confirmed, adds what evidence to send and by when, and sends the real confirmation only after the check. The test is run again with a fictional student.
Use this yourself
Confirmation message map
Complete one row per state, then write the messages from it.
| State | Trigger | Sent by | Must say | Must not say | Next step and date |
|---|---|---|---|---|---|
| Received | Form submitted | System | Not yet confirmed; what happens next | Confirmed | |
| Pending verification | Member or student claimed | Secretariat | Evidence needed, how, by when | Place held, unless you have decided it is | |
| Pending payment | Place offered | Finance | Reference, route, deadline | Confirmed | |
| Confirmed | All conditions met | System | Reference, category, how to change | ||
| Waitlisted | Cap reached | Secretariat | Not a booking, how offers work | Confirmed | |
| Cancelled | Delegate or organiser | Secretariat | What was cancelled, refund position |
Handle it in-house, or bring in help?
Your team can usually handle this when
- You have two or three states and a platform whose messages you can edit.
- One person is notified if something goes wrong.
- You have tested the messages on a phone.
Outside planning help earns its fee when
- Several routes (member, student, group, waitlist, payment) each need different messages.
- Messages come from more than one system, such as registration and finance.
- Delegates are already confused about whether they have a place.
Want delegates to always know where they stand?
A conference project lead can map your registration states with the secretariat and finance, draft the messages for each and test the flow end to end before opening. Edits inside the platform are made by whoever administers it.
Questions organisers ask
When should a registration be called confirmed?
When every condition you set has been met, such as verification and payment. Until then, use the received or pending states and say what is outstanding.
Should the confirmation include the programme?
Include what is fixed and say that more will follow. Do not publish details that are not yet agreed.
What if the email does not arrive?
Ask delegates to check spam and give a reply route monitored by a named person, with a way to resend.
Can our platform send different messages by state?
Check the platform's own documentation or support for what it can send at each state, and test every route with fictional delegates.
Related resources
Content record: Draft. Written from the cited sources and checked by automated rules; not yet independently reviewed.