Defining event registration statuses
Three people use the word confirmed to mean three different things, and the headcount sent to the caterer depends on which one is counted.
The short answer
Give every registration status one written definition, an owner who may set it, the allowed next statuses and the actions it triggers. Keep the list short enough that staff can recall it without a chart.
Count seats and headcounts only from statuses you have defined, and use the same list in the registration system, the exports and every message to delegates.
Why status words cause disputes
Words such as registered, confirmed, paid and attending are used loosely in emails, but each one drives a different action: sending joining details, holding a seat, issuing an invoice, printing a badge.
If two people read the same word differently, supplier numbers and seat counts differ. The fix is one shared definition per word.
A starter status list
| Status | Meaning in one line | Who sets it | Counts toward seats? |
|---|---|---|---|
| Started | Form begun, not submitted | System | No |
| Submitted | Form complete, awaiting any check | System | Holds a seat for a stated time |
| Pending verification | Rate or eligibility needs checking, such as member verification | Secretariat | Holds a seat |
| Confirmed | Accepted and confirmation sent | Secretariat or system rule | Yes |
| Payment outstanding | Confirmed, invoice not yet settled | Finance | Yes, until the stated date |
| Waitlisted | Not yet offered a seat; see waitlist rules | System | No |
| Cancelled | Withdrawn under the cancellation process | Secretariat | No |
| Attended | Checked in on the day | Desk team | Final count |
Rules for moving between statuses
- Write allowed moves as arrows, for example Submitted to Pending verification to Confirmed. Anything not listed needs a named approver.
- Never let a status go backwards silently. A move from Confirmed to Submitted should leave a note saying why.
- State which statuses trigger a message and which trigger none.
- Keep a date and a name against every status change so a dispute can be traced.
Define the counts, not only the labels
Write which statuses feed each number: seats taken, caterer headcount, badge print list, certificate list. The caterer number often includes people still pending payment; the certificate list should not include people who cancelled.
Put these formulas on the same page as the status table so the reports use the same logic.
Test with fictional delegates
- Create one fictional delegate for each status and each allowed move.
- Move them through the paths and check the messages, counts and exports.
- Add edge cases: a delegate who cancels while pending, a waitlisted person who is offered a seat and does not reply.
- Record the results using the registration testing checklist.
Worked example · Fictional example
Status clean-up for a seminar series
Fictional organisation and figures, for illustration only.
A fictional professional-learning team ran a seminar with 180 seats and found 214 people marked as registered. Registered meant submitted, confirmed and waitlisted combined.
The team replaced it with seven statuses, defined the caterer count as Confirmed plus Payment outstanding, and the certificate list as Attended. Three test delegates showed that waitlisted people had been receiving joining details, and the message trigger was removed from that status.
Use this yourself
Status definition and count sheet
Fill one row per status, then add the count formulas underneath.
- Status name and one-line meaning:
- Who may set it:
- Allowed next statuses:
- Message sent when it is set (or none):
- Counts toward seats, caterer headcount, badge list, certificate list (yes or no for each):
- Maximum time a registration may stay in this status:
- Test delegate and result:
- Count formulas agreed with finance and venue contact:
Handle it in-house, or bring in help?
Your team can usually handle this when
- Your platform has a short fixed status list and you only rename it.
- One person sets statuses and writes the counts.
- Nobody else uses the registration data for decisions.
Outside planning help earns its fee when
- Finance, the secretariat and the venue each report different headcounts.
- Statuses are set by several people and by automatic rules.
- You are changing platform and need the old statuses mapped to new ones.
Need one set of statuses everyone uses?
A conference project lead can run the definitions session with your secretariat and finance, write the state table and count formulas, and test them with fictional delegates before registration opens. The meaning of each status stays your decision; the lead keeps the working version consistent.
Questions organisers ask
How many statuses are enough?
As few as cover the decisions you make. Six to eight is common; more than that tends to hide confusion between statuses that do the same job.
Should delegates see the status names?
Show them plain wording that matches their situation, such as Confirmed or On the waitlist, and keep internal names such as Pending verification for staff.
Who owns the status list?
One named person, usually the secretariat head or the project lead, who approves any change and informs finance and suppliers.
Related resources
Content record: Draft. Written from the cited sources and checked by automated rules; not yet independently reviewed.