5-Platform Hotel Price Comparison

The problem

In Chinese OTA workflows, the same hotel on the same stay date can show meaningfully different prices across Fliggy, Tuniu, Tongcheng, Meituan, and RollingGo, while candidate details remain scattered across separate entry points. Engineers or travelers need a more structured way to narrow hotels by city, date, area, landmark, or brand, then compare a specific hotel across platforms, instead of repeatedly copying hotel names, switching pages, and manually checking room types and cancellation policies. For integration use cases, it can also be treated as a lightweight query entry point for Chinese OTA data sources.

How it works

The skill splits the workflow into two states. Without hotel_name, it runs in browsing mode and returns a hotel list with ratings, distance to landmarks, breakfast, windows, cancellation policy, and guest review summaries, making it easier to decide whether a hotel fits. After a user selects a hotel, it enters comparison mode, sends concurrent requests to multiple OTA endpoints through a cloud proxy, parses the responses, sorts by price, and returns the lowest-price booking link. When prices are equal, it follows the commission priority described in the materials, and when cross-platform price gaps are large, it flags the result to avoid mistaking room-type differences for normal price variation. Users can add follow-up filters such as price caps, minimum ratings, or area changes.

Boundaries

The core scope is browsing, comparison, and hand-off; it does not complete booking or query existing order status. Prices change in real time, so the final booking page governs; some platforms may time out, and results may include fewer than five sources. If no date is provided, it defaults to a one-night stay starting tomorrow. It is suitable for quickly filtering city hotels and comparing platform prices for a chosen hotel, but not for order management, rebooking, invoices, or enterprise travel approvals.