Wedding guest list online: RSVP, allergies and export

The failure mode is always the same, and it is never technical. Two people maintain the list, both of them are right, and the difference only surfaces when somebody has to give the kitchen a number.

A guest list is not an address book, it is a counter with a status column. At any moment it answers three questions: who is invited, who has replied, and how many covers that adds up to. As long as those numbers live in chats, notes and a spreadsheet on somebody's laptop, they drift apart — and nobody notices until the caterer asks. The value of an online guest list is that the reply, the plus-one and the meal choice sit on the same row as the name.

Which is why this guide spends more time on who does what than on which tool does what. The features matter, but only once one question is settled: whose list is this?

Every guest list problem that shows up in the final month started as an ownership problem in the first.

The awkward part is that it is a decision about people, taken early, and no feature list will take it for you.

Who gets invited at all is a separate decision; this is about the list that follows it. And it starts with a person rather than a feature: exactly one of you maintains the list, everyone else supplies names. The moment two households enter data in parallel, duplicates appear with different spellings, and the place cards reveal it later. Collect contributions in a fixed shape — first name, surname, address, relationship to the couple — and enter them in one place.

Agree early how a name is spelt, how it should appear on the place card and whether titles travel with it. It sounds fussy and it saves an evening: menu cards, seating and thank-you notes all draw from the same column. In blended families, add a note about who should sit with whom and who should not — that knowledge otherwise disappears exactly when the seating plan is being built.

Guest lists are where the difference between a pleasant tool and a usable one shows up, and it is not in the interface.

Two things decide it. Both are easy to check before you commit and close to impossible to fix afterwards, which is a fair definition of what belongs in a comparison at all: whether the data can leave again, and how invitations are counted.

For a guest list, export decides most of it. Check whether the list can be downloaded as a spreadsheet, whether menu choices, allergies and plus-ones come with it, and whether it works during the trial period too. A tool that takes data in but only gives it back as a screen view has merely postponed the work: the caterer, the witnesses and the printer all work from files, not from logins.

The second point is the guest cap. It is rarely a problem while you are building the list and almost always one while you are backfilling: when five declines are followed by five replacement invitations, some models count those as additional invitations. Establish beforehand whether a declined invitation frees the slot again, and whether re-sending one counts twice.

A list only adds up if every row means one thing. That sounds trivial until replies start arriving through four different channels, none of which was designed to update a spreadsheet.

Half the work of an online guest list is refusing to let a second list form beside it.

For the list to add up, every guest needs one unambiguous status: invited, accepted, declined, outstanding. The hybrid "said yes at the barbecue" is where every discrepancy starts — enter such replies as proper acceptances straight away, with a note on where they came from. Just as important: guests without a smartphone have to be enterable in the same list, by you, by hand. A second sheet of paper beside it is the most common reason for two different numbers.

Do not count heads from memory. Children go in with their age and plus-ones with a first name. The people who are not guests but still eat — the band, the photographer, the celebrant — need their own rows with their own marker. Otherwise the covers nobody invited are exactly the ones missing. How to collect the replies cleanly in the first place is covered in wedding RSVP online.

A guest list is the one document at a wedding holding other people's addresses, phone numbers and health information in the same row. It is also the one most likely to be forwarded as an attachment.

So the question here is one of circulation rather than storage, and it is answered by agreements between people rather than by a setting.

Three questions decide it in practice. Who sees the list in full? For most contributors a partial view or a number is enough. What leaves the list? The caterer needs numbers, menu choices and allergies, the printer needs names and addresses — nobody needs all of it. And when does it end? Set a date after the thank-you cards on which addresses and phone numbers are deleted.

Separated parents are the practical test here too. Both sides may contribute, neither receives the other's contact details, and what goes back to both is a number rather than a file. That is not distrust; it is the reason the list lives in one place instead of travelling through three inboxes as an attachment.

Most of what goes wrong in a guest list is a missing column, and columns are cheap before the first invitation and expensive afterwards.

Before the first invitation goes out, walk through the columns nobody adds later:

• The name in the spelling that should appear on the place card.
• A status with exactly four values, plus a field recording where a verbal acceptance came from.
• Plus-ones with a first name, children with an age.
• Menu choice and allergy in separate columns, both against the name.
• A marker for suppliers who eat with you and for a second celebration.

After that, one rule applies: the number that counts is the one in the list, not the one in somebody's memory. When something changes after the deadline — and something always does — change the status first and tell people second. Do it the other way round and the caterer gets a number that never reached the list, while the menu planning works from a state that no longer exists.

Getting Married keeps the list, the replies and the seating plan on the same rows, and the export carries the menu choices and allergies out with it.