Agoda PBS Config: Price shopping and comparison

Introducing an approval flow for price shopping and comparison at Agoda

Role

Product Designer

Industry

Enterprise B2B

Tag

Web App Design

Stage 1. Problem Statement and Opportunities

Project Overview: What is the PBS Config tool? How did it support Agoda's business?

During my time at Agoda, I had the opportunity to support the Agoda PBS Config team. This team owned this incredible tool to compare Agoda's prices to its competitors at scale (with large volumes of price comparison). By automating price comparison at scale, many teams across Agoda leveraged the tool to enhance our pricing strategies.

In the initial MVP delivered by the team, the team had yet to consider implementing a gatekeeping mechanism. As such, they needed help controlling the flow of shop requests from various Agoda teams. I came in and designed an approval flow that admins would control.

Your Role:

As a product designer, my primary role was to develop an approval flow to manage incoming configuration requests effectively. I collaborated closely with the PBS Config team, which included business analysts, data analysts, and developers, to introduce this essential feature. We aimed to ensure that only approved requests were processed, improving the tool's efficiency and reliability.

Challenges:

The biggest challenge in introducing an approval process was determining the most relevant information for the admin team to approve incoming requests. Additionally, the tight timeline posed another significant challenge, as I needed to deliver the design within a sprint and a half.

Stage 2. Research and Ideation

2.1 Opportunity to Align with a New Design System

Given the limited timeframe for this project, I collaborated closely with the product owner to define the requirements for the new approval flow through regular design syncs. An audit of the existing product revealed that the MVP portal had been built without a designer’s input and relied on Bootstrap for its user interface, resulting in a functional but outdated product.

I proposed leveraging Agoda’s existing design system, the Agoda Design System (ADS), to address this issue. Using ADS would reduce the time to production by utilizing its extensive library of pre-built components. Additionally, the PBS Config team would receive support from the ADS team during the adoption phase. This adoption would streamline the design process and align the product with other Agoda applications, ensuring a cohesive and modern user experience.

Although the engineering team was concerned about a major overhaul, the benefits of adopting ADS far outweighed the effort required.

2.2 First Iteration

The first step of the design was refreshing the existing table list of all configs using ADS.

As I worked on the table, I sought to understand the most important information for an admin user when deciding to approve or reject a config request.

The primary user of this new portal provided valuable insights into the information her team needed to make decisions.

Information Needed from an Admin’s Perspective:

Information on the Config Itself:
- Config ID
- Config Name
- Config Run Frequency
- Number of Shops
- Cost of Each Config
- Approval Status
- Assignment Type (indicating which team is requesting this type of config)
- Config Relationship (indicating whether this is a parent or child config)

Information on the Parameters of the Shops Done:
- Lead Time
- Length of Stays
- Occupants
- Domain Segment
- Currency
- Language
- Origin (whether this is a domestic or international booking)

Information About the Requestor:
- Who Created the Config
- When the Config Was Created

Given the extensive information about the configs, we designed an intuitive interface where users could easily drill down into specifics without being overwhelmed by excessive initial details.

2.3 Additional Changes

Through further syncs with the product owner, we decided to nest all actions under a hamburger menu to streamline the user interface.

2.4 Final Iteration

In the final iteration, we addressed edge cases for various scenarios:

Handling approvals of config requests
Handling denials of config requests
Managing system errors on the backend during config requests
Handling filtering

This comprehensive approach ensured the design was robust and user-friendly, accommodating various potential issues.