Đổi lịch trên Zalo Mini App cần xử lý đồng thời trải nghiệm khách, chỗ trống và trạng thái lịch trong hệ thống nghiệp vụ. Một luồng hoàn chỉnh phải xác nhận lịch mới thành công, xử lý lịch cũ và cập nhật lời nhắc liên quan; chỉ đổi thông tin hiển thị trên màn hình là chưa đủ.
Với salon, trung tâm dịch vụ hoặc đơn vị tư vấn, khách có thể đổi lịch nhiều lần hoặc thao tác khi nhân viên cũng đang điều chỉnh. Nếu không có quy tắc xác nhận và chống trùng, doanh nghiệp dễ giữ hai chỗ cho một người hoặc báo còn chỗ trong khi khung giờ đã kín.
Xác định hệ thống chịu trách nhiệm lịch
Mini App có thể là điểm chạm để khách chọn và quản lý lịch; trạng thái cuối phải do hệ thống lịch được chọn xác nhận. CNV đã mô tả hành trình đặt bàn và chăm sóc trên Mini App. [1] Bài viết này mở rộng thành khung thiết kế cho tình huống đổi lịch, không mặc định mọi loại lịch và tích hợp đều có sẵn.
Trước khi xây giao diện, thống nhất ai quản lý tài nguyên, thời lượng, chi nhánh và nhân viên phục vụ. Một khung giờ trống trong giao diện chưa đủ nếu tài nguyên cần thiết chưa sẵn sàng.
Luồng đổi lịch cần những bước nào?
| Bước | Việc cần làm | Kết quả cần xác nhận |
|---|---|---|
| Mở lịch hiện tại | Nhận diện đúng khách và lịch | Khách được phép thao tác |
| Kiểm tra điều kiện | Thời hạn, trạng thái, chính sách | Có thể đổi theo nghiệp vụ |
| Chọn phương án | Lấy chỗ trống từ nguồn quản lý | Dữ liệu đủ mới |
| Xác nhận | Kiểm tra lại chỗ và lưu thay đổi | Có mã hoặc trạng thái xác nhận |
| Cập nhật liên quan | Lịch cũ, lời nhắc, người phụ trách | Không còn hành động sai giờ |

Chỗ trống cần được kiểm tra lại tại thời điểm xác nhận.
Xử lý khi hai người cùng chọn một giờ
Hệ thống cần một cơ chế xác nhận tài nguyên nhất quán. Khi một người đã giữ hoặc đặt chỗ thành công, người còn lại phải nhận trạng thái cập nhật và lựa chọn khác, thay vì cùng thấy thông báo hoàn tất.
Nếu có giữ chỗ tạm, cần xác định thời hạn và lúc giải phóng. Không để giữ chỗ vô hạn khi khách đóng Mini App. Cách khóa, giữ hay xác nhận phụ thuộc hệ thống lịch; đây là yêu cầu cần khảo sát, không phải cam kết một cơ chế kỹ thuật áp dụng cho mọi nền tảng.
Không hủy lịch cũ quá sớm
Nếu lịch mới chưa được xác nhận nhưng lịch cũ đã bị xóa, khách có thể mất cả hai. Thiết kế cần xác định cách chuyển trạng thái và phục hồi khi một bước lỗi. Trong một số hệ thống, toàn bộ thay đổi có thể được xử lý như một nghiệp vụ thống nhất; hệ thống khác cần cơ chế đối soát hoặc bù trừ.

Chỉ báo thành công khi nguồn quản lý xác nhận; trạng thái chưa rõ cần được kiểm tra.
Khi kết nối timeout, không mặc định thao tác thất bại rồi tạo lại ngay. Hãy kiểm tra bằng mã yêu cầu hoặc cơ chế tra cứu tương ứng để biết thay đổi đã được lưu chưa. Điều này giảm nguy cơ tạo nhiều lịch từ một lần khách bấm.
Cập nhật lời nhắc và người phục vụ
Sau khi đổi thành công, các lời nhắc theo giờ cũ phải được hủy hoặc tính lại. Trước lúc gửi lời nhắc mới, kiểm tra lịch hiện tại lần nữa để phản ánh thay đổi mới nhất.
Nhân viên cần thấy lý do, thời điểm và lịch sử điều chỉnh đủ để hỗ trợ khách. Tránh tình huống khách đã được xác nhận đổi nhưng quầy tiếp đón vẫn dùng danh sách cũ. Cần kiểm thử cả màn hình khách lẫn màn hình vận hành.
Nội dung xác nhận nên rõ những gì?
Thông báo cần nêu lịch nào đã đổi, giờ mới, địa điểm và bước khách cần làm tiếp theo. Nếu yêu cầu đang chờ xác nhận thủ công, phải diễn đạt đúng trạng thái chờ. Không dùng cùng một thông điệp “thành công” cho cả hai trường hợp.
Nếu đổi lịch ảnh hưởng đặt cọc hoặc điều kiện cung cấp dịch vụ, hiển thị thông tin liên quan trước khi khách quyết định. Phạm vi điều chỉnh này cần được doanh nghiệp xác nhận theo chính sách của mình.
Kiểm thử trước khi mở cho khách
Thử các tình huống: khung giờ vừa kín, khách bấm hai lần, nhân viên đổi cùng lúc, mạng ngắt, lịch cũ đã hủy và đổi sát giờ phục vụ. Đo tỷ lệ đổi thành công, số trường hợp trùng, lịch treo và thời gian xử lý ngoại lệ.
Không chỉ kiểm tra tổng số lịch. Một tổng đúng vẫn có thể che việc lịch sai người hoặc lời nhắc sai giờ. Hãy đối chiếu từng tình huống quan trọng từ đầu vào đến trạng thái cuối.
Câu hỏi thường gặp
Đổi lịch có cần AI Agent không?
Không bắt buộc. Nghiệp vụ rõ có thể dùng luồng cố định. AI có thể hỗ trợ hội thoại, nhưng nguồn quản lý lịch vẫn cần xác nhận tài nguyên và thay đổi.
Lịch mới hiện trên màn hình là đã hoàn tất chưa?
Chưa chắc. Cần trạng thái xác nhận từ hệ thống lịch và cập nhật các phần liên quan như lịch cũ, lời nhắc và vận hành.
Có nên gửi lại yêu cầu khi mạng lỗi?
Cần kiểm tra kết quả trước hoặc dùng cơ chế chống trùng đã thiết kế. Gửi lại thiếu kiểm tra có thể tạo lịch lặp.
Bước tiếp theo
Vẽ luồng đổi lịch với cả nhánh thành công, hết chỗ và chưa rõ kết quả. Trao đổi với CNV CDP để xác nhận cách kết nối Mini App, hệ thống lịch và chăm sóc sau thao tác.
Đọc thêm: Xin quyền theo ngữ cảnh Mini App · Tracking plan cho CDP · Chống gửi trùng Automation.
Nguồn tham khảo
[1] CNV – Từ đặt bàn đến gắn kết khách hàng trên Zalo Mini App. Đối chiếu ngày 20/10/2026. Luồng đổi lịch và yêu cầu nghiệm thu là mô hình đề xuất theo nghiệp vụ.




