A membership form looks like the simplest thing an organisation ever builds. Name, email, which tier, pay here, done. Then the first fifty applications arrive and the shape of the real work appears: two people paid the wrong rate, one is a student who needs proof of enrolment, three are sitting unreviewed because the person who was going to check them is on leave, and nobody can say whether the applicant who emailed last Tuesday ever got an answer.
The form is not where that goes wrong. A membership application is an approval process with a form at the front, and the part that costs time is everything between the submission and the welcome email. This article covers what to ask, how to handle tiers and fees without making the form unreadable, and where the decision itself should live.
A membership application ends in a decision, not a receipt
This is the difference that shapes everything else. A contact form is finished when the message lands. A membership application stays open until somebody has said yes or no, and often until money has moved.
That means at least three states exist from the first day: submitted and unreviewed, approved, declined. Most organisations discover they need a fourth, which is waiting on something from the applicant, because a surprising share of applications arrive incomplete. Proof of student status, a professional registration number, a referee who has not replied yet. Without a state for that, those applications sit in the same undifferentiated pile as the ones nobody has opened, and they are the ones most likely to be forgotten.
There is also a second party in a membership process who does not exist in a contact form: the person who decides. For a small club that is the secretary. For a professional body it might be a committee that meets monthly. Either way, the form needs to hand the application to that person in a state they can act on, and needs to record what they decided and when. If the answer to "who approved this member" is a memory or a chat message, the process works until somebody asks.
Decide those two things first, before choosing a tool. What are the states, and who moves an application between them. Everything after this is easier once those are written down.
The fields worth asking
Membership forms grow. Each year somebody adds a question and nobody removes one, and eventually the form asks about dietary requirements for an event that happened in 2019. Start from the decision and work backwards.
Who they are
Full name, email address, and one more contact route if you genuinely use it. Email is load bearing here in a way it is not on a survey, because it becomes the identifier that ties this person to their renewal next year, their payments, and every message sent to them. Validate it as an email field so typos fail at entry.
Whether they qualify
This is the part that distinguishes a membership form from a sign-up. If membership is open to anyone who pays, skip it. If there are criteria, ask only for what you will actually check: the qualification, the employer, the institution, the referee. Asking for evidence you never look at trains applicants to treat the form as theatre.
Which category
Tiers, rates and start dates. Covered in the next section, because this is where forms go wrong.
What you are permitted to do with it
A membership record is held for years and used for mailings, so consent belongs on the form rather than in a policy nobody reads. Separate the operational messages from the marketing ones. Someone joining a professional body expects to hear about the renewal; they have not necessarily agreed to a monthly newsletter.
What the organisation needs but the applicant should not see
Internal notes, who reviewed it, the date the committee approved it, the reference number issued. These are not questions. They belong alongside the application as fields your team fills in afterwards, which is a capability worth checking for when you compare tools.
Categories, eligibility and the conditional logic problem
Almost every membership form has tiers: full, associate, student, retired, corporate, life. Each has a different fee, and usually a different set of questions behind it. A student needs to prove enrolment and give a graduation year. A corporate member needs a billing contact and a number of seats. A retired member needs neither.
Put all of those questions on one page and the form becomes a wall. Applicants answer questions that do not apply to them, or abandon it. The fix is conditional logic: ask the category first, then show only the branch that follows from it.
Conditional logic is now standard rather than premium. Tally includes it on the free plan, as do Fillout and Cognito Forms. Google Forms has had section branching for years, though it operates on whole sections rather than individual questions, which makes complex fee structures awkward. Microsoft Forms supports branching in a similar way.
Two mistakes recur regardless of tool. The first is encoding the fee in the form as static text, so that when the rates change in April somebody has to remember this form exists. Better to keep the fee in one place and reference it, or at minimum put a review date in the calendar. The second is letting applicants self select a discounted category with no check attached. If a student rate exists, either verify enrolment or accept that some people will take it; what does not work is verifying it inconsistently, because that is where complaints come from.
Payment: with the application, or after approval
There are two designs and they suit different organisations.
Taking payment at submission is simpler to operate. The applicant fills in the form, pays, and is a member. It works when membership is effectively open and the review is a formality. The risk is refunds: if you decline an application you have already charged, somebody has to unwind it.
Taking payment after approval is cleaner where the decision is real. The applicant applies, you review, and only on approval does a payment link go out. This adds a step and a chase, because a share of approved applicants will not pay promptly, which means you now need a state for approved but unpaid.
Payment support on the common tools, taken from their own pricing pages:
| Tool | Payments on the free tier | Notable limit |
|---|---|---|
| Jotform | Yes, 10 payment submissions a month on Starter | Bronze 100, Silver 250, Gold 1,000 a month |
| Cognito Forms | Yes, payments on every plan | Free tier is 100 entries a month, 1 user |
| Tally | Yes | Unlimited submissions under a fair use policy |
| Fillout | Yes | 1,000 responses a month on the free plan |
| Google Forms | No payment collection | Free, no submission metering |
| Microsoft Forms | No payment collection | Up to 400 forms per user |
The Jotform payment allowance is the one that catches people, because it is metered separately from submissions. A free Starter account allows 100 submissions a month but only 10 of those can be payments. For an annual membership intake that arrives in a burst, that is a low ceiling.
Whichever design you pick, keep the payment reference next to the application rather than only in the payment processor. Reconciling a bank export against a spreadsheet of applications is an hour a month that nobody budgets for.
Where the approval decision is recorded
Once applications are arriving, the operational question is which ones are waiting on whom.
Give every application an owner, even in an organisation of three people. An application that two committee members have both glanced at is an application neither has reviewed, and that ambiguity is the single most common source of applicants waiting three weeks for an answer.
Give every application a stage, and keep the list short: received, waiting on the applicant, approved, declined, paid. Five is plenty. The value is not process for its own sake. It is that a list you can filter by stage answers the one question that causes actual damage, which is what has been sitting untouched and for how long.
Keep the history, because membership decisions get questioned. When somebody asks in eighteen months why an application was declined, the useful record is the sequence: when it arrived, who reviewed it, what was sent, when the decision was made. A spreadsheet holds the current state and forgets everything else. Tools built around response management keep the sequence without anyone maintaining it.
And keep the internal fields with the application rather than in a parallel document. Reference number, committee date, renewal date, notes. The parallel document is always the one that goes stale.
The three messages every membership intake sends
Most complaints about membership processes trace back to a message that was not sent, or was sent twice.
The acknowledgement goes out automatically on submission, with a copy of what the applicant wrote and a realistic timeframe. It costs nothing, and it removes the entire category of "did that go through" emails. State a period you will actually meet.
The decision. Approval or decline, sent from somewhere the rest of the team can see. This is where duplicates happen: the reply goes from a personal mailbox, nobody else can tell it went, and the next person to open the application sends it again. A decline that arrives twice reads as carelessness about a decision the applicant has already taken badly.
The chase. For applications waiting on a document, or approvals waiting on payment. Nothing external pushes these, so they need to be visible in the list rather than remembered.
If applications arrive in an annual wave, sending the decisions as a batch with the applicant's name merged in is both faster and more consistent than writing each one. Keep a template for each outcome so the wording does not drift between reviewers.
Renewals are the same problem a year later
A membership form is rarely a one time build, and that is worth knowing before you choose where to build it.
Twelve months on, the same people need to be contacted, some details need updating, and the fee needs paying again. If the original applications live in a spreadsheet that has since been filtered, sorted and partly overwritten, the renewal starts with an hour of reconstruction.
Two things make renewals cheap. The first is that the member record is keyed on something stable, normally the email address, so a person who submits a renewal form is recognised as the same person rather than becoming a second row. The second is that the renewal reuses the original form rather than starting from a blank one. Tools that let you duplicate a form with its questions, notifications, auto replies and stages intact turn the annual renewal into a five minute job.
Retention is the other side of this. Membership records contain more personal data than most forms collect and are held for longer. Decide how long applications from people who never joined are kept, write it on the form, and delete on schedule. The questions people ask about where a tool stores data and who can reach it are worth reading before the first application arrives rather than after.
What to change first
Write down the states an application passes through and who moves it between them, then check whether your current form tool can hold that without a side spreadsheet. If it cannot, that is the thing to change, ahead of any question on the form. Halict shows what a membership intake looks like when the application, the decision and the reply all sit in the same place.
Q1. What should a membership application form ask for?
Name, email address, the membership category, and only the eligibility evidence you will genuinely check. Add consent handled separately for operational messages and for marketing, since a member expects renewal notices but has not necessarily agreed to a newsletter. Anything you will not act on should come off the form.
Q2. Should payment be taken at submission or after approval?
Take it at submission when membership is effectively open and the review is a formality, since it is simpler to run. Take it after approval when the decision is real, because charging an applicant you then decline means unwinding a payment. The second design needs a state for approved but unpaid, and someone to chase it.
Q3. Can Google Forms collect membership fees?
No. Google Forms has no payment collection, so fees have to be handled separately through a payment link or bank transfer and then reconciled by hand. Jotform, Cognito Forms, Tally and Fillout all support payments, though Jotform meters payment submissions separately from ordinary ones.
Q4. How do you handle different membership tiers on one form?
Ask the category first, then use conditional logic to show only the questions that follow from it. A student branch asks for enrolment evidence, a corporate branch asks for a billing contact, and neither sees the other. Conditional logic is available on the free plans of several form builders, so it is rarely a reason to upgrade.
Q5. How long should membership applications be kept?
Current members' records are kept while the membership is active and for whatever period your accounting obligations require. Applications from people who never joined should have a shorter, stated period. Write the retention period on the form so applicants know, and delete on schedule rather than accumulating an archive with no purpose.