Booking.com — cẩm nang tối ưu listing để lên top

Booking.com — cẩm nang tối ưu listing để lên top

Nguồn: ba tầng, đã tách bạch mức tin cậy — hợp đồng GDT (General Delivery Terms, bản Việt Nam) · Partner Hub chính thức (đọc ngày 11/09/2026 qua Chrome đăng nhập) · bên thứ ba + forum. Mỗi khẳng định đều gắn nhãn nguồn. Quan hệ với file khác: booking.md ghi tình hình thực tế 7 property của mình; file này ghi luật chơi của Booking. Song song với agoda-listing-playbook.md. 📕 Luật truy cập: vault/10-rules/ota-readonly-rule.md — extranet CHỈ ĐỌC. File này là kiến thức + checklist; mọi thao tác sửa chỉ làm khi user ra lệnh cho đúng việc đó.

0. Đọc file này thế nào

⚠️ Quy ước đánh dấu: - 📜 HỢP ĐỒNG = nguyên văn GDT. Cao nhất. Booking tự ràng buộc mình bằng câu này. - 🟩 CHÍNH THỨC = Partner Hub / extranet. - 🟨 SỐ CỦA BOOKING = con số Booking tự công bố trong tài liệu bán hàng. Không dùng làm proof trong content marketing của mình. - 🟠 BÊN THỨ BA = blog/forum, chưa có nguồn chính thức xác nhận. - ❌ SAI / CHƯA KIỂM CHỨNG = xem §11. - ⬜ KHÔNG CÔNG BỐ.

1. 📜 Thuật toán theo HỢP ĐỒNG — nguồn có thẩm quyền cao nhất

Đây là chỗ gần như không ai đọc, nhưng lại là mô tả chính xác nhất. Annex 4 của General Delivery Terms (chính hợp đồng mình ký với Booking) bắt buộc phải công bố tham số xếp hạng theo luật EU P2B. Nguyên văn:

1. Booking.com aims to display search results relevant to each Guest, by providing a personalised default ranking… Booking.com uses multiple algorithms to produce default ranking results, which is a constantly evolving process.

2. Booking.com has identified the following parameters to be most closely correlated with a Guest finding a suitable Accommodation, so prioritises such parameters in the algorithms:   a. the Guest's personal search history   b. the rate of click through from the search page to the property page   c. the number of bookings related to the number of visits to the Accommodation page ("Conversion")   d. gross (including cancellations) and net (excluding cancellations) bookings

3. Conversion and click through rate may be affected by various (stand-alone) factors including review scores (both aggregated scores and components), availability, policies, competitive pricing on the Booking.com Platform, quality of content and certain features of the Accommodation. The Commission percentage paid by the Accommodation or other benefits to Booking.com may also impact the default ranking.

4. The Accommodation may influence its ranking by participating in programs… Genius, deals, Preferred and Preferred Plus, Visibility Booster (the latter three involve paying a higher Commission).

1.1 🟩 Bản Partner Hub nói thêm hai điều quan trọng

Trang Search results, ranking and visibility bổ sung:

"The importance of each factor is determined dynamically for each search and is not based on fixed weightings."

⇒ 🟩 Không tồn tại "trọng số" cố định. Mọi bài blog vẽ ra bảng "review 30%, ảnh 20%, giá 25%" đều là bịa. Không có con số nào như vậy được công bố, và Booking nói thẳng là nó thay đổi theo từng lượt tìm kiếm.

Bốn nhóm yếu tố bản mới liệt kê:

2. 🟩 Mô hình HAI TẦNG — điểm mấu chốt hầu hết blog viết sai

Đọc kỹ Annex 4 sẽ thấy một cấu trúc mà danh sách phẳng kiểu "10 yếu tố xếp hạng" làm hỏng hoàn toàn:

TẦNG 1 — thuật toán thật sự tối ưu cái này
┌──────────────────────────────────────────────┐
│  b. Click-through rate  (search → trang)     │
│  c. Conversion          (đặt / lượt xem)     │
│  d. Gross & net bookings                     │
│  a. Lịch sử tìm kiếm của khách  (ngoài tầm)  │
└──────────────────────────────────────────────┘
            ▲                    ▲
            │ ảnh hưởng qua      │
TẦNG 2 — đòn bẩy mình cầm trong tay
┌──────────────────────────────────────────────┐
│  điểm review (tổng + từng hạng mục)          │
│  tình trạng phòng (availability)             │
│  chính sách (policies)                       │
│  giá cạnh tranh TRÊN Booking                 │
│  chất lượng nội dung (content)               │
│  đặc điểm/tiện ích property                  │
├──────────────────────────────────────────────┤
│  % HOA HỒNG trả cho Booking  ← đi thẳng      │
│  (Preferred · Preferred Plus · VB)   TẦNG 1  │
└──────────────────────────────────────────────┘

Ba hệ quả thực tiễn:

1. Ảnh đẹp không "làm tăng thứ hạng" trực tiếp. Ảnh đẹp làm tăng CTR; CTR mới là tham số xếp hạng. Nên phép thử đúng cho mọi thay đổi nội dung là: "cái này có khiến người ta bấm vào thẻ của mình nhiều hơn không?" — chứ không phải "cái này có làm trang đầy đủ hơn không?".
2. Huỷ phòng bị tính hai lần. Tham số d đo cả gross lẫn net. Một booking bị huỷ vẫn vào gross nhưng rơi khỏi net — tức là khoảng cách giữa hai số chính là hình phạt. Tỷ lệ huỷ cao ăn mòn thứ hạng ngay cả khi lượng đặt thô trông đẹp.
3. Tiền mua được thứ hạng, và Booking viết thẳng điều đó trong hợp đồng. Không phải thuyết âm mưu — §10.

3. 📜 Wide Parity — Việt Nam, và vì sao giá Airbnb ảnh hưởng Booking

3.1 Việt Nam thuộc nhóm nào — đã tra tận GDT

Đọc thẳng bản GDT (admin.booking.com/hotelreg/terms-and-conditions.html?cc1=vn&lang=en, 11/09/2026):

⇒ 📜 Việt Nam = WIDE PARITY. Đây là chế độ chặt nhất trong ba chế độ.

3.2 📜 Wide parity ràng buộc những gì (Annex 5)

(i) "Rate Parity" — cùng giá hoặc tốt hơn cho cùng chỗ nghỉ, cùng loại phòng, cùng ngày, cùng loại giường, cùng số khách, cùng hoặc tốt hơn về tiện ích và add-on (ăn sáng, wifi, nhận/trả phòng sớm-muộn), cùng hoặc tốt hơn về restriction và chính sách (đổi lịch, huỷ) so với những gì mình bán trên website/app/call-centre của mình, trực tiếp tại chỗ nghỉ, với BẤT KỲ đối thủ nào của Booking (mọi đại lý online/offline) và bất kỳ bên thứ ba nào liên quan tới mình.

(ii) "Availability Parity" — phải cấp cho Booking số phòng mở bán ít nhất ngang bằng với bất kỳ đối thủ nào của Booking.

Ngoại lệ duy nhất: closed user group. Giá cho nhóm kín chỉ được miễn parity khi đủ cả bốn điều kiện: (a) khách chủ động đăng ký thành viên, (b) giao diện hiển thị giá có mật khẩu bảo vệ, (c) thành viên đã điền hồ sơ, (d) khách đó đã từng đặt ít nhất một lần với tư cách thành viên. Hễ giá đó lọt ra công khai — kể cả do bên thứ ba hay metasearch — Booking lấy lại quyền parity.

3.3 Hệ quả cho mình — đây là mục quan trọng nhất của cả file

🟩 Trang ranking chính thức viết: Booking không tính tới giá/tình trạng phòng ngoài nền tảng khi xếp hạng — nhưng chỉ dành cho No Parity và Narrow Parity. Việt Nam không nằm trong hai nhóm đó.

⇒ Với 7 căn của mình:

🔴 Ranh giới cần nhớ: đóng Booking vì phòng đã bán thật là hợp lệ. Đóng Booking để giữ phòng ưu tiên cho Airbnb là vi phạm Availability Parity, và đồng thời tự dìm tham số availability ở tầng 2.

🔴 Parity còn là ĐIỀU KIỆN VÀO CỬA của cả ba chương trình miễn phí lẫn trả phí — Genius, Preferred và Preferred Plus đều ghi "if your property is based in a wide-parity… country, you'll need to provide competitive prices on our platform, compared to all other websites". Airbnb rẻ hơn Booking ⇒ có thể rớt điều kiện Genius ngay từ đầu, dù review và số lượng đã đủ.

4. 🟩 Property Page Score — đòn bẩy rẻ nhất, có con số

Ở đâu: Extranet → Property → Quality rating / Property page score (content_score.html).

🟨 SỐ CỦA BOOKING: "Properties with a 100% property page score get up to 18% more bookings than properties with incomplete content." — lặp lại hai lần trong cùng bài, là con số Booking dùng nhiều nhất để thúc đối tác.

🟩 Điểm này chấm những gì: "everything from the photos you display to the type of breakfast you serve, the languages spoken by your staff, and the facilities guests can access, either at your property or in the surrounding area."

Ba điều đáng chú ý về cách chấm:

1. Nó là checklist, không phải điểm thẩm mỹ. Máy đếm ô đã khai — không chấm ảnh đẹp hay văn hay.
2. Nó tính cả tiện ích khu vực xung quanh, không chỉ trong nhà. Đây là mục hay bị bỏ trống nhất.
3. 🟩 Property page score là đầu vào của Quality Rating — xem §5. Nên nó được tính hai lần: một lần cho conversion, một lần qua ô vàng cạnh tên.

🟩 Luật đã học được và phải nhớ (ghi ở booking.md §6d): trường nào Overview còn ghi "You haven't added…" thì Booking coi là CHƯA TỪNG KHAI, không phải đã khai là không có — và nó rơi về một giá trị mặc định có thể sai (ca nôi em bé 100.000₫ của alacarte305). Vào bấm Save với giá trị đúng, kể cả khi giá trị đó là 0.

5. 🟩 Quality Rating — ô vàng cạnh tên, và điều kiện để có

Đây là mục trả lời câu hỏi treo lâu nhất trong booking.md §6: "Quality Rating cho nhà/căn hộ — chưa tìm được trang trong extranet." Trả lời: không có trang riêng. Nó nằm CHUNG trang với Property page score. Property → Quality rating/Property page score. Nếu chưa được gán rating thì trang chỉ hiện page score — đó là lý do trước đây tìm mãi không ra.

5.1 Nó là gì

🟩 Ô vàng hiện cạnh tên chỗ nghỉ trong kết quả tìm kiếm và trên trang property. Không phải sao khách sạn. Khách lọc được theo nó — nên nó ảnh hưởng việc mình có lọt vào tập kết quả hay không, chứ không chỉ thứ tự.

5.2 🟩 Năm nhóm dữ liệu tạo ra rating

"Quality ratings are created by combining factors like the accuracy of property info on the Extranet, which can be divided into five major categories:"

🟩 Và câu quan trọng nhất: "The property page score is an essential part of the quality rating – the higher your property page score, the higher your quality rating." ⇒ §4 là đường vào §5.

5.3 🟩 Điều kiện để ĐƯỢC gán rating — kiểm ngay ba dòng này

11 loại hình đủ điều kiện: Apartments · Vacation homes · Villas · Guest houses · B&Bs · Aparthotels · Country houses · Farm stays · Chalets · Riads · Gites. (Ngoài ba loại đầu — apartment, vacation home, villa — thì chỉ áp dụng cho property có unit riêng và không có tiện ích dùng chung.)

Property phải có đủ ba điều kiện:

🟩 "Once you receive a quality rating, you'll be notified by a banner on the Extranet."

5.4 ⚠️ Chỗ chưa chắc — phải tự kiểm, đừng suy diễn

Điều kiện 1 viết nguyên văn "All rooms or units marked as open and bookable". Booking không nói rõ đây là: - (A) trạng thái cấu hình của room type (không bị đóng vĩnh viễn), hay - (B) mọi ngày trên lịch đều mở bán.

Cách đọc (A) hợp lý hơn — nếu là (B) thì không property nào từng kín phòng có nổi rating. Nhưng 6/7 căn của mình đang có Rate closed dài ngày do channel manager (L-06, L-17), và alacarte305 còn có property song trùng 15702691 đang Closed/Not bookable (L-03). ⬜ Chưa kiểm chứng được cách nào đúng.

👉 Cách xác minh rẻ nhất: mở content_score.html của từng căn, xem có ô Quality rating hay chỉ có page score. Căn nào có rating mà vẫn đang Rate closed ⇒ cách đọc (A) đúng. Ghi kết quả vào booking.md.

5.5 🟩 Highlights và Suggestions

• Highlights — "We analyze over 400 features including facilities, amenities, services, interior photos, and unit configuration, then highlight the categories that set you apart from properties around you." ⇒ so tương đối với hàng xóm, không phải ngưỡng tuyệt đối.
• Suggestions — gợi ý tiện ích nên thêm. 🟩 "currently only available for apartments, vacation homes, and villas" ⇒ đúng loại hình của cả 7 căn. Đây là danh sách việc Booking tự đưa, nên làm theo trước khi tự đoán.
• 🟩 Cập nhật theo chu kỳ, không tức thì: "it can take some time before changes are reflected in your rating."
• 🟩 Không gỡ được rating khỏi trang.

6. 🟩 Ảnh — luật chính thức, và chỗ mình đang làm khác

🟨 "63% of guests use photos as their primary source of information while searching for a stay."

6.1 Số lượng

6.2 🟩 Kỹ thuật — chỗ khác với thói quen của mình

6.3 🟩 Cấm / không nên

Vỡ hạt · mờ · tilt-shift · xử lý quá tay · filter, contrast mạnh, bão hoà, HDR quá đà · ảnh ghép (collage) · watermark hoặc hình minh hoạ · méo/nghiêng/kéo giãn · đen trắng · góc siêu rộng / fisheye · ảnh chứa thông tin định danh (CMND, hoá đơn, hợp đồng) · ảnh chủ yếu để khoe thông tin liên hệ · 🟩 "photos where people are the main focus".

🔴 Đối chiếu nội bộ: luật này đánh thẳng vào thói quen làm ảnh marketing của workspace — overlay chữ, logo, ghép nhiều khung. Ảnh Booking phải là ảnh chụp trần, không chữ, không logo, không ghép. Kho vault/02-villas/images/ dùng được; các bản fbalbum-*/instacarosel-* thì không.

7. 🟩 Review — và luật recency mới

🟩 Từ tháng 01/2025, điểm tổng được tính theo độ mới: "your overall Guest Review Score is weighed by recency, which means the most recent review has the biggest impact."

⇒ Hai hệ quả: 1. Một review xấu gần đây nặng hơn nhiều review tốt cũ. Phục hồi nhanh hơn trước, nhưng tụt cũng nhanh hơn. 2. Property ít review mà lâu không có review mới thì điểm đứng yên và cũ dần — alacarte305 có 11 review, mỗi review mới đổi điểm rất mạnh.

🟩 Review cao mở khoá: Traveller Review Awards · Preferred Partner · Genius. Và 🟩 "Many travellers use the overall Guest Review Score to filter their search results" — lại là chuyện lọt vào tập kết quả, không chỉ thứ tự.

🟩 Thứ tự review trên trang phụ thuộc ngôn ngữ trình duyệt của khách. Review không có bình luận (chỉ có điểm) bị đẩy xuống dưới và không trả lời được.

📜 Nhắc lại Annex 4: tính cả "components" — tức điểm từng hạng mục, không chỉ điểm tổng. alacarte305 có Comfort 8,7 thấp hơn tổng 9,0 → đó là hạng mục cần nhìn.

7.1 🟩 Value for money (VFM)

🟩 "Although it doesn't directly impact your overall score, there's a relationship between good VFM and high-scoring reviews." Ba trục: giá (so với property tương tự) · chất lượng dịch vụ (sạch sẽ, tiện ích, thái độ) · giá trị theo mắt khách. 🟩 Booking nói thẳng: "Lowering rates… is the most likely to improve your VFM in the short-term" — nhưng gợi ý dùng Basic Deal / Genius / Mobile / Country Rates thay vì hạ giá gốc.

8. 🟩 Tình trạng phòng và restriction — trần chặn mọi thứ khác

8.1 Mở lịch xa

🟩 "set reminders to keep your property's calendar open for as far as 24 months ahead" — và "A lot of travellers start looking for places to stay up to a year in advance". 🟨 Trang khác nói có khách đặt trước 16 tháng.

⇒ Không có ngày mở thì không xuất hiện trong kết quả, và mọi tối ưu nội dung đều vô nghĩa cho khoảng đó.

8.2 ⚠️ Restriction là con dao hai lưỡi

🟩 "If a traveller looks for a stay that you've set a restriction for, you might not show up in their search results."

Restriction gồm: min/max stay · closed to arrival / departure. 📜 Annex 4 xếp policies vào tầng 2 — nên restriction vừa chặn hiển thị, vừa hạ conversion.

🟩 Dynamic restrictions — luật tự động nới restriction khi còn phòng ế. Đây là cách giữ kiểm soát mà không tự khoá mình khỏi kết quả tìm kiếm.

🔴 Nhắc: booking.md §2 đã ghi — ô Restrictions ở đầu lịch mặc định bỏ tick. Không tick thì không thấy min-stay đang chặn. Tick trước khi kết luận vì sao không có khách.

8.3 Chỉ số đo được: Availability for search

Có trên Ranking Dashboard. alacarte305 đo 05/09: 27,50 % so với peer group 47 % — gần ba phần tư lượt tìm là căn này không đặt được. 📜 Đây là availability ở tầng 2, và nó chặn thẳng tầng 1: không hiện thì không có CTR, không có CTR thì không có conversion.

9. 🟩 Giá và khuyến mãi

📜 Annex 4 ghi rõ đòn bẩy là "competitive pricing ON the Booking.com Platform" — giá so với đối thủ trên chính Booking, không phải giá rẻ tuyệt đối. Cộng thêm §3: ở wide-parity country, giá ngoài kênh cũng bị soi cho điều kiện chương trình.

Bản cũ của trang ranking còn liệt kê ADR (average daily rate) là một trong năm việc cần tập trung — và Ranking Dashboard trong extranet vẫn hiện ADR là một trong bốn yếu tố. Cách đọc hợp lý: ADR quá thấp thì doanh thu/lượt hiển thị thấp, quá cao thì conversion chết. Không phải "càng rẻ càng lên hạng".

9.1 🟩 Bộ công cụ giá — xếp theo mức xâm lấn tăng dần

🟩 Stacking — Booking khuyến khích chồng nhiều khuyến mãi để tạo mức giá nổi bật. Đây là cách hạ giá hiển thị mà không phá giá gốc (và không phá parity, vì Genius/deal là cơ chế của chính Booking).

⚠️ Nhưng không phải cái nào cũng chồng được — đọc từ khối "Stacks with" trên trang setup của 16927056, 12/09/2026:

"For promotions that don't stack and are applicable, only the largest discount is displayed." ⇒ cặp chồng thật cho property chưa có Genius là Mobile (hoặc Country) + Basic deal.

9.2 🟩 Room/unit differentiation tool

Extranet → Boost performance → room/unit differentiation tool. Gợi ý theo 6 nhóm: tiện ích còn thiếu · tiện ích phổ biến nhất nền tảng · tiện ích có mà chưa khoe · cải thiện ảnh · diện tích chưa hiển thị · dịch vụ độc quyền chưa khai.

🟩 "your property may be more visible in our search results to travellers who've specified this feature in their preferences" ⇒ đây là đường vào bộ lọc, giống Quality Rating. Với căn nhiều phòng ngủ như của mình, đây là công cụ bị bỏ quên rẻ nhất.

10. 📜 Các chương trình TRẢ THÊM HOA HỒNG

📜 Hợp đồng nói thẳng: ba chương trình Preferred, Preferred Plus, Visibility Booster "involve the Accommodation paying a higher Commission", và "The Commission percentage paid by the Accommodation… may also impact the default ranking".

⇒ Đây là đòn bẩy duy nhất đi THẲNG vào tầng 1 mà không cần qua CTR/conversion. Cũng là đòn bẩy duy nhất tốn tiền mỗi đêm bán được, mãi mãi.

10.1 So sánh bốn chương trình

⚠️ Số của Booking tự mâu thuẫn giữa các trang. Genius được ghi +45 % bookings ở bài help nhưng +70 % search views ở trang Increase bookings; Preferred ghi +20 % bookings ở bài help (cập nhật 1 ngày trước) nhưng +35 % ở trang Improve visibility. Dùng bài help — mới hơn. Và tuyệt đối không bê những con số này vào content marketing của mình (§0).

10.2 🟩 Genius — chi tiết cần biết trước khi bật

• Giảm 10 % áp tự động vào phòng rẻ nhất VÀ phòng bán chạy nhất. Nếu hai cái là một thì chỉ áp cho phòng đó.
• Có thể tạm dừng giảm giá: mức 10 % dừng được tối đa 30 ngày/năm; Level 2–3 có thêm 30 ngày cho mức 15 %; Level 3 thêm 60 ngày cho mức 15 % và 20 %.
• Bật ở: Boost performance → Genius partner program.
• 🔴 Đây là chương trình duy nhất trong bốn cái KHÔNG làm tăng % hoa hồng — chi phí nằm ở giá bán. Với căn đang ế thì rẻ hơn Visibility Booster; với căn gần kín thì là tự cắt doanh thu.

10.3 🟩 Visibility Booster — cơ chế và bẫy

Extranet → Boost performance → Visibility Booster. Bốn bước: chọn ngày nhận phòng → chọn quốc gia nguồn khách → kéo thanh mức hoa hồng → Apply new commission rate.

🟩 Booking đề xuất bốn tình huống dùng: ngày cao điểm · ngày ế còn nhiều phòng · nhắm một quốc gia · bán lại phòng vừa bị huỷ.

🟠 BÊN THỨ BA (chưa có nguồn chính thức): mức hoa hồng cộng thêm chạy khoảng 5–30 %, có nguồn nói trần tới 60 %; chỉ tính trên booking đến từ lượt hiển thị được boost.

🔴 Bẫy kinh tế — đây là chỗ mất tiền lặng lẽ nhất. Booster chỉ bảo đảm hiển thị, không bảo đảm đặt phòng. Bật rồi quên trong giai đoạn vốn dĩ sẽ kín phòng thì mình trả thêm hoa hồng cho những booking đằng nào cũng có. Phép thử trước khi bật:

Số đêm tăng thêm cần có để hoà vốn
  = (đêm vốn dĩ sẽ bán được × % hoa hồng cộng thêm)
    ÷ (biên lợi nhuận trên một đêm bán thêm)

Không ước lượng nổi mẫu số thì chưa nên bật. Với danh mục hiện tại, việc rẻ hơn và chắc hơn nằm ở §12 bước 1–3.

10.4 ⬜ Chưa biết — cần đọc trong extranet

• Performance score của từng căn (điều kiện 70 %/80 %): ⬜ Booking chỉ mô tả định tính — "maximum commission your property can generate and the traveler demand for your property type compared to similar properties already in the program". Con số thật chỉ xem được ở Boost performance → Preferred Partner Program.
• Mức hoa hồng cộng thêm cụ thể của Preferred: ⬜ không công bố trong tài liệu, chỉ hiện trong extranet. 🟠 bên thứ ba đoán ~3 %. Vẫn liên quan L-37 (chưa biết hoa hồng gốc của tài khoản này).

11. ❌ Điều bên thứ ba nói SAI hoặc chưa kiểm chứng

Đã đối chiếu 8 nguồn bên thứ ba với GDT + Partner Hub. Danh sách dưới đây là chỗ chúng lệch. Ghi lại để phiên sau khỏi tin nhầm.

11.1 Về tầng "forum" — báo cáo trung thực

Thu hoạch thật từ forum còn đọc được (🟠, là trải nghiệm cá nhân chứ không phải dữ liệu): - Than phiền tập trung vào tỷ lệ huỷ: một host báo 22 booking hoàn tất so với 80 lượt huỷ trên hai property, gọi nền tảng là "Cancel dot com". - Bức xúc vì không được tự viết mô tả, phải tick ô có/không — 🟩 khớp với điều đã biết: mô tả do Booking tự sinh từ facilities/amenities (booking.md §6b). - Hoa hồng ~15 % cộng phí xử lý, thu theo tháng, trừ từ tài khoản ngân hàng.

⇒ Kết luận về tầng forum: với Booking.com, forum không là nguồn đáng tin cho chuyện xếp hạng. Nguồn thật là GDT Annex 4 + Ranking Dashboard trong chính extranet của mình — cả hai đều đã có trong tay.

12. ⭐ QUY TRÌNH HOÀN CHỈNH — xếp theo thứ tự nhân quả

Không phải checklist phẳng. Thứ tự này bám đúng mô hình hai tầng ở §2: mở cửa đã → rồi mới làm đẹp → rồi mới trả tiền. Làm ngược thứ tự là đốt tiền.

Bước 0 · Đo trước khi sửa — 15 phút

Mở Analytics → Your search ranking and booking performance (showrank.html) của từng căn, chép đủ sáu số:

Cách đọc chẩn đoán — ba ca khác nhau, ba cách chữa khác nhau:

🔴 Không bỏ bước này. Cả ba ca trên đều bị gọi chung là "không lên top", nhưng cách chữa ngược nhau: ca 2 cần hạ giá/đổi ảnh bìa, ca 3 thì đổi ảnh bìa không giúp gì.

Bước 1 · Mở cửa — trần chặn mọi thứ khác

Không có bước nào sau đây có ý nghĩa nếu khách không đặt được.

1. Tick ô Restrictions trên lịch trước khi kết luận bất cứ điều gì (mặc định bỏ tick — booking.md §2).
2. Soát min stay / max stay / closed-to-arrival / closed-to-departure trên từng rate plan. Mỗi restriction là một lát cắt khỏi tập kết quả tìm kiếm.
3. Mở lịch xa 12–24 tháng. Chưa có giá cho năm sau thì copy giá năm nay rồi tinh chỉnh sau.
4. Phân biệt cho đúng bốn trạng thái (bảng ở booking.md §2): Rate closed là công tắc ai đó gạt, Sold out mới là hệ quả.
5. 📜 Đối chiếu Availability Parity (§3): lịch Booking có đang mở ít hơn Airbnb ở những ngày phòng thật sự còn trống không?
6. Cân nhắc dynamic restrictions thay cho restriction cứng.

Xong bước này thì: Availability for search phải tiến về mức peer group.

Bước 2 · Đưa Property Page Score lên 100 %

🟨 Mốc này có con số gắn kèm: +18 % booking. Và nó là đầu vào của Quality Rating (§5).

1. Mở content_score.html, làm đúng danh sách Booking liệt kê — không tự đoán.
2. 🔴 Trường nào ghi "You haven't added…" thì vào bấm Save với giá trị đúng, kể cả giá trị đó là 0 (§4). Bỏ trống ≠ khai là không có.
3. Khai tiện ích khu vực xung quanh, không chỉ trong nhà — đây là nhóm hay trống nhất.
4. Khai ngôn ngữ nhân viên, loại bữa sáng, cách nhận chìa khoá.
5. Chạy room/unit differentiation tool (§9.2) và làm theo 6 nhóm gợi ý.

Bước 3 · Chữa CTR — cuộc chiến ở THẺ tìm kiếm, không phải ở trang

📜 CTR là tham số tầng 1 (b). Khách chỉ thấy bốn thứ trên thẻ: ảnh bìa · tên · giá · điểm review (+ nhãn Genius/deal nếu có).

1. Ảnh bìa — ảnh ngang, phân giải cao, cảnh mạnh nhất của căn (bể bơi, view, mặt tiền). 🟩 "that photo can make all the difference between clicking or moving on."
2. Ảnh phải là ảnh chụp trần — không chữ, không logo, không ghép (§6.3).
3. Giá hiển thị — bật Mobile Rate (🟨 +30 % booking) và/hoặc Basic Deal (🟨 55 % khách tìm chỗ có khuyến mãi). Đây là cách hạ giá hiển thị mà không phá giá gốc.
4. Nhãn — Genius tạo nhãn riêng trên thẻ, vừa tăng CTR vừa vào bộ lọc Genius.
5. Tên property — 🔴 kiểm overclaim. Ca 15nuocman5 đang để "Koi Pond" trong tiêu đề ở cả ba kênh trong khi không có hồ koi (L-02) — vừa sai sự thật, vừa là bom hẹn giờ cho review.

Bước 4 · Chữa conversion — cuộc chiến ở TRANG

📜 Tham số tầng 1 (c). Khách đã bấm vào rồi mà không đặt.

1. Ảnh đủ theo luật: ≥4 ảnh/phòng, ≥1 phòng tắm, condo hotel ≥24 ảnh (§6.1). Thiếu ảnh phòng là lý do rời trang phổ biến nhất.
2. Phí và chính sách hiện rõ, không gây bất ngờ. Phí ẩn phát hiện ở bước cuối là nguồn bỏ giỏ hàng lớn.
3. Chính sách huỷ — 🟩 khách lọc "Free cancellation". Chính sách chặt làm tăng conversion giả rồi đẩy tỷ lệ huỷ lên; chính sách lỏng thì ngược lại. Cân theo mùa.
4. Cấu hình phòng đúng — số giường, sức chứa, diện tích m². Vừa là đầu vào Quality Rating (§5.2 nhóm 2), vừa là bộ lọc.
5. Giá so với hàng xóm TRÊN Booking — mở competitiveset.html.

Bước 5 · Giữ tham số d — huỷ phòng ăn hai lần

📜 Tham số tầng 1 (d) đo cả gross lẫn net. Khoảng cách giữa hai số chính là tiền phạt.

1. Đo tỷ lệ huỷ 90 ngày cho từng căn.
2. Huỷ nhiều thường do lệch kỳ vọng (ảnh/mô tả hứa quá) hoặc overbooking do lệch lịch giữa các kênh.
3. Sau mỗi đợt huỷ, dùng Last-minute Deal để bán lại — 🟩 đây đúng là tình huống Booking khuyến nghị bật Visibility Booster.

Bước 6 · Review theo luật recency

1. 📜 Annex 4 tính cả điểm tổng lẫn điểm từng hạng mục — mở hạng mục thấp nhất ra xem (ca alacarte305: Comfort 8,7 < tổng 9,0).
2. Từ 01/2025 review mới nhất nặng nhất (§7) ⇒ nhịp review đều đặn quan trọng hơn điểm trung bình lịch sử.
3. Nhắc khách để lại review sau khi trả phòng — đã có sẵn hệ thống tin nhắn OTA ở vault/16-ota-messages/. 🔴 Nhớ luật: Airbnb cấm xin "5 sao"; Booking không cấm nhưng vẫn nên dùng chữ "review".

Bước 7 · Chỉ đến đây mới xét trả tiền

Theo đúng thứ tự rủi ro tăng dần:

1. Genius — không tăng hoa hồng, chi phí nằm ở giảm 10 %. Bật trước tiên nếu căn đang ế. Kiểm điều kiện: ≥3 review, ≥7,5 điểm, và parity (§3).
2. Preferred — cần performance score ≥70 %. Nhớ khoá 180 ngày nếu rớt.
3. Visibility Booster — chỉ bật có ngày cụ thể, có lý do cụ thể (lấp ngày ế, bán lại phòng vừa huỷ). Tính hoà vốn trước (§10.3).
4. Preferred Plus — chỉ khi đã ở Preferred và performance ≥80 %.

🔴 Đừng đảo thứ tự. Trả thêm hoa hồng để đẩy nhiều khách hơn vào một trang có conversion 1 % là nhân cái lỗ lên, không phải chữa nó.

13. Áp vào 7 căn Harth Living — trạng thái thật và việc phát sinh

Dữ liệu từ booking.md, issues.md và audits/2026-09-05-booking-305-audit-corpus.md. 🔵 = phát hiện mới từ vòng nghiên cứu 11/09, chưa cấp mã L-nn.

13.1 alacarte305 — căn duy nhất có đủ số để chẩn đoán

Chẩn đoán: căn này không phải hỏng nội dung — page score đã 100 %, review 9,0. Nó hiện nhiều hơn peer 27 % mà bị bấm ít hơn 38 %. ⇒ Ba việc theo đúng thứ tự: mở lịch (B1) → bật Genius + Mobile Rate để có nhãn và giá cạnh tranh trên thẻ (B3/B7) → truy nguyên tỷ lệ huỷ 40 % (B5). Làm nội dung thêm nữa là đổ công vào chỗ đã đầy.

13.2 🔵 Phát hiện mới — chưa có mã L-nn

13.3 Việc chung cho cả 7 căn — xếp theo tỷ lệ lợi ích/công sức

14. Nguồn và cách đọc lại

14.1 📜 Hợp đồng — nguồn cao nhất, đọc lại khi nghi ngờ bất cứ điều gì

https://admin.booking.com/hotelreg/terms-and-conditions.html?cc1=vn&lang=en

• Annex 4 — RANKING: bốn tham số + các yếu tố ảnh hưởng + hoa hồng. §1.
• Annex 5 — WIDE PARITY COUNTRY WORDING: Rate Parity + Availability Parity. §3.
• Định nghĩa ba nhóm parity: tìm chuỗi "Narrow Parity Countries" means.

⚠️ GDT đổi theo thời gian và theo quốc gia. Đọc lại bằng cc1=vn mỗi khi có thay đổi chính sách lớn.

14.2 🟩 Partner Hub — đã đọc ngày 11/09/2026

🔴 partner.booking.com trả 403 với mọi công cụ fetch thường. Phải đọc qua Chrome đang đăng nhập:

node scripts/chrome-cdp-daemon.mjs &        # một lần đầu phiên, khỏi bấm Allow nhiều lần
node scripts/chrome-grab.mjs --out <dir> "<url1>" "<url2>" ...

⚠️ Nhiều bài có FAQ GẬP — page.txt mục === TEXT === không chứa câu trả lời. Nội dung thật nằm ở mục === n PANEL GẬP / CHI TIẾT ẨN ===. Riêng bài Quality Rating, toàn bộ §5 của file này nằm trong panel gập, phần TEXT chỉ có danh sách câu hỏi. Đọc thiếu panel là kết luận sai.

14.3 🟠 Bên thứ ba đã đối chiếu

Hostaway · Smoobu · Rentals United · Smart Order · Hostlyft · MARA Solutions · Little Hotelier · AirHostsForum. Không có nguồn nào trong số này đưa thông tin mà GDT + Partner Hub chưa có, và nhiều nguồn sai ở §11. Giá trị duy nhất: trải nghiệm vận hành (than phiền về huỷ phòng, cách thu hoa hồng).

14.4 Đọc lại số của chính mình

node scripts/ota-read-booking.mjs --hotel <hotel_id> --out <dir>   # 26 trang extranet
python3 scripts/listing-data.py show <slug>                        # dữ liệu đã chuẩn hoá
python3 scripts/listing-data.py compare booking                    # so các căn

Trang quan trọng nhất cho file này: showrank.html (Ranking Dashboard) và content_score.html (page score + quality rating).

15. Ghi chép cho phiên sau

• ✅ Đã trả lời câu hỏi treo trong booking.md §6: Quality Rating nằm chung trang với Property page score (content_score.html), không có trang riêng — đó là lý do các phiên trước thử quality_rating.html, quality.html, property_quality.html đều 404.
• ✅ Đã trả lời: điều kiện Preferred (70 % performance + 7,0 review + parity), Preferred Plus (80 % + 8,0 + parity), Genius (3 review + 7,5 + parity), và cơ chế Visibility Booster.
• ⬜ Vẫn chưa biết: con số Performance score thật của từng căn · mức hoa hồng cộng thêm của Preferred và VB (chỉ hiện trong extranet) · hoa hồng gốc của tài khoản (L-37) · cách Booking tính Listing strength.
• ⚠️ Chỗ suy luận, chưa xác minh: cách đọc điều kiện "all rooms or units marked as open and bookable" của Quality Rating (§5.4). Đừng trích file này như thể đã chắc.
• 🔵 Năm phát hiện ở §13.2 chưa được cấp mã L-nn trong issues.md — cần user duyệt trước khi đánh số, để tránh đụng số với agent khác.