Chủ khách sạn mini, nhà nghỉ hay homestay bán phòng qua vài kênh OTA thường dừng lại ở cùng một câu khi tính chuyện đổi phần mềm khách sạn: "Đổi xong, đặt phòng trên kênh có mất không? Có phải làm lại từ đầu trên Booking, Agoda không?" Lo như vậy là lo đúng chỗ: với nhiều khách sạn nhỏ, phần lớn khách đến từ kênh OTA, và một đơn rơi mất vào tuần đông khách có thể thành một phòng bỏ trống, hoặc hai khách cho một phòng.
Câu trả lời ngắn: đổi phần mềm quản lý không phải là đổi kênh OTA. Tài khoản, hạng phòng, giá và đánh giá của khách sạn trên từng kênh vẫn nằm nguyên ở phía kênh. Khi chuyển sang DiCloud, khách sạn giữ nguyên hãng quản lý kênh đang dùng, và DiCloud kết nối hai chiều với hãng đó, với điều kiện hãng quản lý kênh ấy đã có kết nối với DiCloud. Các hãng đã kết nối có trong danh sách hãng quản lý kênh đã kết nối trên dihotel.vn, vì DiCloud được phát triển từ nền tảng gốc DiHotel. Nếu hãng khách sạn đang dùng chưa có trong danh sách, khách sạn phải đổi sang một hãng quản lý kênh đã kết nối. Điều này cần biết trước khi ký, không phải sau.
Bài dành cho khách sạn 1–3 sao bán qua hai đến bốn kênh OTA, nơi người làm Sale thường cũng trực quầy. Chuyển dữ liệu, tránh nhận trùng phòng, giữ tiền cọc, đào tạo lễ tân đã có ở các bài trước. Ở đây chỉ bàn phần kênh OTA: cái gì giữ nguyên, cái gì phải chuyển, ai làm, theo thứ tự nào.
Phần 1: Đổi phần mềm khách sạn — vì sao chủ khách sạn sợ mất đặt phòng OTA
Nỗi lo thường gồm bốn câu hỏi, và câu nào cũng có lý:
- Đơn rơi vào khoảng trống. Trong lúc chuyển phần mềm, khách bấm đặt trên kênh thì đơn về đâu, ai thấy?
- Tồn phòng sai. Phần mềm mới chưa biết phòng nào đã bán, kênh vẫn mở bán một phòng đã có khách.
- Làm lại từ đầu trên kênh. Có phải tạo lại hạng phòng, mất thứ hạng và đánh giá đã tích lũy không?
- Không có người làm. Người làm Sale cũng là người trực quầy, lấy đâu ra thời gian làm việc với kênh?
📌 Rủi ro thật không nằm ở kênh OTA mà ở khoảnh khắc chuyển đường nối. Thứ cần làm kỹ là chuyển đặt phòng sang trước, đối chiếu, rồi chuyển đường nối một lần, vào lúc ít đơn.
Phần 2: Kênh OTA, hãng quản lý kênh và phần mềm quản lý — đổi lớp nào, giữ lớp nào
Một khách sạn bán phòng qua kênh OTA có ba lớp, mỗi lớp giữ một phần việc riêng:
- Lớp 1, kênh OTA, ví dụ Booking hay Agoda: giữ tài khoản của khách sạn, hạng phòng hiển thị cho khách, ảnh, giá bán, chính sách hủy, đánh giá và hợp đồng hoa hồng. Khách sạn làm việc với lớp này qua trang quản trị của từng kênh.
- Lớp 2, hãng quản lý kênh: nhận đặt phòng từ các kênh, gửi số phòng còn trống ra các kênh. Mỗi kênh được nối với hãng bằng một bảng ánh xạ: hạng phòng nào trên kênh ứng với hạng phòng nào của khách sạn, gói giá nào ứng với gói giá nào.
- Lớp 3, phần mềm quản lý khách sạn: nơi lễ tân nhận phòng, trả phòng, thu tiền; nối với hãng quản lý kênh để nhận đơn về và báo số phòng còn trống ra.
Đổi phần mềm khách sạn là đổi lớp 3. Lớp 1 không bị đụng tới: tài khoản, đánh giá, thứ hạng, ảnh, hợp đồng hoa hồng trên kênh vẫn như cũ. Thứ thay đổi là đường nối giữa lớp 2 và lớp 3: trước ngày chuyển, hãng quản lý kênh nối với phần mềm cũ; sau đó, nó nối với DiCloud.
Phần 3: Điều kiện để giữ nguyên hãng quản lý kênh đang dùng
DiCloud kết nối hai chiều với các hãng quản lý kênh đã có kết nối: đặt phòng từ kênh chảy về DiCloud, số phòng còn trống từ DiCloud chảy ra kênh qua hãng. Nhờ vậy khách sạn giữ được hãng đang dùng cùng hợp đồng và tài khoản trên hãng đó. Điều kiện là hãng ấy phải nằm trong danh sách hãng quản lý kênh đã kết nối. Có hai trường hợp:
- Hãng đang dùng đã có kết nối. Khách sạn giữ nguyên hãng. Việc phải làm là ánh xạ hạng phòng và gói giá trên DiCloud với hãng, chuyển đặt phòng tương lai, đối chiếu, rồi chuyển đường nối vào ngày đã chọn.
- Hãng đang dùng chưa có kết nối. Khách sạn phải đổi sang một hãng quản lý kênh đã kết nối với DiCloud. Tài khoản và đánh giá trên từng kênh vẫn giữ, nhưng các kênh phải được nối vào hãng mới; kế hoạch khi đó dài hơn, cần tính trước.
Bốn câu nên hỏi trước khi ký
- Hãng quản lý kênh khách sạn đang dùng đã kết nối với DiCloud chưa?
- Hợp đồng với hãng hiện tại còn đến khi nào, có cần báo trước cho hãng khi chuyển đường nối không?
- Ai làm phần ánh xạ hạng phòng, gói giá, và ai hỗ trợ?
- Chuyển đường nối vào ngày nào, khung giờ nào, ai trực lúc đó?
Phần 4: Chuyển đặt phòng tương lai và tiền cọc theo từng kênh
Trình tự đúng là: đặt phòng đi trước, đường nối đi sau. Toàn bộ đặt phòng tương lai, kể cả đơn từ kênh OTA và các khoản cọc, phải có mặt trên DiCloud trước khi đường nối được chuyển sang. Làm ngược thì số phòng trống báo ra kênh được tính trên một sổ còn thiếu, dễ dẫn tới bán vượt.
- Xuất danh sách đặt phòng tương lai, tách theo kênh: kênh nào, mã đặt phòng của kênh, tên khách, ngày đến, ngày đi, hạng phòng, số khách, số tiền.
- Giữ mã đặt phòng của kênh trên từng đặt phòng ở DiCloud. Đó là chìa khóa để đối chiếu, và cũng là mã khách đưa ra khi đến quầy.
- Đơn khách đã trả trước cho kênh: ghi đúng là kênh đã thu, để lễ tân không thu thêm và người làm sổ sách biết khoản này về theo kỳ thanh toán của kênh.
- Đơn trả tại khách sạn: chỉ cần đúng giá, đúng gói và đúng chính sách hủy.
- Cọc chuyển khoản trực tiếp: gắn vào đúng đặt phòng, không gộp thành một số tổng. Cách gom và đối chiếu cọc theo nguồn có ở bài nhà nghỉ, homestay đổi phần mềm: giữ khách đang ở, tiền cọc.
Nên chuyển thử trước một lượt, đối chiếu, rồi xuất lại danh sách sát ngày chuyển để cập nhật đơn mới và đơn đã hủy.
Phần 5: Đối chiếu ba nguồn — kênh OTA, hãng quản lý kênh và DiCloud
Một đặt phòng OTA đúng phải có mặt ở cả ba nơi, cùng ngày đến, ngày đi, hạng phòng, số khách và số tiền: trang quản trị của từng kênh (xem cả đơn đã hủy), hãng quản lý kênh và DiCloud. Đối chiếu theo mã đặt phòng của kênh, từng kênh một. Bốn kiểu lệch hay gặp:
- Có trên kênh, không có trên DiCloud: thường là đơn vào sau lúc xuất danh sách. Bổ sung vào DiCloud.
- Đã hủy trên kênh, vẫn còn trên DiCloud: hủy trên DiCloud để phòng được mở bán lại.
- Khác hạng phòng hoặc số đêm: khách đã sửa đặt phòng trên kênh. Lấy theo kênh, ghi chú lại.
- Khác số tiền: kiểm giá, khuyến mãi của kênh và cách thanh toán; hỏi lại kênh nếu chưa rõ.
Chỉ chuyển đường nối khi ba nguồn đã khớp, hoặc mọi chỗ lệch đã có người nhận xử lý và đã ghi lại.
📸 Chụp ảnh tồn phòng trước khi chuyển. Ngay trước giờ chuyển đường nối, chụp màn hình số phòng còn trống theo từng hạng phòng cho các ngày sắp tới, trên hãng quản lý kênh và trên từng kênh. Sau khi chuyển, số trên kênh khác ảnh chụp mà không có đơn mới nào là chỗ cần kiểm ngay.
Phần 6: Chọn thời điểm chuyển kết nối — một lần, không chạy song song
Một hãng quản lý kênh chỉ nên nhận số phòng trống từ một phần mềm quản lý tại một thời điểm. Để phần mềm cũ và DiCloud cùng nối vài ngày "cho chắc" thì số bên này đè số bên kia, và đơn mới có thể chỉ về một nơi. Vì vậy kết nối kênh không chạy song song: đặt phòng chuyển sang trước, đối chiếu xong, rồi đường nối được chuyển một lần. Từ lúc đó đơn OTA mới về DiCloud, nên quầy cũng ghi mọi nghiệp vụ trên DiCloud.
Chọn ngày giữa tuần, ngoài mùa cao điểm; chọn khung giờ có ít đơn, căn cứ lịch sử đơn trên hãng quản lý kênh, lúc người làm Sale không trực quầy, và hẹn trước với hãng cùng đội triển khai DiCloud.
| Thời điểm | Việc | Ai làm | Xong khi |
|---|---|---|---|
| Trước ngày chuyển | Ánh xạ hạng phòng, gói giá; chuyển thử đặt phòng tương lai, đối chiếu | Sale cùng nhân viên hãng quản lý kênh; đội triển khai DiCloud hỗ trợ | Bảng ánh xạ được hai bên xác nhận; lượt thử đã đối chiếu |
| Sáng ngày chuyển | Xuất lại danh sách, chuyển chính thức đặt phòng tương lai sang DiCloud | Đội triển khai DiCloud; Sale kiểm | Mọi đặt phòng tương lai có trên DiCloud, kèm mã của kênh |
| Trước giờ chuyển | Đối chiếu ba nguồn lần cuối; chụp ảnh tồn phòng | Sale | Ba nguồn khớp, hoặc chỗ lệch đã ghi lại và có người nhận |
| Giờ chuyển | Hãng quản lý kênh chuyển đường nối sang DiCloud, ngắt đường nối với phần mềm cũ; quầy chuyển hẳn sang DiCloud | Nhân viên hãng quản lý kênh; đội triển khai DiCloud hỗ trợ | Hãng xác nhận đường nối mới đã chạy |
| Ngay sau khi chuyển | So phòng trống trên kênh với ảnh chụp và DiCloud; kiểm đơn phát sinh sát giờ chuyển | Sale | Phòng trống khớp; không đơn nào nằm ngoài DiCloud |
| Cuối ngày và những ngày đầu | Mỗi tối đối chiếu ba nguồn cho các đơn mới | Sale hoặc người trực đêm | Nhiều ngày liền không còn chỗ lệch |
Bảng cố ý không ghi số giờ: mốc để sang bước sau là cột "xong khi".
Phần 7: Danh sách chuẩn bị cho người làm Sale
Ánh xạ hạng phòng và gói giá với từng kênh do người làm Sale của khách sạn làm cùng nhân viên hãng quản lý kênh, vì chỉ người làm Sale biết gói nào đang bán trên kênh nào. Đội triển khai DiCloud hỗ trợ cài đặt trên DiCloud cho khớp. Hãy dành riêng thời gian cho phần này, đừng làm xen lúc trực quầy.
| Việc chuẩn bị | Lấy ở đâu | Dùng để làm gì |
|---|---|---|
| Bảng hạng phòng: tên hạng, số phòng mỗi hạng, tên hiển thị trên từng kênh | Phần mềm cũ, trang quản trị từng kênh | Cài hạng phòng trên DiCloud, ánh xạ đúng với từng kênh |
| Bảng gói giá: có ăn sáng không, có hoàn hủy không, giá theo mùa | Trang quản trị từng kênh, hãng quản lý kênh | Ánh xạ từng gói; tránh đơn về sai gói |
| Mã kênh, mã hạng phòng, mã gói giá trên hãng quản lý kênh | Hãng quản lý kênh | Lập bảng ánh xạ để nhân viên hãng xác nhận |
| Chính sách hủy và thanh toán của từng gói | Trang quản trị từng kênh | Ghi đúng trên đặt phòng; lễ tân biết thu hay không thu |
| Đặt phòng tương lai theo kênh, kèm mã đặt phòng của kênh | Phần mềm cũ, trang quản trị từng kênh | Chuyển sang DiCloud, đối chiếu ba nguồn |
| Tài khoản đăng nhập từng kênh và hãng quản lý kênh; đầu mối của hãng | Chủ khách sạn, hãng quản lý kênh | Đối chiếu, đóng mở phòng khi cần, gọi ngay khi có lệch |
| Ảnh chụp tồn phòng các ngày sắp tới | Hãng quản lý kênh và từng kênh | Mốc so sánh sau khi chuyển |
Bảng ánh xạ nên được hãng xác nhận bằng email hay tin nhắn trước ngày chuyển; hạng phòng, gói giá nào chưa có cặp phải xử lý trước.
Phần 8: Dấu hiệu lệch tồn phòng trong ngày đầu và cách xử
Chuẩn bị kỹ làm giảm rủi ro, không xóa hết rủi ro. Ngày đầu, những dấu hiệu sau cần kiểm ngay:
- Số phòng trống của một hạng trên kênh khác với DiCloud, trong khi không có đơn mới.
- Một hạng phòng bỗng đóng bán trên kênh dù DiCloud vẫn còn phòng, hoặc mở bán nhiều hơn số phòng thật.
- Đơn về DiCloud nhưng nằm sai hạng phòng hoặc sai gói giá.
- Khách đưa mã đặt phòng của kênh mà quầy không tìm thấy trên DiCloud.
Cách xử, theo thứ tự:
- So với ảnh chụp tồn phòng để biết lệch từ lúc nào, ở hạng phòng nào.
- Có nguy cơ bán vượt thì đóng tạm hạng phòng đó trên kênh hoặc trên hãng quản lý kênh, rồi mới tìm nguyên nhân.
- Báo hãng quản lý kênh và đội triển khai DiCloud, kèm mã đặt phòng và ảnh chụp; kiểm bảng ánh xạ trước tiên.
- Đơn có trên kênh mà thiếu trên DiCloud: nhập ngay, ghi kèm mã của kênh.
- Ghi lại từng lần lệch để buổi đối chiếu tối theo dõi tiếp.
Nếu đã lỡ nhận hai khách cho một phòng, cách xử lý tại quầy có ở bài khách sạn mini tránh nhận trùng phòng mùa cao điểm.
🧭 Đừng đặt mục tiêu "không lệch đơn nào". Hãy đặt mục tiêu là lệch thì biết ngay trong ngày, có ảnh chụp để so và có người để gọi. Khách sạn nhỏ làm được việc đó.
Phần 9: DiCloud hỗ trợ gì khi đổi phần mềm mà vẫn bán qua kênh OTA
DiCloud là phần mềm quản lý khách sạn cloud AI cho khách sạn mini, nhà nghỉ, homestay và khách sạn 1–3 sao. Với phần kênh OTA khi đổi phần mềm:
- Kết nối hai chiều với các hãng quản lý kênh có trong danh sách: đặt phòng về DiCloud, số phòng còn trống ra kênh.
- Đội triển khai DiCloud hỗ trợ cài hạng phòng, gói giá cho khớp bảng ánh xạ người làm Sale chốt với hãng quản lý kênh, và hỗ trợ trong khung giờ chuyển đường nối đã hẹn trước.
- Chủ đầu tư và GM theo dõi số qua DiOwner, ứng dụng chỉ đọc trên điện thoại, số khớp với phần mềm vận hành.
- Lễ tân học thao tác theo ca, như ở bài đổi phần mềm khách sạn: đào tạo lễ tân để vận hành ngay.
🏨 Khách sạn từ 50 phòng hoặc chuỗi từ 2 cơ sở? DiHotel có gói Đổi hệ 0 đồng cho khách sạn đang chạy phần mềm cài tại chỗ đời cũ, áp dụng cho hợp đồng ký đến hết 30/06/2027. Các bước để đổi phần mềm quản lý khách sạn ở quy mô đó có trên DiHotel Blog, và bài cùng đợt đổi phần mềm cho chuỗi khách sạn: có phải nối lại kênh OTA? đi vào ánh xạ gói giá và lộ trình theo từng cơ sở.
Sắp đổi phần mềm, đang bán qua nhiều kênh OTA?
Cho đội ngũ DiCloud biết khách sạn đang dùng hãng quản lý kênh nào và bán qua những kênh nào. Chúng tôi kiểm hãng đó đã kết nối với DiCloud chưa và gửi mẫu danh sách chuẩn bị cho người làm Sale.
Kiểm hãng quản lý kênh miễn phíCâu hỏi thường gặp
Đổi phần mềm khách sạn có phải làm lại tài khoản trên các kênh OTA không?
Không. Tài khoản, hạng phòng, giá và đánh giá trên các kênh như Booking hay Agoda nằm ở phía kênh. Đổi phần mềm quản lý chỉ đổi đường nối giữa hãng quản lý kênh và phần mềm, với điều kiện hãng quản lý kênh đang dùng đã có kết nối với DiCloud.
Hãng quản lý kênh khách sạn đang dùng chưa kết nối với DiCloud thì sao?
Khi đó khách sạn phải đổi sang một hãng quản lý kênh đã kết nối với DiCloud, và các kênh phải được nối vào hãng mới. Nên kiểm danh sách hãng đã kết nối trước khi ký.
Có nên để phần mềm cũ và DiCloud cùng nối với hãng quản lý kênh vài ngày cho chắc không?
Không. Hai phần mềm cùng báo số phòng trống ra kênh thì số bên này đè số bên kia, và đơn mới có thể chỉ về một nơi. Đặt phòng được chuyển sang DiCloud trước, đối chiếu xong mới chuyển đường nối, và chuyển một lần.
Đặt phòng tương lai đã nhận qua kênh OTA được chuyển thế nào?
Toàn bộ được chuyển sang DiCloud trước giờ chuyển đường nối, giữ mã đặt phòng của kênh và ghi rõ đã trả trước cho kênh, trả tại khách sạn hay đã chuyển cọc, rồi đối chiếu với kênh và hãng quản lý kênh.
Ai làm việc ánh xạ hạng phòng và gói giá với từng kênh?
Người làm Sale của khách sạn làm cùng nhân viên hãng quản lý kênh, vì người làm Sale biết gói nào đang bán trên kênh nào. Đội triển khai DiCloud hỗ trợ cài hạng phòng và gói giá trên DiCloud cho khớp bảng ánh xạ.
Ngày đầu thấy số phòng trống trên kênh khác với DiCloud thì làm gì?
So với ảnh chụp tồn phòng trước giờ chuyển, đóng tạm hạng phòng đó trên kênh nếu có nguy cơ bán vượt, báo nhân viên hãng quản lý kênh và đội triển khai DiCloud, rồi kiểm bảng ánh xạ của hạng phòng bị lệch.
Kết luận
Đổi phần mềm khách sạn có thể tránh mất đặt phòng OTA nếu khách sạn hiểu đúng mình đang đổi lớp nào: kênh OTA giữ nguyên, hãng quản lý kênh giữ nguyên nếu đã kết nối với DiCloud, chỉ đường nối giữa hãng và phần mềm quản lý thay đổi. Phần còn lại là kỷ luật: đặt phòng tương lai và cọc sang trước, đối chiếu ba nguồn, chụp ảnh tồn phòng, chuyển đường nối một lần vào lúc ít đơn.
DiCloud thuộc hệ sinh thái DiHotel Solutions Corps, công ty hơn 20 năm phát triển phần mềm khách sạn, phục vụ hơn 300 cơ sở lưu trú tại Việt Nam và Nhật Bản. Là một phần mềm quản lý khách sạn online AI, DiCloud mở được trên máy quầy lẫn điện thoại, để chủ khách sạn thấy ngay đơn mới về đâu.
Với khách sạn 4–5 sao, resort và chuỗi bán qua nhiều kênh, nhiều gói giá trên nhiều cơ sở, phần mềm quản lý khách sạn AI DiHotel là nền tảng gốc, triển khai được trên đám mây, tại chỗ hoặc kết hợp.