SPARK EPOS RESERVATION
A redesigned reservation system that helps restaurants manage bookings more flexibly, reduce lost opportunities, and improve both operational efficiency and customer experience.
Defining the problem & strategy
Project Background
In October 2025, SparkEPOS lost two key merchants due to long-standing issues in the reservation system. These problems were structural and had been building up for nearly a year, eventually affecting merchants’ operations and revenue.
The Problem
The reservation logic did not reflect real restaurant workflows, causing valid bookings to be rejected and leading to merchant churn. In addition, merchants were unable to assign tables, which prevented them from reserving preferred seats for customers.
My Role & Scope
As a Product manger, I was asked to identify the root causes and deliver a practical solution quickly to prevent further loss. As the company’s only UI/UX designer, I was also responsible for redesigning and maintaining consistency across all reservation-related features, including email templates and the timeline interface.
Outcome Direction
Within a 2 weeks timeframe, delivered a full redesign of the reservation ecosystem, covering the customer-facing reservation app, back-end reservation management
The update resolved long-standing issues in reservation handling, improved flexibility for merchants, and reduced booking-related complaints.
Merchants provided positive feedback on the new experience, helping SparkEPOS retain more customers and restore confidence in the reservation system.
Goals & Success Metrics
Goals
Improve reservation flexibility and reduce rejected but valid bookings
Give merchants clearer control over reservations across the admin system
Success Metrics
Higher reservation creation success rate
Reduced reservation-related complaints from merchants
90% merchants reported that bookings are blocked for certain time slots despite available capacity.
Merchants prioritize accepting bookings over enforcing strict system rules
70% of merchants mentioned that the booking timeline is confusing, and unavailable time slots are visually overwhelming
40% merchants want customizable reservation confirmation emails, but only a fixed template is currently available
Current booking rules and UI are too rigid and confusing, preventing merchants from accepting bookings even when capacity exists.
Key Takeaway:
User Research
Through merchant interviews, support feedback, and churn analysis, we conducted a quick user study due to time constraints, interviewing 10 real merchants, and found that:
Persona & Key Scenarios
This project supports two user groups with different needs. Restaurant managers and front-of-house staff use the admin system to create and manage reservations efficiently, especially during busy hours. Customers use the front-end app to book tables and expect a clear, reliable confirmation experience.
Persona 1: Restaurant Manager / Front-of-House Staff (Admin Reservation System User)
Persona 2: Diner / Customer (Front-end App Reservation User)
Design Solution
1.Redefining the Reservation Logic
The original reservation system enforced a strict relationship between party size and dining duration. For example, a party of two was automatically assigned a one-hour dining time, while a party of four was assigned two hours.
This rigid rule often led to wasted availability. If a four-person group wanted to book a table at 6:00 PM, the system required a continuous two-hour slot. Even if a table became available at 4:30 PM, the system would still reject the booking because the full two-hour window was not available.
To address this, I removed the forced binding between party size and dining duration and introduced controlled flexibility into the system.
Key changes included:
-
Dining duration is no longer strictly tied to party size, managers and staff can manually adjust dining time when needed
-
Introduced Time View and Table View to support different operational workflows; Time View means select a time first then choose a table; Table View means select a table first , then choose a time
This approach shifts the system from rigid rule enforcement to informed decision support, allowing merchants to maximize table usage without sacrificing service quality.
Information Architecture
2.Reservation Redesign
This reduced back-and-forth decisions and improved confidence during reservation creation, especially in busy environments.
Key improvements:
-
Combined table and time selection into a single step to reflect their real-world dependency
-
Used visual states and color coding to clearly communicate booking status
-
Supported table combinations for larger parties when needed
Final Design
Before
After
3.Handling Edge Cases Proactively
Several edge cases were surfaced directly in the flow rather than after failure:
-
Clear explanations for unavailable times or tables
-
Warnings when dining time was shorter than the configured minimum
-
Explicit feedback for buffer time and flexible time rules
By surfacing these constraints early, the system helped users make informed decisions instead of blocking them at the final step.
4.Reservation Email Template Redesign
While reviewing the full reservation lifecycle, I identified confirmation emails as a critical touchpoint that lacked flexibility and consistency. To address this, I redesigned the email template configuration experience:
This ensured that booking details communicated to customers always matched the actual reservation settings.
-
Merchants can customize brand elements and message content
-
System-generated booking details are automatically populated and protected
-
A live preview allows merchants to see the final result before applying changes
-
Fallback values ensure emails remain clear even when some customer data is missing
5.Customer-Facing Reservation Experience
Finally, I aligned the customer-facing reservation flow with the updated system logic.Improvements included:
As a result, customers were less likely to encounter unexpected rejections after completing the booking flow.
-
A clear, step-by-step booking process
-
Time options based on real availability
-
Early feedback when selections were not feasible
-
Clear confirmation and payment states
Why This Solution Works
It addresses the root logic problem rather than only UI symptoms
Admin, notification, and customer experiences are aligned around the same rules
The system supports merchant decision-making instead of over-restricting it
The reservation experience is consistent from creation to confirmation
Why This Solution Works
It addresses the root logic problem rather than only UI symptoms
Admin, notification, and customer experiences are aligned around the same rules
The system supports merchant decision-making instead of over-restricting it
The reservation experience is consistent from creation to confirmation
Why This Solution Works
It addresses the root logic problem rather than only UI symptoms
Admin, notification, and customer experiences are aligned around the same rules
The system supports merchant decision-making instead of over-restricting it
The reservation experience is consistent from creation to confirmation
