Một cuộc gọi đáng lẽ hoàn tất vào ngày 5 nhưng sales đến ngày 8 mới thực hiện. Việc tiếp theo được đặt cách hai ngày sẽ đến hạn ngày 7 hay ngày 10? Hai kết quả đều có thể phù hợp với một cách tổ chức công việc, nhưng chúng phục vụ hai ràng buộc khác nhau. Nếu đội không chốt mốc tính trước khi tự động hóa, danh sách nhắc việc có thể báo trễ ngay khi vừa được tạo.
Thiết kế chuỗi nhắc việc CRM không đơn thuần là chọn số ngày. Điều cần biết là bước sau phải giữ một lịch đã cam kết hay cần cách bước trước một khoảng thực tế. Bài viết dùng các ngày và vai trò giả lập, phân tích cách chọn mốc trong chuỗi hoạt động Odoo 19. Các lịch minh họa là phép tính để thảo luận, không phải kết quả đã chạy trên một CRM khách hàng.
Giữ lịch cố định và chờ đủ khoảng cách là hai nhu cầu
Hãy xét hai công việc cùng mang tên “follow-up”. Với công việc thứ nhất, khách đã hẹn trả lời vào ngày 12. Sales cần nhắc đúng ngày đó dù bước chuẩn bị nội bộ bị muộn. Với công việc thứ hai, khách cần có hai ngày xem tài liệu kể từ khi thật sự nhận. Nếu tài liệu được gửi muộn, giữ nguyên ngày nhắc cũ có thể làm sales liên hệ khi khách chưa có thời gian đọc.
Không thể chọn chỉ bằng tên loại hoạt động. Đội cần mô tả lý do của khoảng cách: mốc cam kết bên ngoài, thời gian chờ để khách xử lý hay khoảng chuẩn bị nội bộ. Một cấu hình thống nhất cho mọi “follow-up” có thể làm việc dễ quản lý ở màn hình cài đặt nhưng khó giải thích khi lịch thực tế không còn đúng nhu cầu.
Trong tình huống giả ban đầu, tính hai ngày sau hạn cũ cho ra ngày 7; tính hai ngày sau hoàn tất thực tế cho ra ngày 10. Hai ngày này chỉ dùng để minh họa phép neo lịch. Chúng không mặc nhiên là ngày làm việc, thời điểm giờ cụ thể hoặc SLA. Các quy tắc về cuối tuần, giờ địa phương và thời điểm đồng bộ cần được kiểm riêng ở hệ thống đang dùng.
Tài liệu Odoo 19 về hoạt động CRM phân biệt lịch dựa vào hạn hoạt động trước với lịch dựa vào ngày hoàn tất trước. Đây là lựa chọn cấu hình cần hiểu trước khi giao chuỗi việc cho nhóm. Nó không tự quyết định ràng buộc kinh doanh nào quan trọng hơn trong một cơ hội cụ thể.
Thử đi qua một cơ hội gửi tài liệu kỹ thuật
Giả sử Lan phải gửi tài liệu vào ngày 5. Khách cần xem trong hai ngày rồi mới có thể trả lời danh sách câu hỏi. Lan thực tế gửi vào ngày 8. Nếu mục đích của việc kế tiếp là hỏi ý kiến sau khi khách có đủ thời gian đọc, nhóm có lý do chọn mốc gắn với hoàn tất thực tế. Ngày sinh ra cần được đối chiếu với sự kiện đã hoàn tất, không chỉ với lịch dự kiến ban đầu.
Tuy nhiên, “đánh dấu xong” phải có nghĩa nhất quán. Nếu Lan đóng việc lúc chuẩn bị xong file nhưng đến hôm sau mới gửi, khoảng chờ trong mô hình không còn trùng với khoảng khách thực sự có tài liệu. Lúc này sửa số ngày không giải quyết gốc vấn đề. Đội phải thống nhất tiêu chí hoàn tất cho việc gửi tài liệu và bằng chứng tối thiểu cần lưu.
Không cần biến tiêu chí thành ghi chú quá dài. Có thể yêu cầu ghi rõ bản tài liệu nào được gửi, qua kênh nào và điểm còn chờ khách. Điều quan trọng là người tiếp nhận hiểu sự kiện khởi đầu khoảng chờ đã xảy ra. Không dùng một dấu hoàn tất chung cho cả chuẩn bị, duyệt nội bộ và gửi ra ngoài khi ba bước này có thời điểm khác nhau.
Trường hợp ngoại lệ cũng cần đường xử lý. Nếu khách nói sẽ xem vào tuần sau, sales không nên giữ một lời nhắc máy móc chỉ vì nó được tạo tự động. Người có trách nhiệm cần cập nhật theo thỏa thuận thật và giữ được căn cứ thay đổi. Khả năng sửa lịch là công cụ vận hành, không phải bằng chứng hệ thống tự hiểu ý khách từ mọi cuộc trao đổi.
Còn nếu phía khách đã chốt buổi họp?
Giả sử buổi họp đánh giá đã được ấn định ngày 12, không phụ thuộc lúc gửi tài liệu. Một việc kiểm hồ sơ trước cuộc họp cần bám vào mốc ấy. Nếu lấy ngày hoàn tất một bước muộn làm gốc cho tất cả việc sau, lịch có thể trôi qua cả cuộc họp. Trong trường hợp này, nhóm phải nhìn toàn chuỗi và xử lý việc chuẩn bị trễ, thay vì để công thức dời lịch thay cho quyết định.
Đây là lý do không nên hứa một chuỗi nhắc việc sẽ tự sửa mọi chậm trễ. Có những ràng buộc phải giữ, có những khoảng có thể lùi, và có những tình huống cần trao đổi lại với khách. Một cấu hình chỉ biểu diễn phần đã được thống nhất. Các xung đột còn lại cần được hiện ra cho người có quyền giải quyết.
Chọn mốc bằng câu hỏi nghiệp vụ trước khi chọn trường
Với mỗi bước nối, hãy hỏi: nếu bước trước làm trễ ba ngày, bước này có nên trễ theo ba ngày không? Nếu câu trả lời là có vì cần đủ thời gian kể từ việc đã xảy ra, mốc hoàn tất thực tế là ứng viên để xem xét. Nếu câu trả lời là không vì có hạn bên ngoài, cần mô hình lịch giữ mốc ấy và đường cảnh báo chậm chuẩn bị.
Câu hỏi thứ hai là ai chịu hậu quả khi ngày sinh ra không phù hợp. Nhân viên thực hiện có quyền sửa lịch cá nhân nhưng chưa chắc có quyền đổi hạn đã hứa với khách. Đừng để một lựa chọn tự động trở thành cách thay đổi cam kết mà không ai nhận ra. Ghi rõ ngày dự kiến trong CRM và cam kết thương mại nếu chúng có ý nghĩa khác nhau.
Câu hỏi thứ ba là sự kiện nào đủ để gọi là hoàn tất. Đã gọi nhưng khách không nghe máy, đã soạn thư nhưng chưa gửi, đã nhận file nhưng chưa kiểm đều là các tình huống khác nhau. Đội có thể cần các loại việc hoặc quy ước ghi kết quả khác nhau. Không nhất thiết tăng số trạng thái; cần đủ phân biệt những điều làm thay đổi quyết định kế tiếp.
Cuối cùng, hãy hỏi chuỗi này có thực sự cần tự nối hay chỉ cần gợi ý. Mốc ngày và cách tạo bước tiếp theo là hai quyết định liên quan nhưng không giống nhau. Một ngày được tính đúng chưa chứng minh việc đó nên được tạo trong mọi trường hợp. Chẳng hạn, nếu khách đã chủ động trả lời đầy đủ, một hoạt động hỏi lại cùng nội dung có thể không còn ích lợi.
Gợi ý bước sau hay tạo ngay một việc mới?
Mốc tính trả lời khi nào; cách nối trả lời bước kế tiếp có tự xuất hiện thành việc phải làm hay chưa. Trong cấu hình Odoo 19, Suggest Next Activity đưa ra khuyến nghị, còn Trigger Next Activity nối bước sau khi việc trước được đánh dấu Done. Đội nên chốt hai lựa chọn này cùng nhau thay vì chọn lịch đúng rồi bỏ qua việc nào thực sự cần sinh.
Ví dụ, gửi một tài liệu chuẩn thường cần rà lại phản hồi. Nhưng sau cuộc gọi, khách có thể đã trả lời ngay mọi câu hỏi hoặc nói chưa có nhu cầu. Một gợi ý để sales chọn bước phù hợp có thể hữu ích hơn tự tạo thêm lời nhắc giống nhau. Ngược lại, một bước đối chiếu nội bộ luôn bắt buộc sau khi nhận hồ sơ là ứng viên cho cơ chế tự nối, nếu đội đã xác định rõ điều kiện hoàn tất bước trước.
Đó là quyết định thiết kế, không phải lời hứa Odoo tự suy luận mọi nhánh từ cuộc hội thoại. Nếu cần rẽ nhánh theo kết quả, phải kiểm khả năng cấu hình hoặc tích hợp thực tế. Không dùng một chuỗi cố định để thay quy trình có nhiều quyết định rồi yêu cầu sales đóng hàng loạt công việc không còn cần thiết. Số nhiệm vụ được tạo không phải chỉ số hoàn tất nghiệp vụ.
Trong đợt thử, hãy ghi cả danh sách hoạt động mới sau mỗi lần hoàn tất. Một bước đã được lên lịch từ kế hoạch khác có thể khiến đội thấy nhiều việc hơn dự kiến; cần đối chiếu nguồn tạo thay vì xóa ngay vì nhìn giống nhau. Kiểm đúng cơ chế sinh giúp lựa chọn giữa khuyến nghị và tự tạo có căn cứ, đồng thời tránh biến cài đặt tiện lợi thành hàng chờ khó quản lý.
Đợt thử nên cố tình làm bước đầu trễ
Chỉ thử một cơ hội hoàn tất đúng hạn thường không giúp thấy khác biệt giữa hai mốc. Hãy dùng dữ liệu giả để thử ít nhất một bước hoàn tất đúng ngày và một bước hoàn tất muộn. Ghi hạn cũ, ngày hoàn tất, cấu hình đang chọn và hạn bước mới thực nhận. So kết quả với kỳ vọng đã viết trước khi thao tác, không sửa kỳ vọng theo kết quả màn hình.
Nên thêm trường hợp người dùng đánh dấu hoàn tất muộn hơn việc thực xảy ra. Mục tiêu là biết hệ thống dùng dấu thời gian nào, rồi chốt quy ước vận hành phù hợp. Tài liệu cấu hình không thay thế phép kiểm này trên phiên bản, ứng dụng và cách tích hợp đang có. Nếu có connector bên ngoài chỉnh ngày, cần đưa nó vào phạm vi thử thay vì chỉ xem giao diện native.
Kiểm cả người nhận công việc mới. Một lịch đúng nhưng rơi vào người đã nghỉ hoặc không có quyền mở hồ sơ vẫn không tạo được bước tiếp theo hữu ích. Việc phân công cần được đối chiếu riêng; thay đổi mốc tính ngày không tự giải quyết bàn giao nhân sự trong kỳ nghỉ. Cũng không nên đổi chủ sở hữu cơ hội chỉ để đưa một lời nhắc sang đồng nghiệp.
Đợt thử phải cho biết những gì chưa kiểm. Nếu mới xét số ngày theo ngày lịch thì chưa được kết luận đã kiểm lịch nghỉ. Nếu mới dùng một người trong cùng múi giờ thì chưa được kết luận giao tiếp xuyên múi giờ hoạt động đúng. Phạm vi hẹp nhưng được mô tả chính xác giúp lần triển khai tiếp theo biết còn thiếu ca nào.
Khi bàn giao, lưu bản cấu hình được chọn cùng hai hoặc ba ca phản ví dụ và hướng xử lý lịch đã sai. Không sửa hồi tố hàng loạt hoạt động cũ chỉ vì vừa thống nhất quy tắc cho việc mới. Cần xác định tập công việc còn mở, người có quyền điều chỉnh và những hạn cần trao đổi lại trước khi thay đổi.
Mục tiêu của mốc hạn nhắc việc CRM là đưa đúng việc đến đúng lúc để sales có thể hành động, không phải làm danh sách hết màu đỏ. Nếu cần khảo sát chuỗi follow-up và nối dữ liệu website với CRM theo quy tắc của nhóm, Onter có thể trao đổi phạm vi cấu hình, tích hợp và nghiệm thu. Giá: Liên hệ. Nhận tư vấn & báo giá.
