Why the list is where events go wrong
A bad guest list is invisible until it is expensive. A duplicate is two invitations to one person, who notices. A mistyped domain is an invitation that bounces silently, to a guest who assumes they were not invited. A column called “E-Mail” in one tab and “Mail” in the next is a merge that puts phone numbers in the email field for a hundred rows. None of these show up when the spreadsheet is opened; all of them show up the night of the event.
The reason is structural. The list is assembled over weeks by several people, none of whom see the whole of it, and the first time anybody looks at it as one object is the day the invitations go out. By then the mistakes are in the invitations.
Start from one file, and keep the original
Merge everything into one working file before you correct anything, and keep the untouched originals beside it. Corrections made in three places are corrections made three times and reconciled never. If a name is wrong in the CRM export and right in the assistant’s sheet, you want to be able to see both.
Give every row a source. A column that says where the row came from — “sales export”, “partner list”, “added by hand, 12 May” — is the column you will need when a guest asks why they were invited, or when a partner asks why their contact was not.
Find the duplicates before the tool does
Duplicates are rarely exact. “A. Yılmaz” and “Ayşe Yilmaz” are one person; so are two rows with the same email address and different names, and two rows with the same name and a work address in one and a personal address in the other. Sort by email first, then by surname, and read the neighbours: most duplicates sit next to each other once the list is ordered.
Decide what wins before you merge. Usually it is the row with the most recent activity, the work address, and the plus-one allowance the host actually agreed to. Note the decision in the source column; “merged from partner list” is enough.
- Same email, different name: one person, two spellings. Keep the fuller name.
- Same name, different email: usually one person with a work and a personal address. Ask, or keep the one the host knows.
- Same phone, different everything else: often a couple sharing a number. Two guests, one household.
- Diacritics and case: “Ozan” and “Özan” are the same person to a search but not to a spreadsheet.
Addresses that cannot receive mail
An address can be well formed and still dead. The common failures are a typo in the domain (“gmial.com”), a role address nobody reads (“info@”), an address at a company the guest has left, and a domain that no longer exists. A tool that checks the shape of an address catches the first; only sending — or a delivery record from the last event — catches the rest.
Do not delete a row for a bad address. Mark it, and find another channel: a phone number, a colleague, the partner who supplied the name. A guest with no reachable address is still a guest; they are just one you will have to invite by hand.
The columns an event actually needs
Fewer than you have. A guest list needs a name the invitation can be addressed to, one channel that reaches the person, a segment (VIP, press, partner, team, family) that decides which door and which report they belong to, a plus-one allowance if there is one, and a language if the invitation goes out in more than one. Everything else — the job title, the company, the note about the seating request — is useful but should not block the row.
Name the columns the same way in every source before you merge. Map “Vorname” and “First name” to one field, and refuse a merge where two columns claim the same field; a merge that guesses is a merge that puts the wrong data in the right place.
Consent, and who is allowed to be on the list
A guest list is personal data. Under European rules, and under most others, you need a reason to hold each row and a way to remove it when asked. The reason is usually obvious — the person is being invited to an event they have a relationship with — but a list built from a purchased database, or from a partner’s contacts without their agreement, is a list you cannot defend.
Keep the consent question simple: for each source, who agreed that these people could be invited, and to what? Write it in the source column. It is also the answer to the guest who asks how you got their address.
Late additions, without inviting anyone twice
The list is not finished when the invitations go out. Four days before the event a client sends three more names; a partner forwards twenty, half of whom are already on the list under slightly different spellings. Adding them by hand to a list that has already been sent is how people receive two invitations.
Treat every late name as a candidate, not a row: compare it with the guests already on the event, by email and by name, and invite only the ones that are genuinely new. The comparison is the same work as the first cleaning pass, done for one person at a time.
A short checklist
Before the first invitation leaves, every row should pass the following.
- One working file; originals kept beside it.
- A source column on every row.
- Duplicates found by email, then by surname, then by phone; the surviving row chosen on purpose.
- Addresses checked for shape, and known-dead ones marked rather than deleted.
- Columns mapped to one set of fields; no two columns claiming the same field.
- A segment and, where relevant, a plus-one allowance and a language on every row.
- A consent note per source.
- A rule for late additions: compare first, invite only the new.