Mai phụ trách một cơ hội bán hàng đang chờ khách bổ sung thông số. Tuần tới Mai nghỉ phép, còn người trực thay là An. Nếu chỉ đổi tên salesperson sang An, đội có thể mất dấu ai đang giữ quan hệ lâu dài. Nếu giữ nguyên mọi thứ, thông báo và việc đến hạn có thể tiếp tục nằm ở người đang nghỉ. Cách tổ chức tốt cần trả lời được ai xử lý trong khoảng này, việc nào được giao và khi nào hai bên rà lại phần còn dở.
Tình huống trên hoàn toàn giả định. Bài viết đề xuất cách bàn giao lead khi sales nghỉ phép cho một nhóm có CRM hỗ trợ phân quyền phù hợp. Đây là thiết kế vận hành để thảo luận, không phải tính năng đã có trên một sản phẩm Onter, không khẳng định Odoo tự đồng bộ nghỉ phép để chuyển toàn bộ cơ hội và không yêu cầu người nghỉ tiếp tục trực.
Thử đi theo một yêu cầu đang mở
Trước ngày nghỉ, Mai đã nhận yêu cầu về cấu hình sản phẩm nhưng chưa có đủ thông số. Khách dự kiến trả lời trong tuần tới. An cần đọc câu hỏi đã gửi, biết tài liệu nào đang chờ và được phép làm gì sau khi nhận được. An không cần toàn bộ hộp thư của Mai hoặc quyền xem mọi khách hàng trong công ty để hoàn thành việc này.
Trong phương án đề xuất, Mai vẫn được ghi là người quản lý quan hệ ban đầu, An là người phản hồi tạm thời từ ngày bắt đầu đến mốc rà lại đã thống nhất. Cơ hội giữ nguyên định danh để nhân viên tiếp tục cùng lịch sử. Nếu CRM chỉ có một trường salesperson, đội cần chọn cách ghi nhận bổ sung được hỗ trợ hoặc thống nhất một sổ đối chiếu có kiểm soát; không được giả vờ hệ thống đã có hai vai trò sẵn.
Có thể ghi một lời bàn giao ngắn: “Đang chờ thông số mục X; khi nhận được, kiểm tra cùng kỹ thuật; không xác nhận giá ngoài bảng đã duyệt; trường hợp khách yêu cầu thay phạm vi chuyển trưởng nhóm”. Nội dung như vậy giúp An hành động đúng hơn một ghi chú chung “chăm sóc giúp”. Không sao chép hợp đồng hoặc dữ liệu cá nhân không cần thiết vào một danh sách chia sẻ rộng quyền.
Khi khách trả lời, An bổ sung kết quả vào đúng cơ hội và tạo bước tiếp theo theo quy trình của nhóm. Việc An đã phản hồi không tự làm An trở thành người quản lý quan hệ vĩnh viễn. Tương tự, tên Mai còn trong hồ sơ không có nghĩa mọi việc đều được giao cho Mai trong thời gian nghỉ. Hai vai trò cần được giải thích bằng trách nhiệm, không chỉ bằng vị trí hiển thị trên màn hình.
Bàn giao lead khi sales nghỉ phép cần hai vai trò
Tài liệu Odoo 19 về đội bán hàng mô tả thành viên và quy tắc phân công lead. Với rules-based assignment, có tùy chọn Pause assignment để ngừng giao tự động cho một người; tài liệu lưu ý vẫn có thể giao thủ công. Vì vậy, tạm ngừng phân công mới không chứng minh những việc đang mở đã được chuyển sang người khác.
Hãy tách hai danh sách. Danh sách thứ nhất là các yêu cầu mới sẽ tới trong kỳ nghỉ; danh sách thứ hai là cơ hội và hoạt động đã mở cần người tiếp tục xử lý. Mỗi nhóm có thể dùng cách phân công khác nhau. Nếu chỉ thử một lead mới và thấy vào đúng người trực, vẫn chưa kiểm được một cuộc hẹn cũ hay lời nhắc đã gắn với người nghỉ.
Mô hình bổ sung có thể gồm người quản lý quan hệ, người xử lý tạm, thời gian hiệu lực và phạm vi công việc. Đây là đề xuất dữ liệu, không cam kết các trường ấy có sẵn trong Odoo hoặc mọi CRM. Nếu chỉ thay một trường hiện có, cần lưu được căn cứ trước sau để không quên trả lại hoặc chuyển nhầm những hồ sơ không nằm trong danh sách đã duyệt.
Quyền cũng phải đi cùng phạm vi. An cần nhìn được thông tin để xử lý đúng việc, nhưng nhãn “trực thay” không tự cấp quyền gửi báo giá đặc biệt, mở tài liệu hạn chế hoặc thay đổi hợp đồng. Trưởng nhóm cần kiểm tra bằng vai trò thực tế trong môi trường được phép thử. Không chia sẻ tài khoản hay mật khẩu của người nghỉ để tránh bước phân quyền.
Mốc kết thúc là một lần đối chiếu
Giả sử ngày Mai trở lại, An đang chờ khách xác nhận một lịch trao đổi. Nếu hệ thống lập tức xóa vai trò của An mà không xem công việc đang dở, cuộc hẹn có thể rơi vào khoảng trống. Nhưng kéo dài quyền trực thay không giới hạn cũng khiến đội không biết ai chịu trách nhiệm. Mốc kết thúc nên kích hoạt việc rà lại và ra quyết định cụ thể theo chính sách của nhóm.
Một cách làm đề xuất là phân mỗi việc còn mở thành: trả về Mai; An tiếp tục đến một bước đã thống nhất; chuyển người khác theo quyết định mới. Giữ thông tin ai đang đợi phản hồi và hành động tiếp theo, không chỉ thông báo “đã bàn giao lại”. Nếu cần kéo dài khoảng xử lý tạm, ghi mốc mới cùng người xác nhận thay vì sửa ngày cũ để mất lịch sử quyết định.
Đừng tự đổi thời hạn đã hứa với khách chỉ vì người phụ trách nghỉ. Nếu không đáp ứng được, người có thẩm quyền cần trao đổi lại điều kiện thực tế. Bài này không đặt SLA chung và không cam kết đội có thể xử lý mọi yêu cầu trong một khoảng cố định. Ngày đến hạn là thông tin để tổ chức công việc; nó không thay quyền quyết định về phạm vi hoặc giá.
| Việc cần làm | Người thực hiện theo giả định | Điểm cần xác nhận |
|---|---|---|
| Nhận thông số còn thiếu | An | Đúng yêu cầu và đúng cơ hội |
| Chấp thuận thay phạm vi | Người có thẩm quyền | Không suy ra từ quyền trực thay |
| Rà việc còn mở khi quay lại | Mai, An và đầu mối nhóm | Ai tiếp tục từng việc |
Để không ghi đè một thay đổi mới, người thực hiện cần đọc lại người đang xử lý trước khi trả hồ sơ về. Có thể trong kỳ nghỉ trưởng nhóm đã chuyển một cơ hội sang bộ phận khác. Danh sách lập trước kỳ nghỉ không còn là lệnh đúng cho mọi cập nhật sau đó. Cách kiểm tra phiên bản cụ thể cần theo hệ thống và tích hợp đang sử dụng.
Đọc báo cáo và tin nhắn đúng vai trò
Một báo cáo “cơ hội theo salesperson” có thể trả lời khác báo cáo “việc đang chờ người trực”. Đội nên ghi rõ báo cáo đang phân nhóm theo trường nào. Nếu nhân viên thay trường chủ sở hữu để giải quyết hiển thị tạm thời, kết quả thống kê theo người có thể bị hiểu là quan hệ đã chuyển hẳn. Không tự dùng thay đổi ấy để kết luận hiệu suất hoặc quyết định phân bổ doanh số.
Về phía khách, chỉ cần biết đầu mối phù hợp và cách trao đổi; không nhất thiết công khai chi tiết lịch nghỉ của nhân viên. Tin giới thiệu có thể nói An hỗ trợ yêu cầu đang mở trong khoảng đã thống nhất. Không để hai người gửi những câu hỏi khác nhau vì mỗi người đọc một bản ghi riêng hoặc tiếp tục một chuỗi nhắc tự động chưa được rà.
Mini CRM của Onter hiện công bố phục vụ quản lý liên hệ đơn giản, dữ liệu riêng theo tài khoản và chưa có phân quyền đội ngũ. Vì vậy không dùng bài này để suy ra công cụ đó đã hỗ trợ trực thay theo nhóm. Với nhu cầu nhiều người, cần khảo sát giải pháp và quyền phù hợp trước khi triển khai.
Đợt thử nhỏ nên dùng một cơ hội chờ phản hồi, một hoạt động đã hẹn và một yêu cầu mới. Mô phỏng người trực không đủ quyền với tài liệu hạn chế, người ban đầu quay lại sớm và một cơ hội được chuyển chính thức trong kỳ. Kết quả mong đợi phải do nhóm chốt trước: đúng người nhận việc, giữ được lịch sử và không tự mở quyền ngoài phạm vi. Đây là đề xuất nghiệm thu, chưa phải bài kiểm thử đã chạy.
Nếu cần tích hợp website và CRM, hãy trao đổi với Onter bằng vài hồ sơ giả lập và một khoảng trực thay cụ thể. Mẫu nên chỉ rõ quan hệ ban đầu, người phản hồi, việc còn mở và cách kết thúc. Quy trình này khác bàn giao danh tính và kết nối AI Agent; không cần đổi tài khoản hệ thống chỉ vì một nhân viên nghỉ ngắn ngày.
