Attendee Management

4.0 out of 53 sold

The people, not the tickets. Who is coming, what they need, and how to tell forty of them something without emailing all two hundred.

From$749

Open the preview Request a quote

Function: 24
User types: 2
Platform: iOS & Android

React Native
TypeScript
PostgreSQL
Expo

Inside the app

What it does out of the box

24 connected functions on one schema across 2 user types. Everything below is in the template before a line of customisation.

Self-service profile
Attendees keep their own details current. A register maintained by one person from emails is out of date by the second week.
Requirements
Dietary and access needs captured once and carried to the day, with totals the caterer can actually use.
Segmented messaging
Message the forty people in one session rather than all two hundred. Broadcasting everything is how attendees stop reading anything.
Changes reach the affected
A room change goes to the people in that room, not to everybody.
Consent
Recorded per attendee, per purpose, with a date. Photography, sharing with sponsors, future marketing, each one separately.
The register
Who is coming, who has checked in, who never turned up, exportable and yours.

User types

Two apps, one register.

The attendee maintains their own record, which is the only way requirements stay accurate. Asking an organiser to keep two hundred dietary notes current by hand does not work.

Attendee
2 of 5 screens
The attendee
Keeps their own details current, tells you what they need, and reads only what is relevant to the sessions they chose.
Preview as the attendee
- Update your own details
- Dietary and access needs, kept current
- Only messages relevant to you
- Your sessions and any changes to them
- Nothing shared without consent
Event owner
3 of 5 screens
The organiser
Holds the register, the requirements and the communication, and can message a segment rather than everyone.
Preview as the event owner
- The register with requirements
- Segment and message, not broadcast
- Requirement totals for catering and access
- Changes flow to affected attendees only
- Consent recorded per attendee

The limits

What this is not.

The same list we give for every app in the catalogue, because the fastest way to a bad project is a promise made in a meeting that nobody wrote down.

It carries no audience
A ticketing platform’s fee partly buys discovery. This sells to people you can already reach.
It is not a marketing platform
It messages people about the event they booked. Campaign sending to a wider audience belongs elsewhere.
Data protection is yours
Consent wording, retention and lawful basis where you operate remain your responsibility. We record consent as you define it.
It does not cater your event
Requirement totals go to your caterer. Nobody here is cooking.

Questions

Questions, answered plainly.

If yours is not here, ask it on the call rather than guessing from a pricing page.

Not covered here?

Ask a consultant directly. No form to fill in first, and no follow-up sequence.

Book a consultant All questions

Why let attendees edit their own details?

Because it is the only way the register stays accurate. A dietary requirement typed into a spreadsheet in July is wrong by November, and the person who knows is the attendee.

Can we message just one session?

Yes, and you should. Broadcasting every change to everybody is how people stop reading your emails before the event that matters.

How is consent handled?

Per attendee and per purpose, with a date. Photography, sponsor sharing and future marketing are separate questions and are recorded separately.

Can we export the register?

Yes, any time, in full. It is your list in your database, which is the point of owning this rather than renting it.

Do I get the source code?

Yes. Both apps, API, schema, migrations and deployment configuration transfer on delivery.