Running an approval queue for a members-only forum

An open conference sells tickets. A members-only forum decides who is in the room, and that decision is the product. Sponsors pay for the room. Speakers agree to appear because of the room. Members renew because of the room. Everything else — the venue, the catering, the app — is logistics around a guest list.

Which means the approval queue is not an administrative chore attached to registration. It is the event, happening in advance, in a spreadsheet-shaped interface, six weeks before anyone travels.

Write the rule down before the form opens

The single most useful hour is spent before a form goes live, writing one paragraph that says who is eligible. Not a policy document — a paragraph, of the kind that can be read out on a call.

Something like: full members in good standing are approved automatically; associate members are approved if they have attended in the last two years; non-members are approved only if a member has introduced them, and the introducer is recorded. Then: anyone from a competitor of the headline sponsor goes to the chair.

Write it down and two things follow. Approvals become fast, because most of them stop being decisions. And the ones that remain are visibly the ones a human should be making, which is the only way a queue of four hundred gets worked through by people with other jobs.

If you cannot write the paragraph, the honest conclusion is that you do not yet have an admissions policy — you have an intention to have opinions later, one delegate at a time, which produces inconsistent outcomes and no defence when somebody asks why they were refused.

Automatic where the rule is mechanical, by hand where it is not

Once the paragraph exists, most of it is mechanical. Membership status is a fact. Domain is a fact. Category is usually a fact. Approve those automatically and you have shrunk the queue to the cases that actually need judgement.

Approve in bulk where the batch shares a reason: everyone from the member directory, everyone a sponsor nominated, everyone in a delegation whose list arrived as a spreadsheet. Approve one at a time when the reason differs per person, because a bulk action taken to clear a backlog is how the wrong person gets in.

The distinction to hold on to: bulk is for a batch that shares a decision, not for a backlog that shares a date.

Approval has to do both things at once

This is the failure worth designing against, because it is silent.

When you approve someone, two things must happen: they get an entry credential, and they are told. If those are separate steps, sooner or later one runs and the other does not — a database migration, a queue that stalls, a browser tab closed halfway. The result is a set of people who are approved in your system and know nothing about it, and you will not discover them by looking at the approval count, because that count is correct.

Approving should issue the signed entry pass and send the confirmation in the same step, and you should be able to see, per person, whether that confirmation was delivered. Approval is not a state in your database. It is a state in the delegate's inbox.

Categories earn their keep at the door

Set a category on every registration — member, guest, speaker, press, sponsor, staff — and set it at approval, when you are already looking at the person. It costs nothing then and it is expensive later.

Categories are what make the pre-event filters useful ("show me approved speakers who have not confirmed travel"), and they are what makes the door legible. A gate that can see category can route people, seat people, and give the right lanyard without asking a question.

Saved views are the queue

An approval queue that is worked from a single unfiltered list gets worked from the top, which means the newest arrivals are decided fastest and the awkward ones age forever.

Build the views the work actually has:

• Needs a decision — pending, no blocking flag. The default.
• Waiting on a member introduction — pending, non-member, no introducer recorded. This is a chasing list, not a decision list, and it belongs to a different person.
• Pending more than five days — the queue's conscience. If this is never empty, the rule paragraph is too vague.
• Approved, confirmation not delivered — the list that prevents the door problem described above.

Then agree a rhythm. Twice a day, ten minutes, one named person. A queue worked in short passes stays under control; a queue worked in a heroic three-hour session the night before produces the decisions you would expect from someone who has been at it for three hours.

Say something when the answer is no

Silence is not neutral. Somebody who applied and heard nothing will assume the form broke, apply again, and then telephone. You have now spent more effort than a decline would have cost, and the person is annoyed as well as absent.

Keep the outward reason short, accurate and non-negotiable in tone: this forum is open to members and their invited guests. Keep the detailed reasoning internal, where the committee can see it and the delegate cannot. Those are two different audiences and they should never share a text box.

Design for the seat coming back

Perhaps a tenth of any approved list will not attend, and most of them know it days in advance. Whether that becomes a returned seat or an empty chair depends entirely on whether declining is easier than doing nothing.

Put a release link in the confirmation itself, so handing back a place takes one tap from the email that granted it. Make it two steps rather than one — a link that acts on a single request will eventually be triggered by a corporate email scanner following every URL in the message, and cancelling a delegate who never touched it. Ask a reason, optionally. The reasons are how you learn that a third of your declines are a clash with another body's annual meeting.

Then the seat goes back into supply, the waiting list moves, and the organiser can see who released and why — which is a far better conversation to have with a sponsor than a photograph of empty chairs.

Keep the record

Approvals attract questions later: why was that firm in the room, who admitted them, when. A log of consequential actions — who approved, who rejected, who overrode a rule, who exported the list — answers those in a minute rather than a week of email archaeology.

And keep contact details away from people who do not need them. A volunteer working the "needs a decision" view can do the whole job seeing names, organisations and categories. Masking phone numbers and addresses from roles without a reason to see them is not distrust; it is the ordinary practice of not spreading a membership list further than the work requires.