Quy Tắc Tin Nhắn OTA (OTA Messaging Rules)

Quy Tắc Tin Nhắn OTA (OTA Messaging Rules)

Nguồn sự thật cho MỌI tin nhắn gửi khách qua Booking.com · Airbnb · Agoda. Bắt buộc đọc trước khi viết, sửa hoặc dán bất kỳ tin nào trong vault/16-ota-messages/. Khảo sát tài liệu chính thức 31/08/2026. Mục 8 ghi rõ luật nào đã xác minh, luật nào là suy luận.

Nguyên tắc gốc: ba nền tảng này không cạnh tranh nhau ở chỗ khách — chúng cạnh tranh ở chỗ giữ khách trong hệ sinh thái của mình. Gần như mọi điều cấm dưới đây đều quy về một mục đích: chặn host kéo khách ra ngoài. Hiểu được động cơ đó thì tự đoán đúng luật ngay cả với tình huống chưa có trong file này.

0. Cổng bắt buộc — chạy trước khi đưa bất kỳ tin nào cho user

Khi user nói "đưa tin nhắn <loại> của <nền tảng>", agent phải làm đủ 6 bước:

1. Xác định nền tảng trước, viết sau. Không có bản "dùng chung ba nơi" — xem mục 7.
2. Quét bảng cấm (mục 1) trên từng câu của bản gốc.
3. Cắt phần vi phạm, thay bằng câu an toàn ở mục 6 — không xoá trắng làm mất thông tin khách cần.
4. Đối chiếu fact với property_details_<slug>.md + business.md (giờ, giá, tiện ích, đưa đón).
5. Kiểm định dạng: bỏ **, ##, bullet markdown — hộp tin OTA không render.
6. Khai báo với user: đã cắt gì, vì sao, dẫn chiếu điều nào trong file này.

Nếu user yêu cầu giữ một câu vi phạm: nói rõ rủi ro một lần, rồi làm theo ý user và ghi vào mục "Còn mở" của file tin đó. Quyết định là của user, không phải của agent.

1. Bảng cấm nhanh

🔴 cấm · 🟡 vùng xám / có điều kiện · 🟢 được phép

1.1 Chỗ nào để placeholder, chỗ nào ghi thẳng

Chỉ để placeholder cho thứ đổi theo từng booking: tên khách · ngày nhận phòng · ngày trả phòng · mã đặt phòng. Ghi thẳng giá trị thật cho thứ cố định: địa chỉ · giờ nhận phòng · giờ trả phòng · Wi-Fi · mã cửa · số điện thoại.

Áp cho cả Airbnb, dù Airbnb có shortcode address / check-in time kéo thẳng từ listing. Lý do: bản dán đọc ra chữ thật nên soát được bằng mắt, và không ai chèn nhầm shortcode. Đánh đổi: đổi giờ trong listing thì phải sửa tay file, không tự đồng bộ nữa. (user chốt 31/08/2026)

2. Airbnb — nghiêm nhất trong ba

2.1 Off-Platform Policy (bản 5/2025) — vùng cấm nặng nhất

Airbnb cấm host giao tiếp, thanh toán, hoặc chia sẻ thông tin liên lạc ngoài nền tảng. Cụ thể trong tài liệu chính thức:

• Cấm thu tiền ngoài Airbnb. "Requesting, sending, or receiving payments outside of Airbnb is prohibited." Tiền phòng và mọi phụ phí bắt buộc (dọn dẹp, thú cưng, hồ bơi…) phải khai trong ô giá của Airbnb lúc đặt. → Mọi đoạn "thu tiền phòng khi nhận phòng" phải bị xoá khỏi tin Airbnb.
• Cấm chia sẻ SĐT, email, mạng xã hội trong tin nhắn, ảnh listing hoặc phần mô tả.
• Cấm chèn link đưa khách ra ngoài — kể cả link cẩm nang nhà, form đăng ký, dịch vụ cộng thêm. Nguyên văn: cấm "requiring guests to follow a link or share contact details to access any part of their stay — including booking, check-in, guidebooks, or extra add-ons".
• Cấm xin email khách qua hệ thống tin nhắn hoặc email alias, kể cả sau khi đã đặt phòng.
• Cấm giảm giá để dụ đặt ngoài nền tảng.

Ngoại lệ duy nhất, rất hẹp: sau khi đặt phòng đã được xác nhận, host được xác nhận lại thông tin liên lạc do chính Airbnb cung cấp, hoặc dùng kênh liên lạc khác nếu khách là người chủ động đề nghị.

Hệ quả thực tế cho Harth Living: câu "contact us via WhatsApp/Zalo at +84 798 229 922" không được đặt sẵn trong tin Airbnb — kể cả tin gửi sau khi đặt phòng. Ngoại lệ đòi khách phải hỏi trước, chứ không phải host chào mời trước. Nếu khách nhắn xin số, lúc đó trả lời số là hợp lệ.

Chế tài: treo listing hoặc xoá vĩnh viễn tài khoản với vi phạm lặp lại hoặc nghiêm trọng.

✅ Bản mẫu đã chạy thật: Check-in 41 Lê Hy Cát — tin Airbnb Harth Living đang dùng, do user cung cấp 31/08/2026. Nó thoả đủ mục 2.1: không có đoạn thu tiền, không có SĐT, không có link ngoài, chỉ dẫn về app Airbnb. Khi cần viết tin Airbnb mới, lấy file đó làm khuôn.

2.2 Review Policy

Nguyên văn: "Reviews may not be provided or withheld in exchange for something of value — like a discount, refund, or a reciprocal positive review." Cấm cả việc gây áp lực để tác động tới nội dung review, và cấm doạ review xấu để đòi bồi thường.

→ Không được xin "5 sao". Câu an toàn: "we hope you will be kind enough to leave us a review" — mời đánh giá thì được, gợi ý điểm số thì không.

2.3 Giấy tờ tuỳ thân

Được xin sau khi đặt phòng nếu listing đã ghi rõ đây là yêu cầu pháp lý. Việt Nam có luật đăng ký tạm trú nên Harth Living đủ căn cứ — nhưng phải gửi ảnh hộ chiếu trong tin nhắn Airbnb, không qua WhatsApp, không qua form/link ngoài (link ngoài vi phạm mục 2.1).

3. Booking.com — thoáng về liên lạc, chặt về đặt trực tiếp

• Thanh toán tại chỗ là bình thường khi listing cấu hình như vậy → đoạn thu tiền mặt/chuyển khoản giữ nguyên được.

3.1 Số điện thoại: được, nhưng KHÔNG "bình thường" như Airbnb là "cấm"

Booking.com không có điều khoản cấm đưa số điện thoại vào tin nhắn — khác hẳn Airbnb. Nhưng họ khuyến cáo ngược lại, nguyên văn trên trang Trust & Safety cho đối tác:

"We strongly advise you to not give out your personal contact info to a guest until you meet — try to keep all communication within our platform."

Đọc đúng ba tầng:

Với Harth Living: +84 798 229 922 là số vận hành doanh nghiệp, không phải số cá nhân của Huy hay Hannah → nằm ở tầng 🟢. Giữ trong tin Booking là hợp lệ.

Nhưng cách viết vẫn quan trọng. Hai rủi ro thật, không phải rủi ro chính sách:

1. Đặt WhatsApp trước và gọi nó là "faster" thì câu đó đọc thành đang kéo khách ra khỏi nền tảng — đúng thứ bộ lọc của Booking soi. Nên để app Booking đứng trước, số điện thoại đứng sau như phương án phụ.
2. Bối cảnh lừa đảo WhatsApp giả danh Booking.com (rộ từ 2023, vẫn còn 2026): khách đang được cảnh báo cảnh giác với tin nhắn WhatsApp liên quan tới Booking. Một tin đẩy khách sang WhatsApp có thể bị chính khách nghi là lừa đảo.

• Đưa SĐT khi khách chủ động hỏi: hoàn toàn an toàn ở cả tầng chính sách lẫn tầng niềm tin.
• SĐT khách có thể chưa hiện nếu đặt phòng cách ngày đến hơn 14 ngày; số sẽ xuất hiện trong Extranet khi gần ngày nhận phòng. Đừng viết tin dựa trên giả định là có sẵn SĐT khách.
• Link bị kiểm soát bởi Messaging security settings trong Extranet: host tự khai link nào được phép tới khách, hoặc chặn toàn bộ link. Muốn gửi link thì phải whitelist trước, không thì khách không nhận được.
• Review: đối tác không được viết review hộ khách và không được tặng ưu đãi để đổi lấy review. Review chỉ nhận trong vòng 3 tháng sau khi trả phòng.
• Cấm circumvention — mời khách lần sau đặt trực tiếp để né hoa hồng là vi phạm hợp đồng đối tác, không chỉ vi phạm chính sách nội dung.
• Cần quyền admin trên Extranet mới tạo/sửa được template.

3.2 Cú pháp placeholder của Booking.com (xác minh 01/09/2026)

Sau khi chèn từ menu, Extranet hiển thị placeholder đúng dạng [TÊN_MÃ] chữ hoa trong ngoặc vuông — trùng khít với token trung tính mà workspace này vẫn dùng làm bản gốc:

[FIRST_NAME] · [CHECKIN_DATE] · [CHECKOUT_DATE] · [CHECKIN_OPEN_TIME] · [CHECKOUT_OPEN_TIME]

Hệ quả: khối dán Booking viết thẳng [FIRST_NAME], không cần ký hiệu «...» như Airbnb/Agoda — chép xong soát bằng mắt là khớp.

🟢 ĐÃ XÁC MINH 22/09/2026 — gõ tay ĂN, không bắt buộc chèn từ menu. Đọc thẳng DOM trình soạn template (messaging/settings.html → tab Message templates → mở một mẫu): thân tin là một <textarea> thường, và giá trị của nó chứa chuỗi chữ literal [FIRST_NAME] · [CHECKIN_DATE]. Không có node đặc biệt, không có thuộc tính ẩn. Ô chip xám bo góc chỉ là cách trang danh sách vẽ lại khi xem trước — không phải cách Booking lưu. → Dán hay gõ tay [FIRST_NAME] cho ra đúng một kết quả như bấm nút menu. Kéo theo: ghi mẫu tin Booking bằng script là khả thi (native setter trên <textarea> rồi Save, giống Agoda).

⚠️ [CHECKOUT_OPEN_TIME] là bẫy — đã xác nhận qua menu. Menu placeholder có hai nút tách bạch cho mỗi mốc giờ: Check-in time / When check-in ends, và Check-out time / When check-out ends. Tức Extranet khai giờ theo khoảng, và [CHECKOUT_OPEN_TIME] (nút Check-out time) lấy đầu khoảng — hồ sơ khai from 07:00 to 11:00 thì khách nhận 07:00, không phải hạn chót 11:00. Hạn chót nằm ở nút When check-out ends.

Đừng dùng [CHECKOUT_OPEN_TIME] cho câu "giờ phải trả phòng". Cách né đang dùng: tách tin theo nhóm chỗ nghỉ có cùng giờ rồi gõ thẳng giờ — đúng luật 1.1 và không phụ thuộc mã nào. Bảng 12 nút đầy đủ ở placeholders.md.

Ngoại lệ duy nhất cho luật 1.1 (thứ cố định thì gõ thẳng): tin dùng chung cho nhiều chỗ nghỉ mà giá trị khác nhau giữa các chỗ. Hiện không tin nào rơi vào diện này — check-out đã tách A La Carte (12:00 noon) và villa (11:00 AM).

4. Agoda — ràng buộc kỹ thuật nặng hơn ràng buộc chính sách

• ⚠️ Agoda TỰ ĐỘNG CHE số điện thoại, email và số thẻ trong tin nhắn, thay bằng ký tự X. Đây là luật kỹ thuật, không phải khuyến nghị — viết số vào là khách nhận được một chuỗi XXXXX vô nghĩa và mất luôn thông tin. → Tin Agoda không được dựa vào số điện thoại trong thân tin. Cách đúng: dẫn khách trả lời ngay trong app, hoặc gọi số hiển thị trên xác nhận đặt phòng Agoda (Agoda tự gửi thông tin liên lạc của chỗ nghỉ cho khách sau khi đặt thành công — với điều kiện chỗ nghỉ đã khai số trong hồ sơ YCS).
• Agoda không chia sẻ thông tin liên lạc của khách cho chỗ nghỉ (viện dẫn luật bảo vệ dữ liệu) — mọi liên lạc đi qua Agoda Customer Messaging.
• ⚠️ SAI TỪ 31/08, ĐÃ SỬA 04/09/2026: Agoda CÓ công cụ gửi tự động. Đọc trực tiếp trong YCS (portal.agoda.com → Guest messages → Automation tools) thấy hai mục: Scheduled messages và Auto reply, cùng khối Template replies (Create new). Khảo sát 31/08 kết luận Agoda "không có engine hẹn lịch" là sai — nhiều khả năng do đọc tài liệu Partner Hub cũ thay vì mở chính YCS. Chưa đọc được các mốc kích hoạt mà Scheduled messages hỗ trợ (thao tác bị chặn quyền 04/09) → chưa biết có mốc "sau khi đặt phòng / trước khi đến / sau khi trả phòng" như Airbnb và Booking không. Cho tới khi đọc được, đừng viết bộ tin Agoda theo giả định phải gửi tay.
• Không có placeholder. Tên khách, ngày tháng phải gõ tay — dễ sai, phải soát trước khi gửi.
• Review: Agoda chỉ đăng review của khách đã xác minh và có kiểm duyệt. Tài liệu công khai không nêu rõ việc cấm xin review tốt (xem mục 8), nhưng nguyên tắc "authentic, honest, unbiased" đủ để coi việc xin "5 sao" là rủi ro.

4.1 Đọc từ tài liệu chính thức + chính YCS (04/09/2026)

Ba nguồn: trang How can guests communicate with you? · How can I start using Agoda's Customer Messaging? · đọc trực tiếp YCS của property 63382515.

Mốc thời gian Message scheduler cho phép chọn (đọc trong YCS 04/09/2026)

Mỗi hàng mốc là một accordion, chỉ bung ra khi bật công tắc của chính nó. Trong hàng có ba thứ: ô Select a time, ô Include a message template* (bắt buộc, có dấu sao) và cặp nút Cancel / Save — chưa bấm Save thì chưa có gì được lưu.

🔴 Hai mốc lệch NGƯỢC CHIỀU nhau. Check-in đếm lùi trước ngày đến; check-out đếm tiến sau ngày đi. Nghĩa là không có cách nào gửi tin trước ngày trả phòng trên Agoda. Bản Booking đang gửi tin trả phòng vào tối hôm trước; trên Agoda sớm nhất chỉ là On the day of check-out. Ai bê nguyên mốc của Booking sang sẽ chọn nhầm.

Độ lệch tính theo ngày, không có tuỳ chọn theo giờ, và không biết Agoda bắn vào giờ nào trong ngày.

Chỗ trống này lại mở ra một cơ hội: 1 day after check-out là mốc đúng cho tin cảm ơn sau kỳ nghỉ (06-post-stay) — nằm gọn trong cửa sổ liên hệ 14 ngày. Nhưng mỗi mốc chỉ gắn được một mẫu tin, nên phải chọn: dùng At check-out cho tin dặn trả phòng, hoặc cho tin cảm ơn, không thể cả hai.

Hệ quả cho bộ tin: tin check-in Agoda gửi trước 1 ngày được, đúng bằng mốc đang dùng bên Booking. Không bị ép gửi đúng lúc khách nhận phòng như lo ban đầu. Độ lệch tính theo ngày, không có tuỳ chọn theo giờ.

⚠️ Tên nội bộ của các phần tử (dùng khi đọc lại bằng CDP): công tắc sched-msg-toggle-{booking|checkin|checkout} · accordion sched-msg-accordion-* và accordion-{BOOKING_CONFIRMATION|CHECKIN_MESSAGE|CHECKOUT_MESSAGE} · nút lưu sched-msg-save-*.

Cảnh báo Agoda tự dán trong mọi cuộc trò chuyện

Đọc nguyên văn trong hộp thư YCS 04/09/2026:

"IMPORTANT: This feature allows direct communication between guests and booking suppliers. As these interactions are not within Agoda's control, we cannot be held responsible for any issues that may arise. Please exercise caution and discretion before taking action to prevent falling victim to scams and fraud. Report any requests to communicate outside Agoda's platform to safety@agoda.com. This conversation may utilize generative AI and will be recorded; please do not share personal or sensitive information here. Your use of this feature is subject to Agoda's Terms of Use and Privacy Policy."

Ba điều rút ra, đều ràng buộc cách viết tin:

1. Cấm mềm việc xin giấy tờ tuỳ thân qua chat. Agoda nói thẳng với khách đừng chia sẻ thông tin cá nhân hoặc nhạy cảm ở đây. Hộ chiếu và visa đúng là loại đó. Không phải điều cấm có chế tài, nhưng khách vừa đọc câu này xong lại nhận tin đòi ảnh hộ chiếu thì rất dễ nghi là lừa đảo.
2. Nội dung chat bị ghi lại và có thể đi qua AI. Ảnh hộ chiếu gửi vào đây là nằm trong hệ thống Agoda, không phải chỉ giữa hai bên.
3. Agoda mời khách tố cáo mọi yêu cầu liên lạc ra ngoài nền tảng về safety@agoda.com. Càng phải giữ mọi tin trong app, và càng phải cẩn thận với mục đòi tiền.

Rủi ro còn lại chưa có tài liệu nào phủ: Agoda không công bố cách nhận diện số điện thoại. Mã cửa 8 số như [đã che] (đầu 081 trùng đầu số di động VN) và mật khẩu Wi-Fi 8–9 số vẫn có thể bị bộ lọc bắt nhầm. Doc thu hẹp rủi ro chứ không xoá được — chỉ thử thật mới biết.

5. Luật chung — không thuộc nền tảng nào nhưng vẫn ràng buộc

• Dữ liệu khách: email và SĐT lấy được qua OTA chỉ được dùng cho chính đặt phòng đó. Đưa vào danh sách gửi marketing về sau là vi phạm cả chính sách nền tảng lẫn nguyên tắc bảo vệ dữ liệu, trừ khi khách đã đồng ý minh thị (opt-in có lưu vết). Booking.com còn ẩn email thật của khách sau alias.
• Luật Việt Nam — đăng ký tạm trú: khách nước ngoài phải khai báo tạm trú; property_details_* đã ghi yêu cầu ảnh hộ chiếu + visa/dấu nhập cảnh. Xin sớm ở tin 02-pre-arrival để đỡ tắc ở sảnh, nhưng đúng kênh của từng nền tảng (mục 2.3).
• Fact: mọi con số, giờ giấc, tiện ích, chính sách đưa đón phải khớp property_details_<slug>.md và business.md. Ưu đãi đã dừng thì không được tái sử dụng — ví dụ đưa đón khứ hồi 5+ đêm đã dừng 25/08/2026, chỉ còn một chiều cho 3+ đêm.
• Định dạng: hộp tin OTA là plain text. Không **đậm**, không ##, không bảng markdown. Cần nhấn mạnh thì VIẾT HOA hoặc tách dòng.
• Emoji thì ngược lại — hiển thị bình thường trên cả ba nền tảng, và Harth Living đang dùng emoji làm nhãn mục trong tin Airbnb thật (🚪 Check-in Instructions · 🌐 Wi-Fi · 💬 Need Help). Đây là cách thay heading hợp lệ duy nhất trong môi trường plain text. Giữ nguyên, đừng "dọn" đi.
• Tên riêng: luôn viết đủ A La Carte Danang Beach Hotel (user chốt 03/07/2026). Tên host hiển thị: Hannah (không viết Hana).
• Ký tên cuối tin: booking/ và agoda/ ký Harth Living Team (user chốt 01/09/2026). airbnb/ vẫn ký Huy — chưa đồng bộ, hỏi user trước khi đổi.
• 🔴 Lời chào cuối KHÁC NHAU theo loại tin, và đó là cố ý — đừng thống nhất lại (user chốt 05/09/2026). 01-confirmation ký Best, · 03-checkin ký Cheers, · 05-checkout ký Thank you, and have a safe trip. Agent đã một lần tự đổi cả bộ Agoda sang Warm regards, với lý do "nhất quán + máy dịch sạch hơn"; user yêu cầu trả lại nguyên trạng. Không nhất quán trông thấy được không có nghĩa là lỗi — dòng ký là giọng của user, không phải hạng mục format.
• Giọng: tin OTA là hội thoại 1-1, ấm hơn copy marketing. Luật "0 dấu chấm than" trong voice-english.md hiệu chuẩn cho nội dung một-tới-nhiều, không áp cứng cho tin nhắn khách.

6. Câu rủi ro → câu thay thế an toàn

7. Ma trận: loại tin × nền tảng — phải cắt gì

8. Độ tin cậy của từng luật

Đã xác minh trên tài liệu chính thức của nền tảng: Airbnb off-platform (cấm thanh toán ngoài, cấm chia sẻ liên lạc, cấm link, ngoại lệ hẹp, chế tài) · Airbnb review policy (cấm đổi chác/gây áp lực) · Airbnb ID sau khi đặt phòng · Booking.com messaging security settings (kiểm soát link) · Booking.com review guidelines (cấm viết hộ, cấm incentive, cửa sổ 3 tháng) · Agoda che SĐT/email/số thẻ thành X · Agoda không chia sẻ liên lạc khách · Agoda không có gửi tự động.

Suy luận từ nguyên tắc, chưa có câu cấm minh thị: Booking.com và Agoda không có văn bản công khai cấm thẳng việc xin "5 sao" — mình xếp 🟡 vì cả hai đều cấm incentive và đòi review "unbiased". Rủi ro thấp nhưng khác 0. Nếu muốn tuyệt đối an toàn thì dùng câu trung tính ở cả ba kênh.

Đã sửa sau khi kiểm lại (31/08/2026): ban đầu file này xếp việc đưa SĐT trên Booking.com là 🟢 "bình thường". Sai — Booking khuyến cáo ngược lại bằng văn bản. Không cấm, nhưng không phải vùng trắng. Xem mục 3.1.

Chưa xác minh, cần kiểm khi có tài khoản: partner.booking.com chặn truy cập tự động (HTTP 403) nên các trang trợ giúp đối tác chỉ đọc được qua bản tóm tắt của công cụ tìm kiếm, không phải nguyên văn — riêng câu khuyến cáo ở mục 3.1 lấy nguyên văn từ booking.com/trust_and_safety/partners.html đọc được trực tiếp. · Agoda có gửi SĐT chỗ nghỉ cho khách hay không phụ thuộc hồ sơ YCS của Harth Living đã khai số chưa — cần vào YCS xác nhận trước khi dùng câu "call the property number shown on your booking confirmation".

Chính sách OTA đổi thường xuyên. Nếu file này quá 6 tháng kể từ 31/08/2026 mà chưa soát lại, phải kiểm tra lại các link ở mục 9 trước khi dựa vào để viết tin.

9. Nguồn

Airbnb: Off-platform policy · Chính sách thu phí trực tiếp · Authentic and trustworthy reviews · Scheduled messages · Quick replies · Bối cảnh siết chính sách 5/2025

Booking.com: Templates & automatic replies · Messaging security settings · Review guidelines · Handling guest reviews · Trust & Safety cho đối tác — nguồn câu khuyến cáo ở mục 3.1

Agoda: Customer Messaging · How can guests communicate with you · Guest reviews

Liên quan: Kho tin nhắn OTA · Bảng token · Quy tắc copywriting · Quy tắc làm việc