Một phòng được giới thiệu dành cho bốn khách chưa chắc nhận được mọi nhóm gồm bốn người. Hai người lớn và hai trẻ nhỏ có thể phù hợp một cấu hình, còn bốn người lớn cần phương án khác. Giới hạn khách trong phòng cần được website kiểm tra theo tổ hợp người lớn, trẻ em và điều kiện gói giá, thay vì chỉ cộng tổng rồi so với một con số sức chứa.
Bài viết đề xuất cách làm rõ quy tắc do cơ sở lưu trú phê duyệt trước khi đưa lên website. Các giới hạn và nhóm khách dưới đây đều là ví dụ giả định, không phải chính sách chung của khách sạn, quy định an toàn hay điều kiện của một nền tảng đặt phòng cụ thể.
Một con số bốn người che khuất những điều kiện nào?
Hãy xét một phòng gia đình giả định được cơ sở cho bán với tối đa hai người lớn và hai trẻ trong phạm vi tuổi đã công bố. Khách chọn ba người lớn và một trẻ. Tổng vẫn bằng bốn, nhưng tổ hợp này không phù hợp cấu hình đang được phép bán. Nếu form chỉ có ô tổng khách, hệ thống không đủ dữ liệu để kiểm tra điều kiện đó.
Cũng cần phân biệt phòng có khả năng chứa bao nhiêu người với một gói cụ thể đang bán cho bao nhiêu người. Gói hai khách có thể sử dụng một phòng lớn hơn mà không tự cho phép thêm hai người miễn phí. Sức chứa, số khách trong giá và điều kiện nhận thêm khách cần được trình bày riêng khi chúng khác nhau.
Tài liệu Hotel Prices của Google phân biệt Capacity và Occupancy, đồng thời có OccupancyDetails để mô tả người lớn và trẻ em. Đây là ví dụ rõ về những đại lượng khác nhau trong hợp đồng dữ liệu. Nó không đặt chính sách tiếp nhận khách thay khách sạn và không chứng minh website riêng đã hỗ trợ đúng mọi trường.
Nhân viên phụ trách cần xác nhận giới hạn tổng, giới hạn theo nhóm và điều kiện gói. Nếu có giường phụ hoặc nôi, cần chốt chúng là lựa chọn yêu cầu, tài nguyên có giới hạn hay phần luôn có sẵn trong một cấu hình. Chỉ một checkbox “thêm giường” không chứng minh cơ sở đã có thiết bị vào đúng ngày khách ở.
Mô tả bằng tên phòng cũng không đủ. “Family”, “Deluxe” hay “Suite” không phải công thức sức chứa chung cho mọi cơ sở. Dữ liệu cần gắn với đúng loại phòng, gói và kỳ áp dụng mà khách đang xem.
Viết quy tắc thành bảng tổ hợp được phép
Trước khi làm bộ chọn khách, hãy để người có trách nhiệm của khách sạn duyệt vài tổ hợp cụ thể. Cách này thường dễ phát hiện thiếu sót hơn một yêu cầu chung “cho nhập số người lớn trẻ em”. Bảng không cần bao phủ mọi con số có thể tưởng tượng; cần đủ để mô tả tập cấu hình đang bán và cách xử lý phần chưa rõ.
| Nhóm giả định | Tổng khách | Kết quả theo cấu hình minh họa |
|---|---|---|
| Hai người lớn, hai trẻ | Bốn | Cần kiểm tra nhóm tuổi và điều kiện gói |
| Ba người lớn, một trẻ | Bốn | Không khớp giới hạn hai người lớn |
| Hai người lớn, một trẻ, một em bé | Bốn | Chưa được suy ra phù hợp nếu quy tắc em bé chưa rõ |
Rooms API của Booking.com cũng tách giới hạn tổng, người lớn, trẻ em và cách tính em bé trong mô hình occupancy hiện hành. Các trường theo nhà cung cấp có thể khác nhau và thay đổi theo phiên bản; đây là căn cứ để yêu cầu mapping rõ, không phải ranh giới tuổi hay cách tính bắt buộc cho mọi khách sạn.
Dòng thứ ba là điểm dễ bị bỏ sót. Không tự coi em bé không chiếm chỗ, không tính vào sức chứa hoặc luôn được thêm ngoài giới hạn. Nếu cơ sở có cách tính riêng, cần lưu rõ quy tắc đó cùng nguồn xác nhận. Nếu chưa có thông tin, website nên nhận yêu cầu tư vấn thay vì tự chấp nhận một tổ hợp không biết.
Phân nhóm tuổi cũng cần được xác nhận theo dịch vụ. Bài chốt mốc tuổi khi đặt tour giải thích vấn đề ngày tham chiếu. Với phòng ở, không bê nguyên ranh giới tuổi từ tour hoặc từ một khách sạn khác. Bài này tập trung vào tổ hợp được phép; phép tính tuổi chỉ cung cấp đầu vào cho quy tắc đã duyệt.
Với mỗi tổ hợp, nên ghi thêm lý do loại hoặc câu hỏi còn thiếu. “Vui lòng chọn lại” không cho khách biết phòng không nhận ba người lớn hay chỉ đang thiếu tuổi của trẻ. Một thông báo cụ thể giúp khách tìm phương án khác mà không cần thử ngẫu nhiên nhiều lần.
Giá cho nhóm khách phải đi cùng kết quả kiểm tra
Giả sử kết quả tìm kiếm hiện một phòng theo giá hai người lớn, sau đó khách thêm hai trẻ. Nếu tổ hợp mới được phép nhưng giá hoặc điều kiện khác, giao diện cần tính lại hoặc yêu cầu xác nhận theo cơ chế đang có. Không giữ tổng tiền cũ trong khi âm thầm đổi số khách, cũng không tự hứa miễn phí chỉ vì ô trẻ em không có giá riêng.
Khách cần biết đang xem giá cho nhóm nào, phần nào gồm trong gói và yêu cầu nào còn chờ cơ sở. Thông tin đó nên xuất hiện ở bước chọn phương án và bản tóm tắt trước xác nhận. Một ghi chú chung ở cuối trang dễ không đủ để giải thích một thay đổi vừa xảy ra trong form.
Khi dùng dữ liệu từ hệ thống quản lý phòng hoặc đối tác, hãy kiểm tra nhóm khách được gửi đi và nhóm được phản hồi. Đọc được giá không có nghĩa giá đó áp dụng cho tổ hợp đang chọn. Nếu đầu ra chỉ cho biết giá hai người, đội tích hợp không nên diễn giải thành giá cho bốn người vì phòng có sức chứa bốn.
Trong trường hợp chưa lấy được kết quả phù hợp, hệ thống cần giữ nhu cầu đã nhập và nói rõ phần cần lễ tân kiểm tra. Luồng hỗ trợ hỏi phòng và chuyển lễ tân có thể dùng dữ liệu đã duyệt để giải thích, nhưng không được tự xác nhận khả năng nhận thêm khách từ một mô tả tiện ích.
Nếu khách đổi một thành viên từ trẻ em sang người lớn, đó là thay đổi đầu vào có thể tác động tới cả tính phù hợp và giá. Không chỉ đổi nhãn hiển thị trong bản tóm tắt. Quy tắc phải được chạy lại trên cấu hình hiện hành và thông báo thay đổi trước khi khách đồng ý bước tiếp theo.
Đừng để bộ chọn khách hứa thay người vận hành
Một thiết kế tốt không nhất thiết luôn có nút đặt tự động cho mọi tổ hợp. Với cơ sở nhỏ, nhận yêu cầu rồi nhân viên kiểm tra một số trường hợp đặc biệt có thể phù hợp hơn việc xây một công thức chung không phản ánh thực tế. Phần quan trọng là khách hiểu họ đang gửi yêu cầu hay đã có xác nhận.
Đội triển khai nên dùng bộ dữ liệu giả để thử hai nhóm cùng tổng người nhưng khác thành phần. Thử thêm thiếu tuổi, vượt giới hạn người lớn, thêm em bé khi chưa có quy tắc và yêu cầu nôi hoặc giường phụ. Kết quả mong đợi cần được người phụ trách duyệt trước; không lấy kết quả phần mềm hiện tại làm đáp án mặc định.
Kiểm tra cả thao tác quay lại sau khi đã xem giá. Nếu khách đổi số người rồi mở lại bước trước, hệ thống phải giữ tổ hợp mới hoặc yêu cầu xác nhận rõ ràng. Không để giỏ hoặc bản tóm tắt giữ một nhóm khác với nhóm đã dùng để kiểm tra phòng. Với API trả chậm, đừng hiển thị giá cũ như một kết quả cho đầu vào mới.
Phòng còn trống theo ngày cũng là một điều kiện khác. Một tổ hợp hợp lệ chưa chứng minh còn phòng vào toàn bộ kỳ ở. Khi khách cần nhiều phòng cho đoàn, xem cách tách phân bổ phòng và kỳ lưu trú; không dùng tổng người của cả đoàn để chứng minh từng phòng đủ điều kiện nhận khách.
Sau nghiệm thu, giữ bảng quy tắc được duyệt và chỉ định người cập nhật khi cơ sở thay điều kiện bán. Một thay đổi ở mô tả marketing không nên tự sửa giới hạn kỹ thuật; ngược lại, đổi cấu hình cũng cần rà lại thông tin khách đọc. Đối chiếu định kỳ hai lớp giúp tránh việc nhân viên và website đưa ra hai câu trả lời khác nhau.
Khi trao đổi website đặt phòng với Onter, hãy mang theo một loại phòng, các tổ hợp khách được phép và hai trường hợp nhân viên thường phải xác nhận thêm. Giá: Liên hệ. Nhận tư vấn & báo giá theo quy tắc của cơ sở, không cần gửi hồ sơ gia đình thật ở bước khảo sát ban đầu.
