Kiến thức nền tảng — Booking.com

Lớp kiến thức tích luỹ. Học được gì mới thì thêm vào đây, ghi ngày. Truy cập theo vault/10-rules/ota-readonly-rule.md. ⭐ Muốn hiểu THUẬT TOÁN XẾP HẠNG và quy trình tối ưu listing để lên top: đọc booking-ranking-playbook.md — bốn tham số theo hợp đồng GDT, mô hình hai tầng, wide parity của Việt Nam, Quality Rating, và quy trình 7 bước. File này lo tình hình 7 căn; file đó lo luật chơi.

1. Tài khoản là dạng NHÓM (group account)

Đăng nhập ra Group homepage liệt kê mọi property, không phải một extranet đơn lẻ. Mỗi căn = một hotel_id riêng, không phải một hotel nhiều room type. Cột trên Group homepage (đo 03/09/2026):

ID · Property · Status on Booking.com · Arrivals in next 48 hours · Departures in next 48 hours · Guest messages · Booking.com messages

Tab thứ hai còn: Listing strength · Property page views (30 days) · Search result views (30 days) · Bookings received since listed · First open/bookable on.

→ Hệ quả: muốn biết tình hình toàn danh mục thì đọc Group homepage, đừng đi từng extranet.

2. Bốn trạng thái phòng trên lịch — đừng nhầm

Hàng Room status trong Calendar. Phân biệt bằng còn phòng hay không và có tiền hay không:

• Sold out là hệ quả (bán hết). Rate closed là công tắc ai đó gạt.
• Room status chỉ hiện Rate closed khi TẤT CẢ rate plan của phòng đó đóng cho ngày ấy. Chỉ một plan đóng thì vẫn là Bookable.
• Rate closed mà vẫn thấy giá ⇒ không phải lỗi thiếu giá, mà là đóng chủ động hoặc bị restriction chặn.
• Ô Restrictions ở đầu lịch mặc định bỏ tick — không tick thì không thấy min-stay / closed-to-arrival đang chặn. Tick trước khi kết luận nguyên nhân.

2b. Phí phụ thu — đọc trực tiếp 03/09/2026

Trang extranet_ng/manage/property_policies.html?hotel_id=<id>, mục Additional fees & charges:

Cả 7 property đều không có damage policy với Booking.com.

⇒ Booking chỉ thu phí dọn ở 1/7 căn, trong khi Airbnb thu ở 6/7. Và ngay căn duy nhất đó, hai kênh cũng lệch: Booking 300.000 vs Airbnb 350.000. → L-25

2c. Soát cấu hình giá cả 7 property — 03/09/2026

2d. ⚠️ Rate closed KHÔNG phải lỗi — là chặn chéo kênh

Đã xác minh bằng đối chiếu lịch. 15nuocman5 trên Booking đóng đúng 09–13/09 và 30/09 trở đi; lịch Airbnb cùng căn cho thấy 10–13/09 và 30/09 đã kín. Khớp. alacarte404 bị đóng toàn dải — và Airbnb căn đó đang 100 % occupancy.

Cơ chế: channel manager chặn Booking bằng cách đóng rate, KHÔNG phải hạ Rooms to Sell về 0 — nên Rooms to Sell vẫn hiện 1 trong khi trạng thái là Rate closed. Đó là lý do trước đây tôi đọc nhầm thành lỗi.

⇒ Rút lại một phần L-06 và L-17. Phần "phòng bị khoá" là bình thường. Phần còn lại — Booking bán 0 đêm/30 ngày trong khi vẫn có nhiều ngày mở — mới là vấn đề thật, và nguyên nhân nghiêng về giá, không phải availability.

2e. Ba phát hiện cấu hình

1. Hai property bị kẹp SÀN GIÁ: 181tohienthanh phẳng 3.000.000 và 41lehycat phẳng 4.000.000 — đúng bằng Min Price của chúng. Thuật toán muốn xuống thấp hơn nhưng bị chặn, và PriceLabs đang gợi ý hạ Min cho cả hai (2.850.000 và 3.800.000). ⚠️ Nhưng cả hai đang khai sai BR = 1 nên gợi ý đó sai gốc — sửa BR trước, rồi mới xét hạ sàn.
2. Rate plan không đồng nhất giữa 7 property: 15nuocman5 thiếu Monthly rate · 404 và 25AT11 có Non-refundable Rate còn 5 căn kia không · ba property có Monthly rate gắn Not XML hoặc Set-up ⇒ nằm ngoài dynamic pricing.
3. Non-refundable Rate đang Open ở 404 và 25AT11 trong khi banner tài khoản nói "We've temporarily disabled the non-refundable and prepayment policies". Mâu thuẫn — chưa rõ rate plan đó có thực sự bán được không.

2f. Khách trả gì, Booking giữ gì — đo trên trang khách + Reservations (15/09/2026)

Khách trả  = Σ Standard Rate (PriceLabs đẩy; VAT 8 % khai included nằm TRONG số này)
             + cleaning fee "not included" → hiện thành "+VND X taxes and fees" ngay dưới giá
Booking giữ = 15,00 % × TOÀN BỘ số khách trả (gồm VAT lẫn cleaning fee)
Host nhận   = 85,0 % × khách trả          (pay at property, không phí thanh toán)

• Trang công khai = đúng Σ giá đẩy PriceLabs, 5/5 căn (305 · 502 · 41 LHC · 25 AT 11 · 181 THT), xem lúc đang đăng nhập Genius L1 mà không giảm ⇒ không căn nào chạy Genius / mobile / country rate. Khách không bị cộng 8 % — ghi chép cũ ở pricelabs.md §2g đã sửa.
• Hoa hồng 15,00 % đúng tới đồng trên 12/12 đơn ok của 305 (Jun–Dec 2026) và 3/3 đơn của 41 LHC, đọc từ reservations_retrieve_list_v2 (Reservations, date_from/date_to/date_type=arrival trên URL). Ví dụ 19–22/09: 4.800.000 (3 × 1.500.000 + 300.000 dọn) → 720.000. ⇒ hoa hồng tính cả trên cleaning fee dạng not included (L-31 · L-37).
• Phí dọn đang khai (trang khách 15/09): 305 300.000 · 502 150.000 · 25 AT 11 300.000 · 181 THT · 41 LHC · 15 MN 0 ("Includes taxes and fees") · 404 chưa xem được (không mở bán). So Airbnb cùng ngày: 402.500 · 230.000 · 575.000 · 575.000 · 690.000 · 575.000.
• Weekly Rate −5 % · Monthly −10 % — cùng mức với Airbnb (weeklyPriceFactor 0,95 / monthly 0,9), nên chênh hai kênh giữ nguyên ở lưu trú dài.
• Kết quả so cùng căn cùng đêm với Airbnb: audits/2026-09-15-price-parity-airbnb-vs-booking.md — khách Booking đang trả ÍT hơn Airbnb trung vị +2,6 % tới +17,1 % tuỳ căn (L-97).
• ⚠️ Trang search_reservations.html với dải ngày rộng hay treo >240 s khi đọc bằng chrome-grab — chạy từng property, --settle 4000 --scroll 0, và chấp nhận thử lại.

3. Nhãn XML — quyết định SỬA Ở ĐÂU

Header lịch có thể gắn XML (edits overwritten): property đó nhận availability và giá từ channel manager qua XML. Sửa tay trong extranet sẽ bị ghi đè ở lần sync kế tiếp.

• Sửa ở channel manager / PriceLabs, không sửa trong extranet.
• Hàng rate nào gắn Not XML (ví dụ Monthly rate của 14756473) thì mới sửa tay được.
• Cách kiểm nhanh nhất một property đã nối PriceLabs chưa (11/09/2026): mở rate_plans.html, cột Price của Standard Rate ghi Mapped from PriceLabs là đã nối (41lehycat), ghi Managed by your Calendar là chưa (25anthuong11). Đối chiếu thêm GET /api/pd_dropdown_options bên PriceLabs: hotel_id phải xuất hiện dưới dạng hotelid___roomid với pms_name = bcom.

4. Rate plan quan sát được

Một property có nhiều plan, mỗi plan một hàng giá riêng. Ví dụ 14756473: Standard Rate (×2 Edit) · Weekly Rate-One-Bedroom Ap… (×2 Edit) · Monthly rate (gắn Not XML, có Set-up).

5. Cảnh báo tài khoản đang có (03/09/2026)

• "We've temporarily disabled the non-refundable and prepayment policies." Booking tạm khoá chính sách không hoàn tiền và trả trước cho tài khoản này. Chưa rõ lý do/thời hạn → issues.md L-10.
• Property 15702691 (A La Carte 305) gắn nhãn Closed/Not bookable + "Learn why" — Booking chủ động gắn cờ, không phải mình tự đóng.

6b. Bản đồ trang extranet + cách đọc tự động (04/09/2026)

Mọi trang cấu hình đều theo mẫu admin.booking.com/hotel/hoteladmin/extranet_ng/manage/<trang>?hotel_id=<id>&lang=xu&ses=<ses>. ses là token phiên, lấy từ URL tab đang mở; hết hạn thì mở lại extranet.

Đọc tự động (chỉ đọc): node scripts/ota-read-booking.mjs --hotel <id> --out <thư mục> — bám Chrome đang đăng nhập qua CDP, đi hết 26 trang trên, xuất JSON + _summary.json có tiện ích bật/tắt kèm nhãn. Rồi chép vào properties/<slug>/booking.md theo properties/_template/booking.md. Đã chạy cho 13311503 → properties/alacarte305/booking.md.

🟩 Mô tả property trên Booking KHÔNG tự viết được — Booking sinh từ facilities + amenities, chỉ nhận sửa lỗi chính tả (~6 ngày). Muốn đổi mô tả thì đổi tiện ích. Chỗ duy nhất tự viết là Your Profile → About the Property (2.000 ký tự) và Fine print (qua Request a fix).

6c. Ba bẫy khi đọc nhóm trang mới (05/09/2026)

1. Tám trang mới render phía trình duyệt — fetch GET chỉ trả vỏ trang có chữ Loading.... Bắt buộc đi qua Page.navigate + chờ settle như script đang làm.
2. ses là token cấp TÀI KHOẢN, không gắn với property. Trước đây script đòi tab đúng hotel_id nên báo "không thấy tab" dù extranet đang mở ở Group homepage. Đã sửa: lấy tab admin.booking.com bất kỳ.
3. Điểm hạng mục review bị giấu sau nút Show more — đọc DOM một lượt chỉ thấy 3/7 hạng mục.

6d. Bẫy: ô để TRỐNG khác với khai là KHÔNG CÓ (07/09/2026)

Trang property của alacarte305 hiện Crib upon request — VND 100,000 per child, per night cho nhóm 0–3 tuổi, ngay cạnh câu ngược lại "Cribs and extra beds aren't available at this property".

Truy ngược: Property policies → Extra bed & crib options (crib_and_extra_beds.html) có numCribs = 0 và numExtraBeds = 0 sẵn từ đầu, nhưng phần Overview vẫn ghi "You haven't added any cribs" ⇒ Booking coi mục này là chưa từng khai, không phải đã khai là không. Ở trạng thái trống đó, một chính sách mặc định (nhiều khả năng thừa hưởng từ chính khách sạn A La Carte — property nằm trong toà của họ) lọt xuống trang khách.

Cách sửa mất 1 giây: bấm Save trên trang đó dù không đổi giá trị nào. Nó ghi một bản khai dứt khoát 0 nôi / 0 giường phụ, và dòng 100.000₫ biến mất khỏi trang khách ngay. ✅ Đã kiểm chứng trên 13311503.

⚠️ Ghi chú 12/09/2026: mục này không có snapshot thô trang khách trước lúc sửa (dump _raw/2026-09-04 và 2026-09-05 không chứa dòng 100.000₫; dump 2026-09-08 là sau sửa). Trang khách 305 kiểm lại 12/09 chỉ còn "Cribs and extra beds aren't available". Ở 25anthuong11 ô crib cũng để trống y hệt nhưng trang khách không rò gì ⇒ cơ chế "để trống ⇒ rò mặc định" chưa tái hiện được, coi là giả thuyết từ một lần quan sát, không phải luật đã chứng minh. Lần sau thấy dòng lạ trên trang khách: cào page.txt lưu vào _raw/ TRƯỚC khi sửa.

⚠️ Thêm 12/09/2026: dump alacarte305/_raw/2026-09-08 (một ngày SAU khi Save 0/0) vẫn ghi "You haven't added any cribs / any extra beds" ở property_policies.html. ⇒ Dòng chữ đó là cách Booking hiển thị 0 nôi, không phải dấu hiệu "chưa từng khai". Câu "Overview vẫn ghi You haven't added ⇒ Booking coi là chưa khai" ở trên là suy diễn sai. Không dùng dòng này để phân biệt đã Save hay chưa.

⚠️ Đừng khai Cribs = 1 rồi đặt giá 0₫ để "ghi đè" — đó là khai có nôi trong khi không có, rơi vào amenity not present.

⇒ Áp dụng rộng: trường nào trên extranet mà Overview ghi "You haven't added…" thì nên vào bấm Save với giá trị đúng, kể cả khi giá trị đó là 0 — để Booking không rơi về mặc định.

5c. Tiền chảy đường nào — Finance, và vì sao chưa thu trước được (10/09/2026)

Trên Booking có hai đường thu tiền của khách trước ngày ở. Tài khoản này đang đóng CẢ HAI, cùng một lý do.

Bằng chứng đo được — endpoint XHR của finance_settings.html

Trang này render client-side, page.txt chỉ ra Invoice details + VAT Details. Sự thật nằm trong network/, đọc bằng node scripts/chrome-grab.mjs --out <dir> "…/finance_settings.html?hotel_id=<id>&lang=xu":

⇒ canOptIn = false là câu trả lời gọn nhất: giao diện không những chưa có ô khai tài khoản ngân hàng, mà còn chưa có cả nút xin bật. Không phải mình chưa tìm ra chỗ.

🔴 Bẫy đọc: "Payment Information" trên finance_overview.html là chiều NGƯỢC LẠI

Trang Financial Overview hiện:

Your current payment method: Adyen · Booking.com banking details — Standard Chartered Bank (Vietnam) Limited · SWIFT SCBLVNVX · Account number 33005<hotel_id> · ACCOUNT HOLDER: Booking.com B.V.

Đây là tài khoản mình trả hoa hồng CHO Booking, không phải tài khoản Booking trả tiền cho mình. Số tài khoản còn được sinh từ chính hotel_id (33005 + 14756473). Đọc lướt rất dễ tưởng "đã có ngân hàng rồi".

Cửa chặn thật: property verification

policies.html của 14756473, ngay dưới chính sách Flexible - 1 day:

"Prepayment options are temporarily paused while we finish verifying your property. Until your verification is complete, please collect payment directly from the guest at check-in."

⇒ L-10 không phải hình phạt mà là hồ sơ chưa duyệt xong. Cùng lúc đó home.html báo Non-refundable rates are still unavailable và Set up the basics (0 of 5 completed).

⚠️ Chính sách Non-refundable vẫn TỒN TẠI trong danh sách của 14756473 với dòng "The guest will be charged a prepayment of the total price at any time" — nhưng banner nói prepayment đang tắt. Chính sách còn đó ≠ thu được tiền. Đây là gốc của L-41.

Cách xác minh — đọc từ tài liệu chính thức (10/09/2026)

Link thật (lấy từ chữ "Learn more about property verification" trên policies.html): https://partner.booking.com/node/2103 → Verifying your property's location.

Booking xác minh VỊ TRÍ chỗ nghỉ, không phải danh tính hay tài khoản ngân hàng.

• Không tự chọn được cách xác minh. Booking gán một trong ba: video upload · thư xác minh gửi bưu điện · video call — tuỳ loại hình và vị trí chỗ nghỉ.
• Chỉ phải làm khi thấy banner xác nhận vị trí trên trang Home của Extranet. Không có banner = không có việc gì phải làm.
• Chuẩn bị trước: địa chỉ + ghim bản đồ đúng · tối thiểu 5 ảnh đã tải lên · nếu không có mặt tại chỗ thì uỷ quyền người tin cậy nhận thư/quay video.
• Video (nếu được gán): quay trong vòng 3 tuần, bản gốc — không filter, không ghép, không time-lapse, không tua — và phải một mạch liên tục thấy biển tên đường rồi vào tới chỗ nghỉ.

Hạn chế "No Prepayment" — đây là LUẬT CHUNG CHO MỌI ĐỐI TÁC MỚI, không phải hình phạt riêng. Nguyên văn: "This procedure applies to all new partners." Trong thời gian bị hạn chế:

• Không xem được thông tin thẻ của khách với đơn thường
• Phải thu tiền trực tiếp khi khách nhận phòng (tiền mặt hoặc máy quẹt thẻ của mình)
• Không đặt được chính sách prepayment
• Số điện thoại khách bị ẩn cho tới gần ngày nhận phòng
• Ngoại lệ vẫn xem/charge thẻ được: khách no-show có phí, và đơn non-refundable đã huỷ có phí

Xong xác minh thì: có thông báo trong Extranet · mở lại nhận đơn · nếu dùng PBB thì các khoản payout bị giữ được giải phóng · hạn chế No Prepayment tự động gỡ.

🔎 Đo thực tế 7/7 căn (10/09/2026)

⇒ Không căn nào có việc xác minh vị trí đang chờ. Hạn chế hiện tại là hạn chế đối tác mới nói chung, Booking tự gỡ sau khi duyệt — không có nút nào để bấm cho nhanh. Đường duy nhất tự làm được là hoàn tất Set up the basics và nếu chờ lâu thì hỏi Partner Support.

📌 25anthuong11 đã từ 0/5 lên 2/5 nhờ đúng việc làm hôm nay: Add amenities + Add facilities and services — hai trong năm mục của checklist.

6. Chưa biết — cần học thêm

🟢 Cập nhật 11/09/2026 — ba mục đầu đã GIẢI. Chi tiết ở booking-ranking-playbook.md.

• ✅ Quality Rating cho nhà/căn hộ — KHÔNG có trang riêng. Nằm chung trang với Property page score: Property → Quality rating/Property page score (content_score.html). Chưa được gán rating thì trang chỉ hiện page score — đó là lý do thử quality_rating.html / quality.html / property_quality.html đều 404. Điều kiện được gán: mọi phòng/unit open and bookable + không có star rating sẵn + (nếu đã có review) Cleanliness ≥ 6,0. Năm nhóm dữ liệu tạo rating và mục Suggestions (chỉ có cho apartment/vacation home/villa) → playbook §5.
• ✅ Điều kiện Preferred / Preferred Plus / Genius / Visibility Booster — Genius: ≥3 review + ≥7,5/10 · Preferred: performance score ≥70 % + ≥7,0/10 · Preferred Plus: ≥80 % + ≥8,0/10, xét mỗi 90 ngày, rớt thì khoá 180 ngày. Cả ba đều đòi giá cạnh tranh so với mọi website khác vì Việt Nam là wide-parity country → playbook §3 · §10.
• ⬜ Mức hoa hồng cộng thêm của Preferred và Visibility Booster: vẫn không công bố trong tài liệu, chỉ hiện trong extranet (Boost performance). Cùng gốc với L-37.
• ⬜ Con số Performance score thật của từng căn — chỉ xem được ở Boost performance → Preferred Partner Program.
• ⬜ Cách Booking tính Listing strength và ảnh hưởng tới thứ hạng.
• ⬜ Quy trình gộp hai property trùng (ca 305) mà không mất review.
• ⬜ Channel manager nào đang đẩy XML xuống — PriceLabs hay bên thứ ba khác.

7. Tài liệu chính thức

Chỉ mục đầy đủ 172 bài Booking + Airbnb + PriceLabs + Agoda đã tách sang ../official-docs.md.

Thẻ trên trang kết quả tìm kiếm — dòng nào do ai quyết (đọc 27/09/2026)

Đọc payload FullSearch (site khách) của 4 villa: mỗi thẻ ghép từ các trường Booking tự sinh, chủ nhà không chọn được dòng nào hiện:

Partner Hub (đọc 27/09): "Any facilities you indicate will appear in our filters" · "We analyze over 400 features … then highlight the categories that set you apart from properties around you." ⇒ Không có công tắc "hiện tiện ích này trên thẻ". Việc mình làm được: khai đúng và đủ (vd Airport shuttle phải là free ở cấp property thì mới có nhãn "(free)"), để khách lọc theo tiện ích đó thì căn hiện ra; còn huy hiệu trên thẻ thì do Booking chọn cái nổi bật nhất so với hàng xóm.