Skip to content
Conclave

Event registration for institutions

From the first sign-up to the last person through the door.

Conclave is one system for the whole registration operation — the form, the approvals, the entry pass, the reminders, the door on the day, and a record of who did what — instead of five tools that never quite agree.

See the demoHow it works
Every event separate
Its own workspace, team, templates and sender identity. The separation is enforced in the data layer, not just hidden in the interface.
The door keeps working
QR check-in runs in a browser on any phone. Lose the network and it holds the scans on the device until the connection returns.
Run it in your country
The whole stack is Docker Compose — app, Postgres, Redis, worker — so it can sit inside your own jurisdiction.
01The problem

Five tools, and none of them agree.

Most registration operations are not run in a system. They are run across whatever was to hand the first year, and every year since has added a workaround rather than removed one.

A form tool
Registrations arrive as form responses. Anything you did not think to ask on day one — category, dietary, accompanying person — is simply not there when you need it.
A spreadsheet
The list is exported once and starts diverging that afternoon. Two people are editing a copy. Three, if somebody mailed it on.
Somebody's inbox
Approvals happen in a reply thread. The decision exists, but only inside one mailbox, and only for as long as that person is reachable.
A mail merge
Reminders go out from a personal account against whichever export was to hand. What was delivered, what bounced, what was never sent at all — none of it comes back.
A printed list and a highlighter
The door is paper and two volunteers. Duplicates get through, the arrival count is an estimate, and reconciliation is a job for Monday.

Nothing reconciles. The number who registered, the number approved, the emails that actually arrived and the people who actually walked in are four different figures — and who approved this, and when? has no answer anywhere in the stack.

02The delegate journey

One record, followed the whole way through.

The same registration carries every decision made about it. Nothing is re-keyed between stages, so nothing has to be reconciled afterwards.

  1. 01

    Register

    A public form or invitation only, with your own fields. Or import the list you already hold.

  2. 02

    Approve

    By hand or automatically. One at a time, or the whole pending queue at once.

  3. 03

    Issue

    Approval issues the signed QR entry pass and sends the confirmation in the same step.

  4. 04

    Remind

    Scheduled 14 days, 3 days and 1 day out against the event date, then a thank-you.

  5. 05

    Check in

    A scan in a phone browser at the gate. No app, and it survives losing the network.

  6. 06

    Report

    Delivery records, exports, and an audit log of every consequential action.

And when they cannot come

A delegate releases their own place from a link in their confirmation email. It takes two deliberate steps, so a corporate link scanner cannot cancel someone by accident. The seat returns to you, and the organiser sees who released it and the reason they gave — rather than finding out at the door.

03Capabilities

What replaces the five tools.

Four things a form, a sheet and a mail merge cannot do between them, however carefully they are held together.

03.1

Approvals that finish the job

In most stacks, approving means changing a cell and then remembering to do three more things. Here it is one action: approving a registration issues the signed QR entry pass and sends the confirmation in the same step. An approved delegate is, by definition, one who has been told and holds a pass.

  • A public form or invitation only, per event — with your own fields.
  • By hand or automatically; one at a time or the whole pending queue at once.
  • The pass is signed, so a pass you did not issue does not scan.

03.2

Messaging you can prove was delivered

Email and WhatsApp both come from inside the platform, against templates you edit there — versioned, and previewable against a real registration before anything goes out. Every message then carries its own delivery record, so “they must not have seen it” stops being a theory.

  • Each event sends under its own name, from-address and reply-to.
  • WhatsApp is mapped to the templates Meta has approved for your sender.
  • Reminders scheduled against the event date — 14 days, 3 days, 1 day — then a thank-you.
  • Sent, delivered, opened, bounced, failed. The failures collect in one view.

03.3

The door, including when the venue Wi-Fi gives out

Check-in is a QR scan in a browser on whatever phones and tablets are already in the room. Nothing to install, nothing to ship, no volunteer standing at a gate waiting for an app store. And when the network goes — which, in a basement ballroom, it does — scanning simply continues.

  • Scans are held on the device while the connection is down and synced when it returns.
  • A command centre with arrivals live by gate and by device.
  • A conflict queue for the scans that need a person to decide.

03.4

Governance, for the question that comes afterwards

Access is granted per event rather than once, globally, and forgotten. A gate volunteer can admit a delegate without ever reading their phone number, because contact details are masked from any role that does not hold the PII permission.

  • Roles per event: check-in operator, registration manager, viewer, event admin.
  • Event separation is enforced in the data layer, not by a filter somebody has to remember.
  • A full audit log of consequential actions, with reports and exports alongside it.

Also in the platform

  • A ten-step guided setup wizard — eight steps optional, and nothing written to your account until the last one.
  • The event's web address is derived from its short name and checked for availability.
  • CSV import with column mapping, row validation before anything is written, and duplicate matching.
  • A registration list with search, status, category and check-in filters, saved views and export.
  • A signed webhook endpoint, an integration guide and a developer console.
  • Self-reported health for the database, the queue and the workers.
04Data residency

Or run the whole thing in your own country.

Conclave ships as a Docker Compose stack — four services, no managed dependency you cannot see. If your ministry, your regulator or your own board requires that delegate data stays inside a particular jurisdiction, it can: you host it there, and what leaves your boundary is only what you asked to be delivered somewhere.

  • Next.js

    The application and the public registration pages.

  • Postgres

    Every registration, decision and audit entry.

  • Redis

    The queue behind scheduled and outbound messages.

  • Worker

    Sending, syncing and the scheduled jobs.

The platform also reports its own health — database, queue and workers — so whoever hosts it can tell that it is alive without having to ask us.

How self-hosting works
Next step

See it run one event, end to end.

A working walkthrough — set an event up, approve a registration, watch the pass and the confirmation go out, then check the delegate in. Then a live instance you can press the buttons on yourself.

See the demoHow it works

Or write to hello@conclavedesk.com.