🧠 Background
Platform: Pigeonhole Live is an audience engagement tool used in events, meetings, and conferences.
Feature: This project aimed to reduce the manual workload for event organizers by allowing attendees to register themselves. Before this, organisers had to upload attendee lists manually—which didn’t scale well, especially for public events or events using SSO (Single Sign-On).
🔍 Problem / Opportunity
Previously, there was no way for attendees to self-register, and SSO access alone wasn’t enough. For example, event staff or vendors without an SSO domain couldn’t join the event easily. The lack of a flexible registration system created friction during live events.
We needed a system where attendees could self-register, and organisers could define how strict or open that process would be.
🎯 Goals
Let attendees self-register via a form
Let organisers decide how long Registration stays open
Lock events so only registered attendees (SSO or otherwise) can enter
Give SSO organisers the flexibility to allow non-SSO entry too
🛠 What I Did
Mapped out the different attendee types and how they enter (SSO, code, embed, API, etc.) to ensure consistency.
Registration system flow:
User flows:
Discussed with the team to Redefined what a "registrant" is in our system. Moving from just "uploaded attendees" to anyone with a valid profile (SSO or otherwise)
Designed the self-registration flow including form link generation, entry validation, and confirmation screen
Added controls for organizers to customize when registration is allowed
Designed Confirmation screens which adapts based on attendee type, time, and entry method
Designed screens for error states, and SSO fallback access
💡 Edge Cases Handled
Email not required? Show attendee code on screen
No registration allowed during event? Block access or reroute
Returning user before event live? Show “You’ve registered” page
SSO-only with no fallback? Enforced strict access
🧪 Results
We introduced a more flexible registration model that supports various event types—from private internal events to large public ones. Organisers now spend less time managing lists, and attendees have a much smoother path to join events.
Highlights:
Form links are obfuscated to prevent unwanted access
Confirmation screens are fully brandable, and include event details and ICS calendar invites
Organisers can toggle real-time restrictions, like only allowing pre-registered SSO users
SSO users are now given an alternative login method if enabled—supporting smoother access for third-party partners
Basically this whole redesign gave organizers flexibility and control over who can access their events, while also supporting a wider range of attendees. It reduced manual overhead, improved accessibility (especially for mobile users), and made the attendee journey smoother.
What i learned
What worked well:
Giving organizers more control over how people join events made a big difference. Letting attendees register themselves made things way easier, especially for big or public events.
What was tricky:
Figuring out all the ways people could enter (SSO, links, codes, etc.) was more complicated than expected. We had to make sure everything worked smoothly for both organizers and attendees, no matter how they joined.
Next time:
I’d explore adding clearer feedback for organizers—like seeing how many people registered in real time—and maybe even tools to send reminders or updates directly from the dashboard.
