Project Context
Redesign the room cancellation policy configuration to increase flexibility, scalability, and ease of use, while aligning with the newly introduced Rate Structure system (Rate Plans & Rate Channels). I worked with another designer and product manager to deliver the redesign of flow and UI mockups.
• Role: UX & UI Designer, UX Researcher
• Scope: Research planning & execution, user flow and visual design
• Timeline: 2.5 weeks
Background Context
In the competitive OTA market, flexibility in hotel booking policies is a key differentiator that directly influences both user trust and conversion.
• For travelers, the ability to modify or cancel reservations without heavy penalties increases booking confidence and overall satisfaction.
• For hotels, flexible policies enable smarter revenue management.
To facilitate this, Traveloka’s internal partner platform, TERA, allows hotels to configure their booking policies.
However, the introduction of a new Rate Structure, including Rate Plans (pricing tiers) and Rate Channels (desktop, mobile app, etc.) introduced new complexity.
The existing cancellation policy tool was limited in flexibility and integration, making it difficult for partners to manage multi-dimensional rate configurations or apply time-bound policies efficiently.
Problems
Goals
Redesigning a room cancellation policy setting that:
Provides greater configuration flexibility
• Allow hotel partners to define and manage cancellation policies by check-in date range and associate them with multiple rate plans and rate channels.
• Support granular policy CRUD operations (Create, Read, Update, Delete) across varying configurations.
Aligns with New Rate Structure
• Integrate with the Rate Structure system (Rate Plan & Rate Channel) to ensure consistent policy behavior across channels.
How might we enable hotel partners to configure flexible cancellation policies that adapt to various room types, rate plans and channels, without compromising ease of use?
User Research
Questions
Before ideating the solution, our team interviewed a few account executives (who manages Traveloka's partnership with hotel managers) to validate assumptions that are key to our problem-solving:
• How do hotel partners configure their cancellation policy?
• How frequent do they change their cancellation policy configuration?
• What drives the changes in configuration?
• Is there any specific behavior that we need to take into consideration?
Insights
1) Cancellation policy is driven based on the business needs to increase booking volume on specific time period
• Hotel partners want to apply stricter or more flexible cancellation policy on specific time period and holiday season.
• The configuration process takes place immediately right after cancellation policy is created.
2) No commonality in changes frequency and behavior – it depends on business needs and happens in granular manner
• Configuration can be as granular as applying a cancellation policy to specific room type and rate plans (e.g Deluxe Room – with breakfast and no breakfast) as well as rate channel (e.g desktop web, mobile app, etc).
• This means we need to provide editing abilities that are modular and agnostic – enabling hotel partners to make changes whenever necessary.
3) Difficulties in tracking the active cancellation policies
This is because the configuration of each cancellation policy (for each applied rate plan and channel) is listed as individual entries, resulting in an overwhelming list of policies.
Approach
The approach below show what solutions can be introduced to solve the pain points
Implementation
Outcome
Increasing the flexibility of cancellation policy can increase hotel's competitiveness and eventually increase their bookings. Our product team predicted that this improvement can drive business outcomes such as:
• Boost hotel booking conversions by 3.5% through enhanced customer confidence and policy transparency.
• Increase policy configuration adoption by 5.2%, leading to better data coverage and reduced dependency on manual ops intervention.
Key Learnings
Given that this is a UI-heavy project, most of the explorations center around the interactions of settings. I went through 5-6 iterations before arriving to the final designs.
This multiple iterations or loop of feedback can be optimized by conducting more design benchmarking (e.g exploring other data-rich applications). Perhaps this will help me in finding the right settings and interactions that can be scaled to multiple levels.
