Product Designer
Role
5 projects/ 16 months
Timeline
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.
A powerful system most customers can't operate is worse than a simpler system that gets used. When I joined in April 2024, availability setup was complex, fragmented, and intimidating.
My Role
I led the design of a phased architectural rebuild of availability from a fragmented, shift-centric setup into a reusable, Mode-based system that's now the foundation for AI-native availability.
Ownership: research, strategy, interaction design, stakeholder alignment, handoff.
Before I'd commit 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.
TL;DR: Where the pain categorized
Across all five streams of research, the problems clustered into four recurring categories: UX/UI, Setup, Troubleshooting/Visibility, and Data/Automation.
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.
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.)
What the Availability setup onboarding process looked like at the time in a nutshell
1
Set up Shifts
Onboarder help Venue to manually set up a Shift which include 4 set of settings : Properties, Capacity, Payments and Policies, Upgrades.
The shift get then duplicated and again manually edited for as many times as needed.
Impact: Availability foundation configured and bookable internally
2
Set up Access Rules
Onboarders help Venues to set up a Access Rule which include 13 set of settings: Schedule, Party size limits, Seating Areas and Tables, Guest facing display, Payment and Policy, Booking channel and audiences, Selectable Upgrades, Duration x party size, Reservation Tag, Booking window, Reservation or Cover limit, Pacing, Guest duration picker.
The AR get then duplicated and manually edited for as many times as needed to create variations of the same Access Rules (Schedules) or a different Access Rule.
Impact: Availability live on Booking Widget (bookable by guests)
More about each research steps below:
Two separate problem-download workshops
Customer configuration audit
Customer interviews
Competitive analysis
What Onboarding looks like
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 strategic arc would collapse into isolated features.
So 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 Floorplan on VMS 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.
However I looked at the Availability Vision at something to work towards by doing some concept-proof testing on the way.
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
Reduced availability tickets by ~44%
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. That's a principle I've used repeatedly since. 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.
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.
Why this was the right bet
f 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.
What are the problems and how we're solving for them
Experiences Require Complex and Redundant Access Rules
Problem
Nuanced settings, like pricing based on time or party size, require complex, time-consuming setups.
Shared information is duplicated across those rules, creating redundancy and management challenges when changes are needed.
Venue employees become afraid of touching Access Rules to make changes
Solution
AI- driven simplicity: Operators can create availability by inputting a desired offering via natural language.
Access Rules are Versatile, but are Time Consuming and lack Guidance
Problem
There is no guidance in the product, which led to a reliance on CS team.
No direction as to how operators can use availability to drive revenue.
Seasonal settings need to be rebuilt yearly.
Solution
The system can auto-populate settings based on Venues' and industry data.
Enable the management of multiple schedules (e.g., seasonal changes) with varying settings inside one rule ensuring minimal effort is required for updates.
Misconfiguration Impact Revenue Potential
Problem
Users are presented with advanced settings, which often leads to overconfiguration (reduction of bookable inventory).
We provide no proactive warning that availability is being limited.
Users struggle to understand the direct consequences of their settings adjustments and how to fix them.
Solution
The current Access Rules become a back-end construct, managed exclusively via the user-friendly interface.
Complex variations (e.g., configurations varying by day, meal period, or party size) are achievable within a single rule.new operator.
Revenue Attribution Challenges
Problem
We can’t accurately track revenue attribution for experiences served through Access Rules due to the free-form nature of their public descriptions (e.g., is "outdoor seating" an experience?).
We’re unable to surface Experience-based ROI data.
Solution
A pre-configured template library to encourage best practice adoption
Existing Offers will be absorbed under availability.
Upgrades can be configured and edited directly from Availability Type, giving operators a centralized tool to implement and manage their upsell strategy.
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?
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.