Eventleash has few concepts and one way of combining them. Once that clicks, every screen becomes predictable: you always know where a piece of data lives, and why.
It is worth reading once before you upload your first list: half the questions we get come from mixing up a contact and a guest.
The chain
Everything flows one way:
Account → Contacts → Event → Guests → Campaign → Messages → Answers → Check-in
Each step adds something without duplicating what came before. That is why your second event costs so much less work than your first.
Contacts are the address book, not the event list
A contact is a person: name, email, phone, company, socials, notes. It belongs to the account and to no event in particular.
The distinction that matters: the email address identifies the contact. Re-import an updated list and whoever is already there is updated, not duplicated. Which is why you can safely reload that file your client sends you slightly different every time.
A contact who unsubscribes stays in the address book but stops receiving: unsubscribing applies to the whole account, not to one event. That is a legal obligation as well as a good idea.
An event is a date, a place and a list
An event holds when, where, what it is called, what it looks like and which rules it follows: whether people get in with a QR code, whether there are time slots, whether companions are allowed.
Active events count against your plan's limit. Archiving a past one makes it read-only and frees the slot without losing anything: all the data stays browsable.
A guest is a contact attached to an event
This is the knot. A guest is not a copy of the contact: it is the link between that contact and that event, plus everything that concerns only that occasion — whether they confirmed, how many companions they bring, which slot they picked, what time they walked in.
What follows in practice:
- Fixing an email in the address book fixes it everywhere, past events included.
- The same person can be a guest at ten events: still one contact, with ten different stories.
- Removing a guest from an event does not touch the contact in the address book.
A campaign is an email to the guests of an event
A campaign always belongs to an event. You pick the template, the subject and who should get it — every guest or some of them — and on sending it produces one message per recipient.
The message is the individual copy: it is what tracks delivery, opens, clicks and bounces. The statistics you see on the campaign are the sum of its messages.
An event usually has several campaigns over time: the invitation, the nudge to those who did not answer, the reminder the day before, the thank you. How many you can have per event depends on your plan.
Landing pages are where the answers land
A landing page is a public page, on your own domain, attached to an event. In its RSVP form it is where a guest confirms or declines, declares their companions, picks a slot and gives their privacy consents.
What they fill in comes straight back onto the guest: there is no manual step, and the list you look at on the day is already up to date.
Accounts and users
The account is the workspace: it holds the address book, the events, the domains, the subscription. An agency working for several brands can have more than one and switch between them from the menu at the top.
The people on your team join an account with a role:
| Role | What they can do |
|---|---|
| Administrator | Everything, settings, domains, users and billing included |
| User | Works on contacts, events, campaigns and landing pages; does not touch account settings |
| Host | Sees events and check-in only — the right role for the staff at the door |
Data never crosses between accounts: each one has its own address book, and a contact does not move from one to another.
Where to start
If you have just opened your account, the order is this: connect your sending domain, then create your first event. The rest you learn by doing.