Improving Pre‑Sale Service Smoothness for International Hotel Business: Metrics, Challenges, and Quote‑Fetching Scheduling Refactor

In late 2018 and early 2019 the International Hotel business was split from the domestic hotel unit, inheriting the same system architecture that favored domestic traffic, resulting in poor pre‑sale service for international users.

The author, a Java backend engineer, joined the International Hotel team and helped improve both pre‑sale and post‑sale services.

1. Business Background

The international segment includes overseas, Hong Kong, Macau, and Taiwan travel scenarios, covering many countries and cities and involving numerous agents. Although the market potential is large, the system and resources remained domestic‑centric, causing sub‑optimal user experience.

2. Pre‑sale Service

2.1 Metric Definition

Pre‑sale service is defined as the smoothness of the user journey from hotel search (L) through detail (D), booking (B), order filling (O) to payment (P). Smoothness for each stage is the product of price smoothness and inventory (room‑status) smoothness, and overall smoothness is the multiplication of the four stage smoothness values.

The goal was to raise the overall smoothness to 87%.

2.2 L‑D Stage Improvement

The L‑D stage initially had only about 30% of users experiencing price or inventory issues, mainly due to unreasonable system mechanisms rather than frequent real changes.

Two extreme assumptions were examined:

Real‑time fetching for every request – infeasible because agent APIs have limited QPS and high latency.

Full caching – also infeasible because it would cause downstream price/inventory mismatches.

The existing strategy used caching for the L page and real‑time fetching for the D page, which led to poor L‑D smoothness.

2.3 Quote‑Fetching Scheduling Refactor

The quote structure consists of suppliers and wrappers; wrappers are cached per hotel. The original scheduling mechanism displayed cached quotes and sent fetch messages to a scheduler that decided whether to fetch based on elapsed time since the last fetch.

Cache times varied: key wrappers had L‑stage cache 10 s‑10 min, D‑stage 0‑1 min; others followed supplier‑provided cache (10 min‑2 h). Analysis showed that D‑page relies on real‑time quotes, while L‑page also needs timely data despite using cache, because of the large, sparse request volume.

To improve, the team proposed a balanced approach: allocate agent API resources wisely, build an offline‑cache‑driven quote strategy, and automate adaptive refresh for popular quotes, reducing manual configuration.

Key diagrams and data were illustrated with images (omitted here for brevity).

Future articles will detail the concrete implementations that lifted the smoothness metric.