Một người liên hệ đặt phòng cho cả đoàn, nhưng thành viên đến vào hai ngày khác nhau. Nếu website chỉ lưu tên trưởng đoàn, tổng số khách và một khoảng ngày, nhân viên vẫn phải đoán đoàn cần những phòng nào trong từng đêm. Số người đúng chưa chứng minh số phòng và thời gian giữ phòng đúng.
Đặt phòng cho đoàn cần tách người liên hệ khỏi các phân bổ phòng và kỳ lưu trú. Bài viết dùng một ví dụ giả định để thiết kế bảng phân bổ, đối chiếu persons và resources trong WooCommerce Bookings rồi nêu phần cần bổ sung bằng quy trình riêng. Không coi số khách là số phòng và không hứa nền tảng tự gom mọi nhu cầu đoàn thành một booking nguyên khối.
Đặt phòng cho đoàn bắt đầu từ từng phân bổ phòng
Người liên hệ là nơi trao đổi, nhận thông báo và xác nhận thay đổi theo thỏa thuận. Phòng là tài nguyên cần giữ. Kỳ lưu trú là khoảng thời gian tài nguyên được dùng. Một đoàn có một đầu mối nhưng nhiều cặp phòng và kỳ lưu trú; quan hệ này cần được thể hiện trong dữ liệu thay vì nén thành một ghi chú dài.
Giả sử đoàn D3 gồm hai nhóm. Nhóm đầu ở hai đêm, nhóm sau tới muộn một đêm. Trưởng đoàn muốn nhận một bản tổng hợp. Nếu website dùng một ngày đến chung, nhóm tới muộn có thể làm hệ thống giữ thừa phòng đêm đầu. Nếu lấy ngày tới muộn cho cả đoàn, nhóm tới trước lại chưa có phòng theo dữ liệu.
Một cách biểu diễn đề xuất là hồ sơ đoàn có mã riêng, liên kết tới các dòng phân bổ. Mỗi dòng giữ loại hoặc phòng cụ thể, ngày nhận, ngày trả, số người và trạng thái xác nhận. Thông tin liên hệ chung ở hồ sơ đoàn, còn các yêu cầu riêng chỉ nằm ở dòng cần dùng. Điều này giúp giảm việc chép cùng thông tin cá nhân nhiều lần.
| Dòng giả định | Phân bổ | Khoảng lưu trú | Câu hỏi cần chốt |
|---|---|---|---|
| A | Một phòng hai người | Ngày 1 tới ngày 3 | Còn cả hai đêm? |
| B | Một phòng hai người | Ngày 2 tới ngày 3 | Chỉ giữ đêm sau? |
| C | Một phòng ba người | Ngày 1 tới ngày 3 | Đủ sức chứa phù hợp? |
Bảng trên là ví dụ về nhu cầu, không phải khả năng cấu hình được bảo đảm sẵn trong một plugin. Nó giúp đội triển khai nhận diện điều phải lưu và điều cần kiểm tra. Doanh nghiệp có thể dùng một giao diện tổng hợp khác, miễn không làm mất từng dòng phân bổ và trạng thái của nó.
Persons đếm người, resources quản lý năng lực
Hướng dẫn quản lý WooCommerce Bookings phân biệt cấu hình persons và resources. Persons có thể tham gia cách tính theo người, còn resource biểu diễn tài nguyên như phòng. Việc chúng cùng có mặt trong một sản phẩm không làm hai khái niệm trở thành một.
Với ví dụ D3, ba người ở cùng một phòng không mặc nhiên bằng ba phòng. Ngược lại, ba khách muốn ở riêng có thể cần ba phân bổ. Giao diện phải hỏi đúng nhu cầu phòng hoặc cung cấp bước nhân viên chốt. Chỉ hỏi tổng số người rồi tự chia theo một công thức ngầm dễ tạo phương án khách không chấp nhận.
Tài liệu resources nêu những giới hạn và lựa chọn phân bổ của Bookings. Đặc biệt, không nên mặc định một booking sẽ nhận nhiều resource độc lập như một giỏ phòng cho đoàn. Cần kiểm tra đúng cấu hình và xem có phải dùng nhiều booking liên kết hoặc một lớp điều phối riêng hay không.
Lớp điều phối đề xuất có thể thu thập nhu cầu đoàn, kiểm tra từng dòng rồi trình bày kết quả tổng hợp. Nó không nên che giấu việc một dòng đã xác nhận còn dòng khác chưa có chỗ. Nếu chưa đủ năng lực giữ toàn bộ đoàn theo cùng điều kiện, thông báo cần nói rõ phần nào đang có và phần nào cần phương án thay thế.
Không cần thu mọi tên khách từ bước hỏi chỗ
Giai đoạn đầu thường chỉ cần thông tin đủ để kiểm tra năng lực và liên hệ người đại diện. Danh sách người ở, giấy tờ hoặc yêu cầu nhạy cảm nên được thu theo nhu cầu và quy trình phù hợp sau đó, với quyền xem rõ ràng. Đưa toàn bộ thông tin lên một ghi chú chung khiến nhiều nhân viên nhìn thấy dữ liệu họ không cần dùng.
Thành viên đoàn thay đổi cũng không nên buộc xóa phân bổ phòng nếu nhu cầu sức chứa vẫn giữ nguyên. Tách thông tin khách với phân bổ giúp cập nhật đúng phần. Đồng thời, doanh nghiệp cần biết ai được phép yêu cầu đổi phòng và thông tin nào phải được trưởng đoàn hoặc người có quyền xác nhận.
Người trả tiền và người nhận thông báo cũng có thể khác nhau. Nếu một đơn tổng hợp thanh toán cho nhiều phân bổ, cần giữ liên kết tới từng phần để đối chiếu khi sửa hoặc hủy. Không mặc định một người liên hệ được phép xem toàn bộ dữ liệu riêng của mọi thành viên chỉ vì họ đứng tên gửi yêu cầu đầu tiên.
Bản tổng hợp cho trưởng đoàn có thể chỉ nêu phòng, số người, khoảng ngày và trạng thái; thông tin phục vụ chi tiết được chia sẻ theo quyền riêng. Cách trình bày này vẫn giúp chốt phương án mà không phải nhân bản mọi hồ sơ cá nhân vào email chung.
Chấp nhận một phần hay chỉ xác nhận khi đủ đoàn?
Đây là quyết định kinh doanh cần có trước khi làm nút đặt. Nếu khách chỉ chấp nhận đi khi toàn đoàn có đủ phòng, website không nên tự nhận tiền cho vài dòng rồi báo thiếu phần còn lại. Nếu cho phép nhận một phần, giao diện phải giải thích số phòng đã được xác nhận và phần còn chờ, tránh một tiêu đề thành công chung cho tất cả.
Trong bước giữ chỗ, việc kiểm tra từng dòng tuần tự có thể tạo ra khoảng giữa: dòng đầu được giữ, dòng sau không còn. Thiết kế cần quy trình giải quyết phần giữ đó theo chính sách. Không hứa giao dịch nguyên khối chỉ vì nhiều dòng được gửi trong cùng một lần bấm nếu chưa có cơ chế đã kiểm chứng.
Với quy mô nhỏ, cách phù hợp có thể là nhận yêu cầu đoàn rồi nhân viên xác nhận phương án trước khi thanh toán. Với hệ thống tự động hơn, cần điều phối thời hạn giữ, phân bổ và phản hồi nhất quán. Hai cách có đánh đổi giữa tốc độ phản hồi và trách nhiệm xử lý ngoại lệ; không có lý do buộc mọi cơ sở dùng cùng một cách.
Hướng dẫn tạo booking thủ công mô tả việc gán persons, resources và liên kết đơn. Đây là một phần công cụ có thể dùng trong quy trình có nhân viên, không tự tạo khái niệm hồ sơ đoàn. Khi triển khai, cần giữ mã liên kết để nhân viên thấy các booking thuộc cùng phương án.
Đổi một phòng không nên đặt lại cả đoàn
Giả sử nhóm B dời ngày đến thêm một ngày. Chỉ dòng B cần được xem lại, nhưng thay đổi có thể ảnh hưởng tổng tiền hoặc điều kiện chung. Hệ thống nên cho nhân viên thấy các phần liên quan trước khi xác nhận, giữ các dòng đã ổn định và ghi lịch sử thay đổi. Không xóa hết booking rồi nhập lại từ ghi chú của trưởng đoàn.
Khi cần chuyển từ loại phòng sang phòng cụ thể, lưu quan hệ phân bổ thay vì làm mất nhu cầu ban đầu. Nhu cầu và lựa chọn thực tế giúp giải thích phương án khi có thay đổi. Một báo cáo chỉ có danh sách tên khách mà thiếu các kỳ lưu trú sẽ không đủ để lễ tân chuẩn bị theo từng đêm.
Đối chiếu trên lịch đêm và trên hồ sơ đoàn
Bộ thử nên dùng một đoàn giả có ngày đến khác nhau, một phòng sức chứa khác và một dòng chưa đủ chỗ. Kiểm tra lịch từng đêm để thấy số tài nguyên bị giữ, rồi đối chiếu thông báo người liên hệ nhận được. Nếu hai màn hình nói khác nhau, chưa thể coi luồng tổng hợp là đúng chỉ vì form gửi thành công.
Thử sửa số người nhưng không sửa số phòng, sửa số phòng nhưng không sửa ngày và hủy riêng một dòng. Mỗi thao tác cần kỳ vọng rõ về phần được giữ, phần được giải phóng và nội dung cần thông báo lại. Dùng môi trường thử có quyền, không làm biến động lịch phòng đang bán cho khách thật.
Cuối cùng thử mở lại yêu cầu cũ để xác nhận không tạo thêm phân bổ chỉ vì người liên hệ gửi lại. Người vận hành cần thấy mã đoàn, các dòng và trạng thái trước sau, không cần xuất dữ liệu cá nhân vào báo cáo nghiệm thu. Nếu cần Onter xây luồng đặt phòng đoàn, hãy Nhận tư vấn & báo giá theo cách xác nhận toàn đoàn hoặc từng phần của cơ sở; giá liên hệ.
