The one rule: one row per person
The most common guest list in the world has a row that says "Mr and Mrs Kaya + 2 children". It is readable by a person and useless to everything else: you cannot send two invitations from it, you cannot record that one of them has a nut allergy, and at the door you cannot admit three people and mark the fourth as absent. Give every person who might walk through the door their own row, even if they are invited together.
Keep the relationship in a column instead of in the name. A household or party column ("Kaya family") ties the rows together, so you can still send one invitation to a couple if you want to, address the envelope to both, and count them as one table — while still knowing exactly who came.
The core columns every guest list template needs
Fewer columns, filled consistently, beat many columns filled sometimes. These are the ones almost every event uses, in the order that makes the sheet easy to read.
- First name and last name in separate columns, so the invitation can say "Dear Ayşe" and the door list can sort by surname.
- Email, one address per cell, the one the guest actually reads.
- Phone, with the country code, for the guest whose email bounces and for the door on the night.
- Company and job title, for business events; leave them out of a wedding.
- Group or segment: VIP, press, partner, speaker, staff, family, friends. This decides entrances, seating and the report.
- Household or party, to link people invited together.
- Language, if invitations go out in more than one.
- Source: where the row came from, so you can answer "why was I invited?"
Plus-ones, children and the guest you do not know yet
Decide before you build the template whether plus-ones are named or unnamed. A named plus-one is a person: give them their own row, linked to the main guest by household. An unnamed plus-one is an allowance: put a number in a "plus-ones allowed" column on the main guest’s row, and let the reply fill in the name later. Mixing the two in one column is how a gala ends up with twelve unexplained extra seats.
Children follow the same rule. If they need a seat, a meal or a wristband, they need a row; an "age group" column (adult, child, infant) is enough for the caterer and the venue without asking for dates of birth.
Dietary needs, access needs and notes
Dietary requirements are the column most often filled by hand in the last week, and the one that matters most if it is wrong. Use a short fixed set where you can — vegetarian, vegan, halal, kosher, gluten-free — and a separate free-text column for allergies, because "nuts" and "severe peanut allergy, carries an injector" are not the same instruction to a kitchen.
Access needs deserve their own column too: step-free entrance, a seat near the exit, a sign-language interpreter. Keep a general notes column for everything else, and treat it as notes, not as a place to store data you will need to sort or count later.
- Diet: a fixed list, one value per row.
- Allergies: free text, exactly as the guest wrote it.
- Access needs: free text, passed to the venue.
- Notes: anything else, never something you need to count.
Status columns: invited, replied, attended
A template is not only the list you start with; it is the list that will be updated for weeks. Leave room for what happens to each guest: whether the invitation was sent, whether it bounced, the reply (yes, no, maybe, no answer), the number of guests confirmed, and on the night whether the person checked in. A VIP flag or tag column lets the door greet the right people without a separate sheet.
Keep these as separate columns with fixed values rather than colours. Colour is lost on import, cannot be filtered reliably and means something different to every person who opens the file.
Consent and the data you should not collect
A guest list is personal data. Collect what the event needs and nothing more: a date of birth, a home address or an ID number should only be there if the event genuinely requires it. If you plan to keep the list for future invitations or to share any details with a sponsor, add a consent column and record what each guest agreed to, and when. It is also the column that answers a deletion request quickly.
Preparing the file for import from Excel or CSV
Most guest lists start in Excel or Google Sheets and end up in a system that sends invitations and checks people in. The import goes well when the file is plain. One header row, one sheet, no merged cells, no blank rows used as separators, no totals at the bottom. Dates and phone numbers stored as text so the spreadsheet does not reformat them.
Before importing, sort by email and then by last name and read the neighbours: duplicates sit next to each other once the list is ordered. Two rows with the same address and different names are usually one person written twice; two rows with the same name and different addresses are usually one person with a work and a private address. Decide which one stays before the import, not after the invitations have gone.
- One header row with clear names: First name, Last name, Email, Phone, Group.
- One sheet, no merged cells, no colour-coded meaning.
- Phone numbers with country code, stored as text.
- Exported as CSV (UTF-8) if the target system asks for it, so accented names survive.
- A quick sort by email and surname to catch duplicates.