Problem
SevenRooms' availability engine was complex, fragmented, and support-heavy: the architecture problem had become the product problem.
Solution
A multi-phase rebuild into a reusable, lego-style system that turned availability into the foundation for automation and AI-native intelligence.
Impact & Results
Stack
Cursor · Claude · Vercel · Figma · Gong · Microsoft Clarity · Firebase · FigJam
In complex B2B, the architecture problem is the product problem.
SevenRooms is a B2B hospitality platform used by restaurants, hotels, and venues worldwide. Availability is the engine underneath the product. Get it right and everything else compounds: revenue, guest experience, operational efficiency. Get it wrong and the whole platform feels broken.
What is Availability
When, for whom, and under what conditions a venue accepts bookings.
I led the design of a phased architectural rebuild of availability from a fragmented, over-engineered setup into a reusable, lego-style system that's now the foundation for AI-native availability.
Before I committed to a phased plan, I needed evidence strong enough to defend a months-long rebuild to the exec team. I ran five research streams in parallel over roughly the first two months.
Simple flows
There is a lot of setup repetition when configuring shifts and access rules. No clear starting point or straight path. Floorplan is a big part of availability however can't be setup on web, where availability settings are created during onboarding.
Minimise redundant access rules
Venues need multiple access rules for the same experience (ie. to attach different policies based on party size or day of week.)
More about each research steps below:
Two separate problem-download workshops
Customer configuration audit
Customer interviews
Competitive analysis
Vision alignment: earning the right to plan phases
If leadership couldn't see the endgame, every individual phase would get re-litigated on its own merit and the strategy would collapse into isolated features.
I facilitated a "Working Backwards" workshop with stakeholders (Product, Engineering, PMM, Execs) starting from the end state and working back to today. We landed on a shared vision and mission.
The output of this workshop gave me: shared language, exec buy-in, and explicit permission to phase the work rather than trying to ship it all at once.
This is also where we identified that a Floor Plan on VMS (Venue Management System) was a critical dependency: without it, availability setup couldn't be streamlined end-to-end.
Vision
SevenRooms powers the most efficient and strategic availability engine in the industry, automating smart decisions so restaurants can focus on hospitality while maximising demand and profitability.
AI-driven revenue management
Intuitive configuration
Personalized optimization
Proactive intelligence
Mission
Enable restaurants to unlock time and revenue potential by making availability setup intelligent, intuitive, and aligned with business goals, reducing operational burden while amplifying performance.
How I sequenced the bets: customers can't wait two years for a rebuild while their day-to-day pain goes unaddressed
A rebuild takes time; customers needed relief immediately.
I looked at the Availability Vision at something to work towards by doing some concept-proof testing on the way.
Short term
Prioritize the UI to improve error resolution and decrease churn: ship a redesigned Access Rules experience.
Long term
The full Core Availability rearchitecture, and then Availability Types on top. Test Operators confidence in AI and coordinate with PM and Data team on the Agent capabilities.
BET 1 - SHORT TERM
Make the system churn-proof: Access Rules redesign
A quick fix against churn
Before we could redesign the underlying architecture, the current system had to become legible enough that misconfiguration was visible and fixable.
Why this was the obvious starting point: churn. Confusion in the Access Rules UI wasn't just a usability cost, it was a retention risk. Venues who couldn't configure or audit their rules at a glance were the same venues most likely to disengage from the product. Fixing the UI was the quickest lever available to protect revenue while the longer rebuild happened in parallel.
The work was in part expensive because the legacy pages had to be rebuilt from Soy templates into React components, and "it's just UI" was not a fundable story. "It's churn insurance" was.
What I explicitly did not do.
I didn't touch the data model. The phase was scoped as UX/UI and stayed there. The point was to make the structural problem legible before redesigning the structure itself.
What shipped and what it cost us.
The Access Rules rebuild was quite design and engineering-heavy because of the Soy-to-React migration. The pay-off was short-term pain relief and, more importantly, visibility: by making the current system legible, we built the internal case for the bigger rebuild that followed.
Imapact
Reduce configuration errors, support burden, and churn from complex availability setups.
Introduced improved Calendar and List views, making it easier for venues to validate availability across days and shifts.
Established research foundation for "next generation avaialability".
Thanks to this and other Availability improvements, support saw about a 44% reduction in availability tickets over the year.
Before
After
“Just want to pass on that I love the changes to the Access Rule page. It works very well and makes things easier”
Shae Cutajarm - Crown
Calendar
List
TESTING / ANALYSIS 50 GONG CALLS
Clearer view of the availability setup issues
Deeper into onboarding issues
After Phase 1 shipped, I ran a second research wave, this time on the onboarding side specifically, analysing the last 50 Gong-recorded onboarding calls. The goal was to uncover deeper onboarding friction now that the UI-feedback noise was cleared.
Two clear thread beneath the mess
Only few settings change between shifts
Almost all venues need multiple Shifts, what vary between Shifts: Duration, Pacing, Payments, and Internal-vs-Online settings (hours, seating areas, guest experience). Everything else is repeated.
More about the calls analysis below:
Checking the numbers
Insights: three structural constraints
BET 2
Give novices a confident default
The bet: Automatic Access Rules
Most venues don't need bespoke Access Rules. They need a sensible default that takes them live. If we could generate that default automatically from a handful of settings, we'd collapse the biggest single friction point in onboarding without stripping power from advanced operators/venues.
From this need the concept of Automatic Access Rule Settings was born. This feature, draws settings from both Shift defaults and new tab in Venue Settings called "Automatic Access Rule Settings".
What are the problems and how we're solving for them
Onboarding Complexity
Problem
The time-consuming and overly complex nature of availabilitY onboarding overwhelms clients, drains CS resources and leaves little time for discussion about revenue-driving features.
Solution
Shift creation alone creates standard availability setup.
Default the most common configurations into quick setups (ie:availability by seating area).
Operators misconfiguration
Problem
Venues frequently misconfigure their access rules. This reduces their bookable inventory, negatively impacting their business and drives high support volume.
Solution
Locked Access Rules set up venues for success by preventing mistakes and ensuring that online availability is a constant.
Product goals and how we measured them
Streamline Onboarding.
Reduce the time and complexity of setting up availability on the first onboarding call.
Target: availability setup during onboarding drops from 20 minutes to 10 minutes.
Simplify Availability Management.
Let operators reach their desired configuration without duplicating settings across Shifts and Access Rules.
Target: >90% of venues with a standard dining offering go live using Automatic Access Rule Settings (excludes multi-concept, eatertainment, and set-menu-only venues).
Maximize Reservations.
Make sure standard online availability is always live, so new venues don't lose bookings in week one because nobody ticked the right box.
Target: Google Reserve activation in month 1 increases from 35% to 45% (a 28% relative lift).
The design tension I had to resolve
How much control do we take from operators in exchange for protecting them from themselves? I landed on: lock the standard cases, surface the advanced controls only when the venue actively needs them. The Automatic Access Rule is by default set up with "Recommended settings" (industry standard / SevenRooms data) that each Venue can customize.
Imapact
Availability setup time on the onboarding call: 20 → 15 minutes
25% faster across 26 beta venues (NAM + EMEA, Aug–Sep 2025). 58% set up in ≤15 minutes. Longest setup: 27 min vs. 36 min on classic Access Rules. Quickest: 5 min vs. 9 min on classic.
The automatic rule held for standard dining.
4 of 26 beta venues created additional manual Access Rules, all for non-standard offerings (prix-fixe, tasting menu, omakase, large-party bookings), not because the automatic rule was broken.
Recommended
Customized
BET1 & 2 CHECKIN
What the first two bets unsurprisingly told us
TL;DR: The problem is not going away
Short-term fixes were working, but the structural problem underneath wasn't going away. Settings duplicated across shifts, no intuitive hierarchy, no foundation for automation. Exactly what Bets 3, 4, and 5 were designed to address.
Phase 1: the system is getting more legible, but it's still complex.
Availability troubleshooting ticket volume dropped consistently month-over-month through 2025, even as the customer base grew. The UI work was doing exactly what it was designed to do: making misconfiguration visible enough that venues could correct it themselves.
But the headline metric told a different story. Total Availability support volume continued to rise: from .066 tickets per venue in 2024 to .082 in 2025. Troubleshooting was going down; other categories of tickets were going up.
Phase 2 : high opt-out
Once Automatic Access Rules rolled out to new venues, we measured opt-out honestly. 35% of new SMB/VSB venues going live in November 2025 opted out of the feature we'd just built for them. The opt-out wasn't coming from the more complex Venues we'd designed around. It was coming from the target audience, whose idea of "standard" was more varied than our rule generator could handle. Main driver:
of dining customization needs unmet. ie: Patio closes at 8pm while the main room stays open until 11pm. Payment required in the dining room but not the tavern.
BET 3
De-risk the big idea on a small surface
The bet: Payments & Duration Modes
Before committing the whole architecture to reusable Modes, test the concept on two contained surfaces. If Modes didn't adopt here, the cost of learning that was small. If they did, I'd walk into any exec review with lived evidence that the concept scaled.
This was the strategic phase. Its value wasn't what it shipped; it was what it de-risked.
The concept I was testing: Modes.
Today, a setting like a payment policy has to be re-entered on every Shift, and when it changes, it has to be updated on every Shift.
What is Mode
A Mode is a reusable group of related settings (for example, "Standard Deposit" could include the amount of the deposit, if it's per person or booking, which policy is attached to it, until when edits can be made to the booking from the customer etc) that's configured once and applied to many Shifts. Edit the Mode once and every Shift referencing it updates. If the pattern worked on two surfaces (payments, durations), it could work for the whole availability system.
The design constraint: no new pages, no major backend changes.
I had to fit Modes into the existing Shift slideout. That was intentional: if I couldn't prove Modes adoptable within the current UX, I wasn't going to convince anyone to rebuild the whole product around them.
The main challenge came from asking the dev team to build a "custom" version of the existing MUI dropdown so that it could host not just a selectable items but also an action. This was possible by demonstrating that the same component was also highly needed in other parts of the product like Marketing and Event Managements.
Why this was the right bet
If Modes didn't adopt here, the cost was small. If they did, we'd have lived evidence that the concept scaled; evidence I could walk into any exec review with.
Why this phase mattered: product goals and how we measured them
Shift Payment activation: +20pp lift
After general rollout: 69.68% adoption among new venues vs. 49.71% legacy baseline (year prior, same launch window).
Modes validated at scale.
No user education campaign, no forced migration, and adoption climbed anyway. That was the signal to commit to Core Availability.
BET 4
Decouple structure from surface
The bet: Core availability (the re-architecture)
From the 50 Gong calls analysis we know that most Shifts settings were always the same and only few changed.
The whole architectural problem could be solved by one structural move: use Modes (re-usable set of settings) as lego-blocks to build the Shift settings.
What is Core availability
Today a Shift owns both operating hours and a bunch of settings (which is why venues end up configuring the same settings three times across three Shifts, and why they drift).
Core Availability decouples the two. Shifts set-up now own only hours of operation. All the availability settings are moved into a new, centralized Mode page, where they're organized into eight sections: Layouts, Seating Area Bookability, Duration, Payment & Policy, Pacing Restrictions, Upgrades, Shift Reporting Period Groups, and Advanced. Each Section holds one or more Modes.
A Shift references one Mode from each Section: so eight Modes make up a Shift. Access Rules, which used to have to be configured manually, are now auto-generated from Shifts plus optional online settings.
Overview of the new Availability setting page which include now Modes, Shifts ad Slot plans. Modes and shifts combined create the base of all availability and can be seen in one place.
What are the problems and how we're solving for them
Redundant Configuration
Problem
Availability setup requires redundant configuration of availability settings across multiple Shifts and Access Rules.
Solution
Modes allow settings to be reused across Shifts and across seasons.
Lack of Guidance and Best Practices
Problem
The system doesn’t provide enough support or suggestions, leaving customers unsure of best practices.
Solution
Modes embed clear defaults, guiding users to the most effective configurations.
Advanced Controls misunderstanding
Problem
Operators are exposed to advanced controls, which they often utilize without clear understanding of their downstream effects.
Solution
Advanced capacity controlling settings are nested, still accessible but not in their face.
The future of Smart settings
Problem
As we move to introduce Automated Revenue Strategies, we need a centralized place where customers can manage Smart Settings.
Solution
Modes which allow us to ‘attach’ different strategies to different shifts. Settings now no longer need to be hard coded on each schedule, but can instead be more dynamic.
The net effect
Edit a Mode once, it propagates to every Shift that references it. No more hunting across Shifts. No more drift. Centralized visibility of how the venue is actually configured.
Rollout and measurement.
Core Availability shipped in April 2026 on a phased rollout: 5–10 friendly venues for beta (weeks 1–3), 10% of venues (weeks 3–4), 50% (week 5), GA (week 6). Target metrics:
Reduce Availability troubleshooting tickets per Venue per month from .036 → .024.
Reduce Availability instructional tickets per Venue per month from .055 → .036.
Drive Shift Payment activation up 30% vs. legacy settings baseline.
Reduce overall Availability support tickets per Rx per month from .092 → .060.
BET 5
Treat AI as a trust problem, not a capability problem
The bet: Availability Types (in progress)
The foundation we've built makes intelligent availability technically possible. But the risk isn't whether the AI can configure a venue, it's whether operators will trust a system they can't fully audit. So every decision is shaped around operator confidence, not AI novelty.
The goal
Replace Access Rules entirely. Not with a better version of what they are, but with a system that's intelligent enough to infer what a venue needs. Operators describe what they want in plain language ("a prix-fixe dinner service Friday and Saturday, guest-selectable patio seating, 2-hour duration") and the system configures the underlying rules accordingly.
We want to enable customers to effortlessly create and manage online experiences with a turn-key approach, providing intelligent templates that handle complex configurations.
The AI Agent
It's essentially a chat interface for editing complex availability settings.
It pulls from two sources of intelligence: a knowledge graph of every configuration field and its rules (so it knows "party size can't be -1"), and a library of 7R best practices per experience type. It validates inputs against those rules and pushes back if something doesn't make sense.
Crucially, nothing goes live automatically: the agent prepares and previews changes, but the operator always manually publishes. This is the core guardrail.
The agent will also introduce a structured flag on Access Rules linked to Availability Types so revenue attribution becomes traceable.
I made the conscious choice to avoid anthropomorphism and I didn't use speech bubbles for Helper's replies. It would have been a manipulative or deceptive UX design choice, used to blur the line between a human and an AI.
What are the problems and how we're solving for them
Experiences Require Complex and Redundant Access Rules
Access Rules are Versatile, but are Time Consuming and lack Guidance
Misconfiguration Impact Revenue Potential
Revenue Attribution Challenges
Validated the mental model
To validate the mental model I built a prototype using a Cursor and deployed to Vercel myself. The prototype tracks whether operators understand the new Type → Schedule → Variations hierarchy, and whether they use AI or manual controls for high-stakes changes.
I also set up the validation stack: Microsoft Clarity for heatmaps and screen recordings, Firebase for event tracking, a shared validation dashboard with PM to track task completion, modality preference, and iteration confidence.
What the prototype is testing — the four risks I'm watching (findings in progress)
Do operators naturally use chat, or revert to manual?
Do they use conversational edits for meaningful changes, or only low-risk ones?
Do they feel safe editing live availability after publishing?
Do they understand the Type / Schedule / Variations hierarchy?
AI (Default)
Manual
Edit settings and ethical AI
I made the choice to allow for edit of one set of settings at the time to avoid overwhelming users with a lot of fields and options. Instead by allowing one set of setting at the time keep them focus on the single action.
I also fought to keep a manual edit at this stage. We're still testing the power of the Availability AI Agent and we want users to always feel in control. Leaving humans in control of AI, including the ability to manually edit, review, or override outputs, is widely considered a cornerstone of ethical AI. It ensures accountability, aligns AI with human values, and mitigates risks such as bias and safety failures. AI often struggles with ambiguity. Human operators bring contextual knowledge that is vital for nuanced decisions, such as in content moderation.
THOUGHTS
What I learned
Pacing matters as much as vision
Every phase shipped real value on its own terms. Keeping each phase self-contained-but-connected is what kept Eng and PM confidence high.
Make the system legible before you change it
Phase 1 UI work was what surfaced the structural problem clearly. Jumping straight to Modes without that foundation would have been fighting against confused-but-entrenched mental models.
Migration is the hard part of B2B design
The thing that actually determines whether a rebuild succeeds is the path you give existing customers from their legacy state to the new world. That's why the "Custom to this Shift" design was an important decision.