Một phòng cần ngừng sử dụng để sửa hệ thống nước trong hai ngày. Lễ tân khóa phòng trên lịch bán mới, nhưng đã có khách đặt từ trước. Nếu công cụ chỉ làm phòng biến mất khỏi trang đặt, phần cam kết cũ vẫn còn nguyên. Vấn đề không kết thúc ở thao tác chặn ngày: khách sạn cần biết ai đang bị ảnh hưởng và ai có quyền giải quyết.
Khóa phòng bảo trì trên website cần một quy trình gồm khoảng không phục vụ, các booking giao với khoảng đó và quyết định xử lý từng cam kết. Bài này dùng resource availability của WooCommerce Bookings làm tham chiếu kỹ thuật, còn quy trình chuyển phòng và thông báo là thiết kế đề xuất. Mọi phòng và tình huống minh họa đều giả định.
Khóa phòng bảo trì: chọn đúng phòng và khoảng thời gian
Phòng vật lý P5 bị hỏng khác việc cả loại phòng T2 tạm dừng bán. Nếu hệ thống chỉ quản lý số lượng loại phòng, một thay đổi ở P5 phải được chuyển thành mức năng lực có thể bán của T2 theo cách đã thiết kế. Nếu hệ thống quản lý từng phòng như một tài nguyên, cần biết chính xác booking nào đã được gán P5.
Tài liệu resource trong WooCommerce Bookings mô tả tài nguyên có lịch và số lượng khả dụng riêng, có thể được liên kết với sản phẩm đặt chỗ. Nhưng cách ánh xạ phòng vật lý, loại phòng và sản phẩm là quyết định triển khai. Không tự suy rằng mọi site dùng Bookings đều đã quản lý từng phòng.
Hãy bắt đầu bằng đơn vị mà đội lễ tân thực sự có thể phân bổ. Nếu khách mua một loại phòng và số phòng cụ thể được gán sau, quy trình bảo trì phải kiểm tra tổng năng lực còn lại và danh sách phân phòng. Nếu khách đặt đúng một căn riêng, không thể thay bằng căn khác mà coi như không có thay đổi với khách.
Khoảng bảo trì cũng cần ranh giới rõ: thời điểm bắt đầu, kết thúc dự kiến và khoảng chuẩn bị cần thiết trước khi nhận khách lại. Không dùng một ghi chú “sửa hai ngày” trong khi hệ thống hiểu theo ngày lịch khác với quy tắc nhận và trả phòng. Mọi bên cần cùng hiểu khoảng nào thực sự không thể phục vụ.
Không nhất thiết cộng một khoảng đệm cố định cho mọi sửa chữa. Đội vận hành có thể yêu cầu kiểm tra nghiệm thu phòng trước khi mở lại, hoặc dùng một mốc dự kiến rồi người có trách nhiệm xác nhận. Quan trọng là không mở bán lại chỉ vì đồng hồ đi qua ngày dự kiến trong khi phòng chưa được bàn giao.
Quyết định thứ hai: giữ nguyên hay thay đổi cam kết nào?
Trước khi áp dụng thay đổi, lập danh sách booking có thời gian giao với khoảng không phục vụ trong đúng phạm vi tài nguyên. Bao gồm các trạng thái mà cấu hình thực tế đang dùng để giữ lịch. Không chỉ nhìn các phòng đã trả tiền; một cam kết đang chờ duyệt hoặc chờ thanh toán cũng có thể cần được xử lý theo chính sách.
Hướng dẫn availability trình bày các lớp quy tắc và giới hạn lịch. Những quy tắc này giúp điều khiển khả năng đặt, nhưng không nên được diễn giải thành tự động bố trí chỗ thay thế cho mọi booking cũ. Cần kiểm tra lại hành vi thực tế của thay đổi và trách nhiệm đối với khách đã đặt.
Ví dụ giả định P5 bảo trì từ giữa một kỳ lưu trú. Booking B1 kết thúc trước khoảng này thì không cần chuyển; B2 ở xuyên qua mốc bắt đầu thì bị ảnh hưởng; B3 bắt đầu sau khi phòng đã được nghiệm thu có thể không bị ảnh hưởng. Một phép kiểm tra ngày đến đơn thuần sẽ bỏ sót B2, vì khách đã đến từ trước.
Trong danh sách ảnh hưởng, ghi hướng xử lý đề xuất chứ không âm thầm sửa. Có thể là kiểm tra phòng thay thế, trao đổi đổi ngày hoặc đưa tới người có quyền quyết định phương án khác. Đề xuất không phải cam kết mới. Trước khi thông báo phòng thay thế đã xác nhận, phải kiểm tra năng lực và những điều kiện khách đã chọn.
Kiểm tra cả trường hợp bảo trì được kéo dài. Một booking không giao với khoảng dự kiến ban đầu có thể bị ảnh hưởng bởi mốc kết thúc mới. Thay đổi khoảng cần tạo một lần đối chiếu bổ sung, giữ danh sách đã xử lý trước đó và bổ sung những cam kết mới phát hiện. Không coi việc đã rà soát hôm trước là bằng chứng mọi ngày kéo dài đều an toàn.
Nếu khách đang ở trong phòng, quy trình cần người vận hành xử lý trực tiếp theo tình huống, không chỉ một email tự động. Phần mềm hỗ trợ nhận diện và ghi nhận quyết định; nó không thay thế việc đánh giá điều kiện sử dụng thực tế của căn phòng.
Chuyển phòng cần bảo toàn những gì?
Những thuộc tính quan trọng có thể gồm sức chứa, cách bố trí giường, khả năng tiếp cận và dịch vụ đã mua. Phòng còn trống chưa chắc là phương án tương đương. Hãy để doanh nghiệp xác định thuộc tính nào bắt buộc và trường hợp nào cần khách chấp thuận, thay vì dùng một quy tắc đổi sang bất kỳ phòng trống.
Lưu liên kết giữa phân bổ trước và sau giúp lễ tân truy vết. Không xóa booking gốc rồi tạo một booking hoàn toàn mới chỉ để lịch trông sạch. Cách đó có thể làm mất lịch sử liên hệ, liên kết đơn và lý do thay đổi. Nếu công cụ hỗ trợ sửa tài nguyên, vẫn cần kiểm tra các tác động đi kèm trên thông báo và chi phí.
Tài liệu xem và sửa booking mô tả các trường có thể quản lý trong màn hình đặt chỗ. Trước khi sửa hàng loạt, thử với đúng một hồ sơ đặt phòng giả trong môi trường được phép. Xác minh giữ được liên kết đơn và dữ liệu không thuộc thay đổi, không suy rằng một nút lưu đảm bảo mọi ràng buộc nghiệp vụ.
Quyết định thứ ba: bằng chứng nào cho phép mở lại?
Hoàn tất sửa chữa theo báo cáo của nhà thầu và sẵn sàng nhận khách có thể khác thời điểm. Cần người chịu trách nhiệm bàn giao, kiểm tra điều kiện phòng và xác nhận khoảng không phục vụ đã kết thúc. Website chỉ nên nhận lại booking theo quyết định đó hoặc chính sách mở tự động đã được chứng minh phù hợp.
Nhật ký bảo trì tối thiểu cần tài nguyên, khoảng thời gian, lý do ngắn và trạng thái bàn giao. Danh sách khách bị ảnh hưởng chỉ nên hiện cho người có quyền xử lý booking, không đưa vào màn hình nhân viên bảo trì nếu họ không cần. Tách thông tin kỹ thuật của phòng khỏi hồ sơ cá nhân giúp phối hợp mà không chia sẻ thừa dữ liệu.
Về vận hành, nên có nơi xem các phòng đã quá mốc dự kiến nhưng chưa được mở, và các booking chưa giải quyết xong. Hai danh sách này trả lời hai câu hỏi khác nhau. Không dùng việc phòng đã sửa xong để tự đánh dấu mọi khách đã được thông báo hoặc đã chấp nhận phương án thay thế.
Thử nghiệm nên bắt đầu với một khoảng ngừng ngắn và vài booking giả có quan hệ thời gian khác nhau: kết thúc trước, bắt đầu trong, ở xuyên qua và bắt đầu sau khoảng đó. Đối chiếu danh sách ảnh hưởng với kỳ vọng bằng mã booking. Không cần tạo lịch kín nhiều tháng để chứng minh một phép kiểm tra giao khoảng.
Tiếp theo, tạo một booking mới thử đúng khoảng bị khóa và xác nhận không thể nhận theo quy tắc đã cấu hình. Kiểm tra một tài nguyên khác không bị khóa theo ngoài ý muốn. Nếu resource được chia sẻ giữa nhiều sản phẩm, thử cả các sản phẩm liên quan để nhận ra ảnh hưởng rộng trước khi dùng trên site đang phục vụ.
Sau khi thử mở lại, kiểm tra khoảng có thể đặt thực sự trên giao diện khách, không chỉ cờ nội bộ. Một quy tắc khác ở cấp sản phẩm hoặc cửa hàng vẫn có thể làm phòng chưa nhận được. Ngược lại, sửa một quy tắc rộng để mở phòng có thể vô tình mở thêm các khoảng khác; chỉ thay đúng phạm vi đã xác định.
Khi nghiệm thu, ba bằng chứng nên khớp: lịch bán mới đã chặn đúng, cam kết cũ có hướng xử lý truy vết được và phòng chỉ mở lại sau điều kiện bàn giao. Số phòng hiển thị đúng là chưa đủ nếu còn khách bị ảnh hưởng mà không có người phụ trách.
Nếu cần Onter thiết kế luồng khóa phòng bảo trì và đối soát booking trên website, hãy Nhận tư vấn & báo giá theo mô hình tài nguyên thực tế của cơ sở. Giá liên hệ; không cần thay toàn bộ hệ thống để bắt đầu bằng một ranh giới thay đổi rõ ràng.
