This is a long overdue post 😛! On July 15 (Sunday), we had a successful conference Google I/O Extended KL 2018, bring together 400+ local developers, 3 tracks and 18 speakers to learn about latest Google technologies. The event planned and ran by 4 core members with the help of 50 volunteers.
In this series (well, a series of only 2 articles), I will share about:
- Part 1: How we plan & manage the actual day event flow — give you an idea on how things work before jumping into the app (if you are new to organizing conference, it might help!)
- Part 2: The conference managing app & how the app is build — all in 3 days — with the use of Angular, Firebase, Google Sheets API and Chart.js, run at $0 cost (thanks Google ❤ for generous free quota!)
Building a PWA Conference Management App in 3 days [Part 2/2]
If you would like to know the background of the conference and event management flow, checkout the part 1 of this…
Some backgrounds of the 4 core organizers, each of us has event organizing (meet up, workshop,) experience, but none of us host a tech conference before with this scale (400 is a big number for us!). Well, challenge accepted, we can do this! 😎💪
What to Manage on the Day?
There are 3 main checkpoints we have in the event:
- Registration (8–9.30am): there are two tasks during registration — verify user id (national identity card or passport) & badge distribution.
- Goodies distribution (8–9.30am, 4–5pm): distribute goodies like bags, bottles, t-shirt to attendees (according to their pre-selected size), ensure that everyone just get it once.
- Lucky draw dropbox(3–5pm): lucky draw entitlement based on stickers quantity (collect 3 by visiting partner booths) and survey completion status (Google Form), ensure everyone enter lucky draw only once.
Also, the core team need to track the real time status of each checkpoints, monitor & adjust resources if necessary.
How could We Handle Checkpoints at Speed?
The team spends quite sometimes to discuss about what can we do to speed up the above mentioned checkpoints.
Below are the questions we asked ourselves and our decision on each:-
How to handle the flow of registration & badge pickup?
The main discussion is around how to split & manage the registration queue. Should we split the queue by the first alphabet of attendee name? What if there are 100 people names start with “A” and only 2 with “X”?
After all, we decide to pre-assign each attendee a 4 digits badge id.
The format of badge id would be something like this XXX–X (e.g. 123–4):
- First digit indicates the ticket types (general, volunteer, sponsor, exhibition, etc)
- Last digit is a checksum to verify the ticket
Attendees must provide the below info during sign up:
- Full name as per identity document (national id, passport)
- T-shirt size
After sign up, they will receive their badge id via email. Email sent via mailchimp in bulk.
By doing this, attendee flow become predictable. We split the registration counter by ticket types, then further split it into multiple lines.
We also discuss about whether to allow badge pickup one day before the event, the answer is no, because:
- We want verify real attendee — no attend on behalf (because we have a long waiting list)
- Event venue only available on the day, setting up pick up station elsewhere require additional approval & permit
How many volunteers needed to handle registrations?
How many registration lines should we have? Is one volunteer enough to handle each lines? How long does one registration take?
The happy path of attendee registration would be:
- Attendee shows identity document & badge id email
- Volunteer verifies name & last 4 digits of the identity document
- Volunteer find the badge from the bulk of badges
- Attendee leaves the line
There might be unexpected scenario happen where:
- Attendee does not know their badge id (e.g. missed the email)
- Unmatched attendee name, identity document & badge id
- Attendee record not found
Also, Malaysian culture of attending event is “last 10 minute” 🤷 🤦, when stated the keynote start at 9am, attendees might reach at 8.50am, the queue might be overloaded for the last 10 min if not handle properly. After 9am, we expect registration slow down, the number of registration lines & volunteers should be cut down & rearrange to other tasks.
To cut down the time spent on unexpected scenario, our arrangement to handle the above is:
- Brief volunteer on acceptable / unacceptable margin errors before the event. For example, minor name spelling errors, minor identity id mistake are acceptable.
- Registration counter will ONLY handle happy path. Before attendee queue for registration, make sure they have all necessary items prepared (badge id, identify document). We have volunteers (assistants) around the area to assist them (e.g. helping them to search for badge id).
- All remaining unexpected cases will be passed to “station master” to handle, we expected these cases are minimal (in fact, it’s really minimal, less than 5 cases)
The registration lines will definitely run smoother with less unexpected scenario, but there are still quite a few tasks to be handled by each registration line, how can we speed it up? Here is our solution:
- Each line handles around 50 registration (total 7 lines)
- All badges arrange in sequence so we have faster badge finding process
- Each line will be handled by 2 volunteers at peak hour (8–9am), one verifies attendee identity, one finds the badge
- After peak hour, lines will be cut down to 4. Each lines will be handled by only 1 volunteer. (in fact, we cut down to only 2 lines after 9am)
What should be printed on badge?
Discussion mostly around how should the badge id be printed? We narrow down to 3 options:
- NFC card: Easiest way to scan and checkin, but we scrap this option because NFC card is out of our budget.
- QR code : Scannable, alternative to NFC, but we scrap this option as well because we think we don’t need it.
- 4 digit ID: Simple, easily viewable & identify, we choose this
We also printed full name, t-shirt size and ticket type on the badge. We use different background colours to depict ticket types too because:
- volunteer in yellow tag — easily identify them when attendees need assistance
- exhibitor in orange tag — exhibitor pass not allow to enter event hall for the talk
Should we distribute goodies during registration?
By doing so, we can cut down one checkpoint and the number of volunteers. However, we decide to split it because:
- we allow attendees to pick goodies (e.g. pick favourite bottle colours) and we have different t-shirt sizes, these activities will definitely slow down registration
- registration is crucial, slowing down registration mean possible delay of conference keynote.
We then decide to have goodies distribution done in a room with two queues, split by shirt sizes. There is a checkpoint before goodies hall, volunteers will need make sure each attendee only enter the hall once.
How can we make sure attendees stay for the whole event?
Good sessions definitely is the main reason people stay for the event. However, besides good sessions, we want the attendees to be excited as well. We have 6 partner booths (more goodies!), we want to encourage attendees to visit the booths.
Besides that, we also want to gather feedback from the attendees. Feedback is important for us to organize next event better.
By combining these 4 objectives:
- making sure attendees stay till the end of event
- encourage attendees to visit partner booths
- gather feedback from attendees
- making the event excited
We came out with one solution — lucky draw* !
Recognise the * symbol after lucky draw? That means terms and conditions apply, haha 😆.
Each sponsors will be given their company logo stickers, to be distribute to the booth visitors.
We setup two pretty simple lucky draw rules. To get lucky draw entry, attendees need to complete the tasks below:-
- collect 3 different stickers from sponsor booths
- complete survey / feedback Google Form at 3pm
- verified by volunteer & drop the lucky draw ballot in lucky draw counter
Below is how the lucky draw checkpoint arrangement looks like:
Now you see how we plan out each of the checkpoints and event flow. You probably can see can probably see how building an app can further smoothen the processes. Next, let’s find out how we build the app to help managing the event & get to what we want.