Nhân viên rảnh lúc 10 giờ, phòng rảnh lúc 11 giờ, nhưng website vẫn cho khách đặt lúc 10 giờ. Lỗi này xảy ra khi lịch xem hai tài nguyên như lựa chọn thay thế: chỉ cần một tài nguyên còn chỗ. Với dịch vụ bắt buộc có cả người thực hiện và phòng phù hợp, điều kiện đúng là hai bên cùng khả dụng trong toàn bộ khoảng phục vụ.
Bài viết bàn về website đặt lịch cần cả nhân viên và phòng ở tầng phân bổ nguồn lực. Đây là yêu cầu kỹ thuật khác với biểu mẫu tiếp nhận nhu cầu hoặc trợ lý hỏi giờ khách muốn đến. Một yêu cầu đã gửi không tự trở thành lịch được xác nhận nếu hệ thống chưa giữ được mọi tài nguyên bắt buộc.
Website đặt lịch cần cả nhân viên và phòng: bắt đầu từ bảng giờ
Giả sử dịch vụ kéo dài một giờ. Nhân viên An rảnh từ 9 giờ đến 11 giờ, phòng P rảnh từ 10 giờ đến 12 giờ. Giao nhau của hai khoảng là 10 giờ đến 11 giờ, vì vậy chỉ một giờ bắt đầu lúc 10 giờ đáp ứng ví dụ này. Không thể dùng phần rảnh của An lúc 9 giờ cộng phần rảnh của phòng lúc 11 giờ để tạo một lịch.
Nếu dịch vụ cần thêm mười lăm phút chuẩn bị phòng, phải đưa khoảng đó vào bài toán. Phòng có thể cần được giữ trước khi khách đến, trong khi nhân viên chỉ cần có mặt từ giờ phục vụ. Hai khoảng chiếm dụng không nhất thiết giống nhau; chúng phải cùng phù hợp với một lịch hẹn và quy tắc đã được doanh nghiệp duyệt.
Đối với dịch vụ có nhiều nhân viên có thể thực hiện và nhiều phòng phù hợp, ta tìm ít nhất một cặp nhân viên–phòng đáp ứng đồng thời. Đây là “chọn một người và một phòng”, không phải “chọn một trong danh sách người hoặc phòng”. Cách diễn đạt trong bản yêu cầu sẽ ảnh hưởng trực tiếp đến mô hình dữ liệu và nghiệm thu.
Danh sách tài nguyên không tự tạo điều kiện đồng thời
Một giao diện cho thêm nhiều resource có thể khiến người quản trị tưởng rằng booking giữ được tất cả. Tuy nhiên, tài liệu WooCommerce Bookings về resources nêu mặc định chỉ một tài nguyên được chọn hoặc gán cho mỗi booking. Với gán tự động, có một tài nguyên khả dụng có thể đủ để ô lịch hiển thị còn chỗ.
Do đó, đưa An và phòng P vào cùng danh sách của sản phẩm chưa chứng minh có điều kiện An và P. Đây không phải lỗi sản phẩm nếu mô hình được thiết kế để chọn một tài nguyên. Đội tích hợp cần chọn cách kết hợp được hỗ trợ, bổ sung lớp điều phối có kiểm thử hoặc đưa luồng về trạng thái chờ nhân viên xác nhận khi chưa có bảo đảm.
Không nên tạo một tài nguyên ảo tên “An cộng phòng P” mà bỏ qua lịch riêng của An và P. Khi An phục vụ một dịch vụ khác hoặc P được dùng cho cuộc hẹn khác, lịch của tài nguyên ảo cũng phải bị ảnh hưởng. Nếu chúng chạy độc lập, cái tên đẹp trong trang quản trị không ngăn được đặt chồng.
Phòng phù hợp quan trọng hơn phòng đang trống
Một phòng rảnh nhưng thiếu thiết bị hoặc không đủ sức chứa không phải phương án thay thế hợp lệ. Tương tự, một nhân viên rảnh chưa chắc được phân công loại dịch vụ đó. Trước khi tính giờ, cần lọc tập ứng viên theo điều kiện phù hợp: chuyên môn, khu vực, thiết bị, số người và những giới hạn vận hành thật.
Với ví dụ một buổi chụp cần người chụp và phòng có phông nền, phòng họp còn trống không thể dùng thay. Nếu thiết bị di động dùng chung giữa hai phòng, có thể phát sinh tài nguyên bắt buộc thứ ba. Doanh nghiệp cần biết lúc nào bài toán chỉ có người và phòng, lúc nào phải xét thêm thiết bị để tránh hứa một lịch không thể thực hiện.
Quy tắc phù hợp nên có người chịu trách nhiệm cập nhật. Khi một phòng ngừng khai thác hoặc nhân viên đổi lịch làm việc, không nên sửa thủ công từng trang dịch vụ. Một nguồn dữ liệu chung, có lịch sử và phân quyền hợp lý, giúp giảm khác biệt giữa lịch khách nhìn thấy và nguồn lực tại cơ sở.
Kiểm tra toàn bộ khoảng và thời gian chuyển tiếp
Website phải xác định khoảng cần giữ cho từng tài nguyên, gồm phần phục vụ và phần đệm nếu có. Lịch một giờ bắt đầu lúc 10 giờ không hợp lệ nếu phòng chỉ rảnh đến 10 giờ 30. Kiểm tra mỗi thời điểm bắt đầu sẽ bỏ sót xung đột nằm giữa cuộc hẹn hoặc ở bước dọn phòng sau đó.
Tài liệu availability của WooCommerce Bookings phân biệt kiểm tra mọi khối trong thời lượng với chỉ khối bắt đầu. Đó là một điểm cấu hình cần đối chiếu trong giải pháp dùng sản phẩm này; với nền tảng khác, phải tìm hành vi tương ứng và chứng minh bằng ví dụ thực tế.
Khoảng nghỉ của nhân viên, thời gian di chuyển giữa chi nhánh và thời gian vệ sinh phòng là ba điều kiện khác nhau. Một khoảng đệm chung có thể quá dài cho người nhưng quá ngắn cho phòng. Nếu phần mềm chỉ có một tham số, cần đánh giá giới hạn đó bằng lịch thật trước khi chọn cách cấu hình thuận tiện nhất.
Đọc lịch thành công chưa phải giữ lịch thành công
Một API cho biết các khoảng bận chỉ cung cấp đầu vào tại thời điểm đọc. Chẳng hạn Google Calendar Freebusy nhận khoảng thời gian và trả về các khoảng bận theo lịch, cùng thông tin lỗi có thể gặp. Đọc kết quả trống không có nghĩa hệ thống đã tạo cuộc hẹn hoặc khóa phòng.
Trong khoảng giữa đọc và ghi, một đơn khác có thể chiếm tài nguyên. Quy trình xác nhận cần kiểm tra lại và giữ tất cả tài nguyên bắt buộc theo cơ chế chống xung đột phù hợp. Không được giữ nhân viên thành công, giữ phòng thất bại nhưng vẫn gửi email “đặt lịch thành công”. Trạng thái một phần phải được hủy hoặc xử lý rõ theo thiết kế.
Nếu kết nối lịch bị lỗi hoặc thiếu quyền xem một lịch bắt buộc, không được hiểu là lịch đó rảnh. Website có thể tạm ngừng xác nhận tự động cho dịch vụ bị ảnh hưởng và cho khách gửi yêu cầu. Cách xử lý này chỉ dừng đúng phần không thể xác minh, không nhất thiết khóa toàn bộ những dịch vụ có nguồn lực độc lập.
Đổi giờ và đổi người cần giữ được tính nhất quán
Khi khách đổi từ 10 giờ sang 11 giờ, hệ thống nên xác nhận phương án mới trước khi giải phóng phương án cũ theo quy trình đã thiết kế. Nếu trả ngay lịch cũ rồi mới phát hiện phòng mới không còn, khách có thể mất cả hai lựa chọn. Việc giữ tạm cũng cần thời hạn để không chặn lịch vô tận khi khách bỏ bước xác nhận.
Thay người thực hiện không chỉ đổi tên trên thông báo. Người mới phải đủ điều kiện và còn rảnh, trong khi phòng cũ có thể vẫn phù hợp hoặc cần đổi. Mọi thay đổi cần tác động đến đúng các nguồn lực liên quan. Lịch sử nên cho thấy ai đổi, đổi lúc nào và kết quả xác nhận, nhưng không đưa thông tin lịch cá nhân lên trang công khai.
Gửi lại yêu cầu sau timeout cần nhận diện cùng một thao tác, tránh tạo thêm cuộc hẹn. Một mã đặt chỗ ổn định giúp bộ phận vận hành đối chiếu giữa website, lịch nhân viên và phòng. Tên khách hoặc số điện thoại không nên được dùng làm khóa duy nhất vì một người có thể đặt nhiều lịch hợp lệ.
Nghiệm thu bằng một lỗi có chủ đích ở từng tài nguyên
Chuẩn bị các ca: chỉ nhân viên rảnh; chỉ phòng rảnh; cả hai rảnh nhưng thời lượng không đủ; cùng rảnh đủ toàn bộ khoảng; phòng rảnh nhưng không phù hợp. Mỗi ca cần có kết quả mong đợi rõ. Thử thêm hai yêu cầu đồng thời cùng dùng một phòng với hai nhân viên khác nhau để phát hiện lỗi khóa tài nguyên chung.
Tiếp theo, mô phỏng lỗi đọc một lịch trong môi trường kiểm thử, hủy giữ tạm và đổi giờ sang khoảng đã kín. Kiểm tra không chỉ lịch hiển thị mà cả nguồn lực được ghi nhận sau thao tác. Một bài trình diễn chỉ đặt được lúc mọi thứ đều trống không đủ bằng chứng cho cơ chế phân bổ đồng thời.
Nếu bạn đang chuẩn bị yêu cầu cho website đặt lịch tích hợp hệ thống vận hành, hãy mô tả một dịch vụ, các tài nguyên bắt buộc và lịch xung đột bằng dữ liệu giả lập. Giá: Liên hệ. Nhận tư vấn & báo giá theo phạm vi nguồn lực và mức xác nhận cần bảo đảm.
