Building BookIt's first event system for the conference floor
Sales teams booked meetings at shows like Dreamforce with a tool built for everyday scheduling. I designed the event system that replaced their spreadsheets and licensing hacks, and helped shape its architecture.
at-risk ARR addressed
named customers and prospects behind that revenue
event-scheduling system in BookIt
BookIt was built for everyday scheduling, not a conference floor
Every meeting runs on a meeting type: duration, availability, questions, confirmation. That works on a normal Tuesday. It breaks at Dreamforce.
No way to say "for these three days, ignore this rep's normal schedule and only book conference meetings."
Demo rooms and booth stations had nowhere to live.
Event teams moved to spreadsheets or competitors. The gap was costing deals.
Every option you hand an admin is a tax
A config-heavy tool turns into a wall of toggles fast. So every decision got one of three answers.
Where the framework got tested
Keep the whole event in one place
BookIt spread a meeting's pieces across separate pages. An admin setting up a conference would have to assemble it from all of them. Now the event holds its meeting types, roster, rooms and activity together.
The cost: more engineering, and ongoing sync between event and global meeting types. A "Dreamforce demo" with a Dreamforce thank-you only makes sense for that event, so keeping it inside kept the global list clean. I judged the admin's clarity worth it.
Protect reps' calendars with something that already worked
Instead of inventing event-only time, BookIt places an Event Hold, a real calendar block, on each rostered rep's calendar for the event hours.
Draw the flexibility line on purpose
Two requests sounded equally reasonable. Only one had no workaround.
Dreamforce sprawls across buildings, some across town. Without scoping a rep to their venues, the system could book a meeting they couldn't physically reach.
Customers said reps are on the floor the whole event, so it was a rare ask. When it came up, reps could already block their off-hours.
One conference, from setup to the post-show report
Venues, rooms, roster, meeting types
Checks before it can activate
Book at the booth, pick a room
Outcomes by rep and room
Build the event once
Rooms have capacity, get auto-assigned, and never double-book.
Add reps or whole round-robin pools. Saving places the Event Hold.
Set up inside the event, kept out of the global list.
It won't activate half-built
An event moves from Draft to Active only when its setup is complete. Instead of a generic "something's wrong," activation names each gap and where to fix it.
Book at the booth
The prospect picks a time. Routing finds an available rep, an open room is assigned, and the meeting is stamped to the event.
For an executive meeting that needs the big room with a projector, schedulers can pick it by hand.
See how the show went
Halfway through, engineering got cut in half
The plan covered all three BookIt booking products. With half the team, I sequenced them by demand times differentiation instead of thinning everything evenly.
The dominant motion at conferences, with the most demand.
A rep books at the booth. Routing makes it the most differentiated.
Personal scheduling links. The least event leverage, so it waited.
Competitors stretched general scheduling to look like event support: no real event, rooms that still needed their own paid accounts. The opportunity wasn't to match them feature for feature. It was to build the structured event system they'd worked around.
What this taught me
A coherent system is its own discipline
This wasn't a set of screens. It was an object model, calendar mechanics that had to stay truthful, routing and a status lifecycle, all holding together. The work that mattered most was keeping the whole thing in my head, and making each decision serve the system rather than one screen.
The strongest decisions were what not to build
Absorbing complexity into what the system already had. Deferring flexibility that had a workaround. Cutting scope on purpose when resourcing halved. Knowing where to stop protected users from complexity and the team from a timeline it couldn't hit.
