Một kỳ nghỉ dễ hiểu bắt đầu từ phần tóm tắt rõ ràng
Khách đã thích căn phòng trong ảnh nhưng còn ngập ngừng trước nút tiếp tục: đến ngày 10, đi ngày 12 là hai hay ba đêm, mức giá đang thấy dành cho một phòng hay cả chuyến? Với website khách sạn tính số đêm, câu trả lời nên xuất hiện ngay cạnh lựa chọn. Trong mô hình lưu trú theo đêm thông thường, ngày trả phòng là điểm kết thúc; kỳ ở từ ngày 10 tới ngày 12 gồm hai đêm, không phải ba.
Hãy đọc phần tóm tắt như người chuẩn bị đi nghỉ: tên loại phòng, ngày đến, ngày đi, số đêm, số phòng và điều kiện của lựa chọn. Ảnh phòng giúp khách hình dung nơi ở, nhưng họ vẫn cần biết ảnh thuộc hạng phòng nào và điều gì thực sự được bao gồm. Nếu có nhiều hạng, đừng để ảnh của hạng cao hơn khiến khách tưởng đó là phòng mình đang chọn.
Ví dụ giả lập: nhận phòng ngày 10/11, trả ngày 12/11, một phòng trong hai đêm. Nếu giả định mỗi đêm cùng mức 900.000 đồng và chưa có thành phần khác, tiền phòng mẫu là 1.800.000 đồng. Đây chỉ là phép minh họa, không phải giá phòng thật; thuế, phụ thu, bữa sáng, điều kiện hủy và thay đổi giá theo từng đêm phải đọc theo chính sách cơ sở, không tự suy ra từ con số này.
Khi khách đổi ngày đi, phần số đêm và thông tin giá cần phản ánh cùng lựa chọn mới. Nếu một đêm không phù hợp hoặc chưa kiểm tra được khả dụng, màn hình nên giúp họ hiểu cần đổi gì hoặc liên hệ ai, thay vì cho cảm giác đã giữ được phòng. Một giao diện đẹp chỉ là phần nhìn thấy; xác nhận phòng còn phụ thuộc dữ liệu và quy trình phía sau.
Các ảnh và phòng trong bài là minh họa giả lập, không phải khách sạn, báo giá hay hệ thống đặt phòng đã triển khai. Khi làm website cho cơ sở của bạn, hãy mang một hành trình cụ thể cùng quy tắc giá và nhận trả phòng tới buổi trao đổi. Những chi tiết kỹ thuật bên dưới giải thích vì sao cùng một lựa chọn cần cho ra cách hiểu thống nhất trên cả máy tính lẫn điện thoại.
Ngày trả phòng là ranh giới kết thúc
Trong mô hình lưu trú theo đêm thông thường, đến ngày 10 và đi ngày 12 nghĩa là sử dụng hai đêm: đêm ngày 10 và đêm ngày 11. Ngày 12 là ngày trả phòng, không phải một đêm thứ ba. Biểu diễn khoảng này bằng cách bao gồm ngày đến nhưng loại trừ ngày đi giúp cả bộ phận bán và phần mềm nhìn cùng một lịch.
Không nên diễn đạt kết quả chỉ bằng “ba ngày” nếu giá được tính theo đêm. Một chuyến đi ba ngày có thể gồm hai đêm, còn dịch vụ sử dụng phòng ban ngày có thể không thuộc mô hình đó. Website cần nêu đơn vị đang bán thay vì để khách tự suy đoán từ con số lớn cạnh tổng tiền.
Tài liệu Hotel Prices của Google mô tả hành trình bằng ngày check-in kết hợp với số đêm nguyên dương. Đó là một ví dụ rõ về việc tách ngày đến khỏi số đêm; không phải cam kết rằng mọi hệ thống phòng đều sử dụng cùng trường dữ liệu hoặc tự hỗ trợ day-use.
Đếm theo ngày lịch, không chia số giờ một cách máy móc
Giả sử giờ nhận phòng là 14 giờ và trả phòng là 12 giờ hai ngày sau. Khoảng thực tế từ hai mốc giờ này là 46 giờ nhưng sản phẩm vẫn là hai đêm theo lịch lưu trú đã công bố. Lấy 46 chia 24 rồi làm tròn xuống thành một đêm là sai mô hình. Làm tròn lên có thể tình cờ đúng trong ví dụ này nhưng không biến phép tính đó thành quy tắc bền vững.
Đối với cơ sở ở nơi có thay đổi giờ mùa hè, một ngày địa phương còn có thể không dài đúng 24 giờ. Điều này đặc biệt đáng lưu ý khi một website bán nhiều điểm đến quốc tế hoặc đồng bộ với hệ thống đặt phòng ở nước ngoài. Không cần có giờ mùa hè tại Việt Nam thì lỗi mới liên quan đến đội phát triển Việt Nam.
MDN mô tả Temporal.PlainDate là ngày lịch không có giờ và múi giờ. Đây là cách phân biệt hữu ích ở tầng mô hình dữ liệu. Nếu dùng công nghệ khác, đội phát triển có thể chọn kiểu ngày tương đương; không nên đổi toàn bộ ứng dụng sang một API chỉ vì bài viết nhắc tới nó, và cần kiểm tra hỗ trợ môi trường trước khi triển khai.
Chọn múi giờ của khách sạn làm ngữ cảnh
Khách đang ở nước khác vẫn đặt đêm tại cơ sở lưu trú. Máy chủ ở một múi giờ khác hoặc trình duyệt đang hiển thị giờ địa phương của khách không nên làm ngày nhận phòng tự nhảy. Chuỗi ngày đã chọn cần giữ nguyên ý nghĩa từ biểu mẫu đến kết quả tìm kiếm, giỏ đặt phòng và thư xác nhận.
Vấn đề dễ lộ khi dữ liệu ngày bị tự chuyển thành mốc nửa đêm UTC rồi lại hiển thị theo múi giờ trình duyệt. Một thao tác kỹ thuật tưởng như chuẩn hóa có thể đổi ngày lịch. Đội tích hợp cần xác định trường nào là ngày không giờ và trường nào thực sự là thời điểm. Ngày lưu trú, giờ đến dự kiến và thời điểm thanh toán không nên dùng chung một kiểu chỉ vì đều có chữ “ngày”.
Hướng dẫn biến URL Hotel Prices nhấn mạnh thông tin hành trình trên đường dẫn phải khớp ngày lưu trú, số người và giá hiển thị ở trang đặt. Khi dùng luồng chuyển từ quảng cáo hoặc công cụ tìm phòng, cần kiểm thử dữ liệu thực sự được chuyển sang biểu mẫu, thay vì chỉ nhìn URL có đủ tham số.
Hai phòng, ba đêm không có nghĩa là sáu đêm cho một phòng
Hãy tách số đêm lưu trú khỏi số đêm phòng. Hai phòng cùng sử dụng ba đêm tạo sáu đêm phòng về mặt đếm đơn vị phòng-đêm, nhưng khách vẫn đi trong một hành trình ba đêm. Nếu giao diện đổi nhãn thành “6 đêm”, khách có thể tưởng ngày trả đã thay đổi hoặc tổng tiền bị nhân hai lần.
Số người cũng không phải số phòng. Một phòng hai khách trong ba đêm không tự thành sáu đêm phòng. Chính sách giá có thể phụ thuộc người ở, độ tuổi trẻ em, giường phụ và gói dịch vụ; những thành phần đó cần được tính theo quy tắc riêng. Bài viết này không đề xuất một công thức giá chung cho mọi cơ sở.
Một bản tóm tắt dễ hiểu nên giữ các chiều dữ liệu cạnh nhau: ngày đến, ngày đi, ba đêm, hai phòng và danh sách người ở theo yêu cầu hệ thống. Nếu có nhiều phòng với hành trình khác nhau, đừng dùng một tổng số đêm duy nhất thay thế các dòng chi tiết; mỗi dòng phải đủ để kiểm tra được khả dụng.
Khả dụng phải bao phủ mọi đêm trong hành trình
Một loại phòng còn chỗ vào ngày đến chưa đủ chứng minh bán được cả kỳ nghỉ. Với hành trình ba đêm, hệ thống cần kiểm tra cả ba đêm cùng các ràng buộc liên quan. Nếu đêm giữa hết phòng, trang kết quả không nên xác nhận một lượt ở liên tục chỉ vì đêm đầu và đêm cuối đều còn.
Tương tự, ba phòng trống ở ba đêm khác nhau không nhất thiết là cùng một phòng vật lý có thể ở liên tục. Một số hệ thống bán theo loại phòng và phân bổ phòng cụ thể sau; một số yêu cầu giữ phòng vật lý ngay. Đội triển khai cần làm rõ mô hình vận hành đó và cách xử lý đổi phòng, thay vì mặc định có thể cộng tồn theo từng ngày.
Các giới hạn số đêm tối thiểu, tối đa hoặc ngày được phép đến có thể khiến hành trình không hợp lệ dù vẫn còn phòng. Thông báo cần tách “không còn phòng” với “chưa đáp ứng điều kiện kỳ nghỉ”. Khách sẽ biết cần đổi ngày, tăng số đêm hay liên hệ cơ sở, thay vì thử ngẫu nhiên nhiều lần.
Nhận phòng sớm, trả muộn và sử dụng ban ngày
Yêu cầu nhận sớm không nên âm thầm đổi ngày đến để tăng số đêm. Khách có thể chỉ ghi giờ đến dự kiến; việc cho vào phòng sớm còn tùy khả dụng và chính sách đã công bố. Nếu cơ sở bán riêng quyền sử dụng từ đêm trước, phải thể hiện thành lựa chọn rõ ràng, kèm điều kiện và xác nhận.
Trả phòng muộn cũng cần được tách khỏi thay đổi ngày đi. Một khoản phụ thu theo chính sách không đồng nghĩa khách có thêm trọn đêm. Ngược lại, nếu khách gia hạn đến ngày sau, dữ liệu hành trình và khả dụng phải được kiểm tra lại. Không nên chỉ thêm tiền vào đơn cũ trong khi lịch phòng vẫn kết thúc vào ngày ban đầu.
Đặt ngày đến trùng ngày đi nên được xử lý theo loại sản phẩm. Với sản phẩm bán theo đêm, thường cần ngày đi sau ngày đến. Nếu doanh nghiệp bán day-use, hãy thiết kế luồng và nhãn riêng, không biến số đêm bằng không thành một đặt phòng miễn phí hoặc tự cộng một đêm mà khách không chọn.
Nghiệm thu lịch bằng những ranh giới dễ bỏ sót
Thử một đêm qua cuối tháng, qua cuối năm và qua ngày nhuận. Kiểm tra cùng lựa chọn trên trình duyệt ở hai múi giờ, đồng thời đổi múi giờ của máy chủ trong môi trường thử nghiệm phù hợp. Kết quả ngày đến, ngày đi và số đêm phải thống nhất; không thực hiện thử nghiệm đổi cấu hình trên máy chủ production đang phục vụ khách.
Tiếp theo, thử đi trước ngày đến, hai ngày trùng nhau, vượt giới hạn số đêm và một hành trình hết phòng ở đêm giữa. Khi sửa ngày trên trang kết quả, các trường tóm tắt và yêu cầu gửi tới hệ thống phòng cần cùng được cập nhật. Nút quay lại trình duyệt không được khôi phục tổng tiền mới với lịch cũ.
Một kiểm thử tốt đọc toàn bộ hành trình như khách hàng: tìm kiếm, chọn phòng, xem tóm tắt, nhận xác nhận. Nếu cần thiết kế hoặc tích hợp luồng này, tham khảo dịch vụ thiết kế website Onter. Giá: Liên hệ. Nhận tư vấn & báo giá với mẫu lịch giả định và quy tắc cơ sở đang sử dụng.
