Mẫu quy trình sàng lọc và điều phối khách hàng tiềm năng
Điều phối tự động chỉ hữu ích khi mỗi quyết định đều giải thích được bằng thông tin người mua đã cung cấp. “Có vẻ là khách tốt” không phải quy tắc. Quy trình tốt phải lưu tín hiệu, áp dụng điều kiện nhìn thấy được, chuyển việc đến đúng một nơi chịu trách nhiệm và xác nhận nơi đó đã nhận.
Mẫu này trung lập về sản phẩm. Bài không tuyên bố Easy AI hay một CRM có sẵn tích hợp nào. Hãy sao chép phần dưới vào một tài liệu trống, điền cùng người phụ trách bán hàng và vận hành, rồi thử bằng một sự kiện có gắn nhãn trên hệ thống đội đã xác minh.
Sao chép phiếu quy trình
Tên quy trình: Sàng lọc và điều phối yêu cầu mới
Sự kiện kích hoạt: Hội thoại hoặc biểu mẫu mới đủ điều kiện
Điều kiện vào: Có quyền liên hệ, đường liên hệ, nguồn, thời điểm, không trùng hồ sơ đang mở
Chiều sàng lọc: Mức phù hợp / nhu cầu đã nêu / thời điểm / bước tiếp theo được yêu cầu
Kết quả: Sẵn sàng cho bán hàng / nuôi dưỡng / loại / người xem lại
Khóa điều phối: Khu vực / sản phẩm / ngôn ngữ / năng lực / tài khoản chỉ định
Người nhận và người dự phòng:
Sự kiện nhận việc và thời hạn:
Điều kiện dừng và hoàn tác:
event_id:
source_event_at và múi giờ:
contact_permission và nguồn:
buyer_goal theo lời người mua:
qualification_evidence (trường/giá trị/nguồn/phiên bản luật):
qualification_outcome:
qualification_reason (mã luật):
routing_key dùng trong hệ thống:
assigned_owner và acceptance_state:
next_step_requested:
workflow_version:
Không chạy khi đội bán hàng và vận hành chưa điền đủ từng dòng. OpenAI và Anthropic đều khuyến nghị giới hạn rõ quy trình, công cụ, rào chắn và điểm can thiệp của con người thay vì mặc định tăng quyền tự chủ. Xem hướng dẫn của OpenAI và bài kỹ thuật của Anthropic.
Định nghĩa quyết định trước khi đặt câu hỏi
| Kết quả | Bằng chứng bắt buộc | Nơi nhận | Lối tắt bị cấm |
|---|---|---|---|
| Sẵn sàng cho bán hàng | Nhu cầu đã nêu, đạt luật phù hợp, yêu cầu gặp người bán hàng | Một nhân viên hoặc hàng đợi cụ thể | Đoán ngân sách, thẩm quyền hoặc mức gấp |
| Nuôi dưỡng | Nhu cầu có liên quan nhưng chưa sẵn sàng cho bán hàng | Người phụ trách nuôi dưỡng | Xem im lặng là đồng ý |
| Loại | Đạt điều kiện loại đã duyệt và có lý do | Trạng thái đóng hoặc lựa chọn phù hợp | Dùng thuộc tính được bảo vệ hoặc không liên quan |
| Người xem lại | Thông tin mâu thuẫn, nhạy cảm, giá trị cao hoặc ngoài phạm vi | Hàng đợi xem lại có người theo dõi | Để mô hình âm thầm giải quyết bất định |
Tài liệu của Salesforce mô tả sàng lọc là đánh giá mức phù hợp và tín hiệu mua trước khi đưa khách đi tiếp trong quy trình bán hàng. Hãy dùng nguyên tắc này nhưng tự ghi rõ tiêu chí của đội. Xem nguồn.
Lập bảng quy tắc
Thay chỗ mẫu bằng quy tắc đã được người phụ trách doanh thu phê duyệt. Điều kiện để trống vẫn an toàn hơn điều kiện được đoán.
| Mã | Trường bằng chứng | Điều kiện | Kết quả |
|---|---|---|---|
| Q1 | Nhu cầu đã nêu | Khớp nhóm vấn đề được hỗ trợ | Đi tiếp |
| Q2 | Bước tiếp theo | Yêu cầu người bán hàng liên hệ rõ ràng | Ứng viên sẵn sàng |
| Q3 | Thời điểm | Người mua tự nêu thời gian đội hỗ trợ | Gắn nhãn thời điểm |
| Q4 | Điều kiện loại | Khớp điều kiện đã duyệt | Loại |
| R1 | Tài khoản chỉ định | Khớp chính xác tài khoản đã xác minh | Sẵn sàng |
| R2 | Ngôn ngữ và năng lực | Có kênh/ngôn ngữ và hàng đợi còn nhận | Sẵn sàng |
| Mã | Nơi chuyển | Khi thiếu hoặc mâu thuẫn |
|---|---|---|
| Q1 | — | Hỏi một câu làm rõ |
| Q2 | Áp dụng luật điều phối | Người xem lại nếu thiếu danh tính/liên hệ |
| Q3 | — | Ghi chưa nêu, không suy đoán |
| Q4 | Người quản lý trạng thái đóng | Người xem lại nếu bằng chứng mâu thuẫn |
| R1 | Người phụ trách tài khoản | Vận hành xem lại khi trùng chủ sở hữu |
| R2 | Hàng đợi hợp lệ | Hàng đợi dự phòng; không làm mất sự kiện |
Bảng tách sàng lọc khỏi giao việc. Một khách có thể sẵn sàng cho bán hàng nhưng chưa xác định được nơi nhận; hãy giữ đúng trạng thái thay vì sửa kết quả sàng lọc.
Khi đưa phiếu vào các trường CRM, hãy xem tên trường trong mẫu là phiên bản dành cho hệ thống của các dòng dễ đọc phía trên, không phải một phiếu thứ hai cần điền. event_id giúp xử lý lại mà không tạo trùng; source_event_at giữ thời điểm gốc; contact_permission ghi quyền liên hệ và nguồn xác nhận. qualification_evidence, qualification_outcome và qualification_reason lưu điều người mua nói, kết quả và quy tắc tạo kết quả. routing_key, assigned_owner và acceptance_state cho biết yêu cầu được chuyển đi đâu và đã có người nhận chưa. Khi sửa, hãy thêm sự kiện quyết định mới thay vì xóa lịch sử.
Trình tự thực thi
- Kiểm tra điều kiện vào và loại sự kiện trùng.
- Chỉ lấy trường làm thay đổi quyết định đã duyệt.
- Chạy luật theo thứ tự cố định và hiện rõ dữ liệu thiếu/mâu thuẫn.
- Ghi kết quả và lý do trong cùng giao dịch nếu hệ thống cho phép.
- Đối chiếu khóa điều phối với người phụ trách và năng lực hiện hành.
- Gửi mẫu bàn giao có cấu trúc.
- Chờ sự kiện nhận việc; dùng tuyến dự phòng khi bị từ chối hoặc quá hạn.
- Đối soát người nhận và bước tiếp theo, rồi đo từ bản ghi sự kiện.
Lần chạy hư cấu đã hoàn tất
Công ty hư cấu Northstar nhận sự kiện E-1042 từ Linh, Giám đốc Vận hành của doanh nghiệp dịch vụ 40 người. Linh nêu nhu cầu điều phối yêu cầu trên website, dùng tiếng Việt và tiếng Anh, đồng thời xin buổi trao đổi trong tháng. Q1, Q2 và Q3 đạt; không có điều kiện loại. R1 không tìm thấy tài khoản chỉ định; R2 chọn hàng đợi song ngữ và người phụ trách nhận việc sau sáu phút. Ví dụ điền đúng cấu trúc mẫu ở đầu bài.
Tên quy trình: Sàng lọc và điều phối yêu cầu dịch vụ Northstar
Sự kiện kích hoạt: Hội thoại website mới đủ điều kiện
Điều kiện vào: quyền=có; đường liên hệ=email; nguồn=website; có thời điểm; không trùng
Chiều sàng lọc: Mức phù hợp / nhu cầu / thời điểm / bước tiếp theo
Kết quả: Sẵn sàng cho bán hàng / nuôi dưỡng / loại / người xem lại
Khóa điều phối: Việt Nam / tự động hóa dịch vụ / vi+en / hàng đợi mở / không có tài khoản chỉ định
Người nhận và dự phòng: bilingual-inbound-queue / revenue-operations-review
Sự kiện nhận việc và thời hạn: queue.accepted trong mốc nội bộ 15 phút của Northstar
Điều kiện dừng và hoàn tác: Dừng khi thiếu quyền, mâu thuẫn danh tính hoặc ghi CRM lỗi; rút giao việc và chuyển vận hành xem lại
event_id: E-1042
source_event_at và múi giờ: 2026-08-16 10:00 ICT
contact_permission và nguồn: có; yêu cầu rõ trên website
buyer_goal: Điều phối yêu cầu website về đúng nhóm dịch vụ
qualification_evidence: Q1=vấn đề được hỗ trợ/tin-3/v2026-08-16-a; Q2=buổi trao đổi/tin-5/v2026-08-16-a; Q3=trong tháng/tin-5/v2026-08-16-a
qualification_outcome: sales-ready
qualification_reason (mã luật): Q1,Q2,Q3,R2
routing_key dùng trong hệ thống: language=vi+en; territory=Vietnam; named_account=false
assigned_owner và acceptance_state: bilingual-inbound-queue; accepted lúc 10:06 ICT
next_step_requested: discovery call
workflow_version: 2026-08-16-a
Lần chạy chỉ chứng minh quy tắc hư cấu hoạt động như thiết kế; không chứng minh chất lượng khách, chuyển đổi hay hiệu năng sản phẩm.
Ngoại lệ, kiểm tra và đo lường
| Lỗi | Phản ứng ngay | Người xử lý |
|---|---|---|
| Sự kiện kích hoạt trùng hoặc phát lại | Chặn hồ sơ thứ hai, liên kết lần phát lại | Vận hành |
| Bằng chứng sàng lọc mâu thuẫn | Đặt human-review, giữ cả hai giá trị | Người phụ trách bán hàng |
| Người nhận vắng hoặc từ chối | Chuyển một lần sang tuyến dự phòng đã định | Người quản lý điều phối |
| Ghi CRM xong nhưng báo tin lỗi | Giữ trạng thái chờ, thử lại an toàn | Người phụ trách hệ thống |
| Rút quyền liên hệ | Dừng liên hệ và áp dụng quy trình chặn đã duyệt | Người phụ trách riêng tư |
Trước khi mở rộng, lấy mẫu quyết định và tự tính lại từ bằng chứng đã lưu. Theo dõi bàn giao được nhận, điều phối chưa xong, sự kiện trùng bị chặn, thời gian nhận việc, lần sửa và kết quả xử lý sau đó. Không gọi tỷ lệ điều phối là kết quả doanh thu.
Câu hỏi thường gặp
Ba câu hỏi sau xử lý các trường hợp thường gặp sau khi đội đã định nghĩa quy tắc và người nhận.
Mọi khách hàng tiềm năng có cần điểm số không? Không. Kết quả theo quy tắc thường dễ kiểm tra hơn. Chỉ dùng điểm khi trọng số, ngưỡng và cách hiểu có người chịu trách nhiệm.
Nếu khách đủ điều kiện nhưng không có người nhận thì sao? Giữ nguyên kết quả, đặt nhận việc là đang chờ, kích hoạt dự phòng và giữ sự kiện nhìn thấy được. Không âm thầm hạ mức hay làm mất yêu cầu.
Quy trình có được đoán ngân sách hoặc mức gấp bị thiếu không? Không. Ghi chưa nêu, hỏi một câu đã duyệt khi hữu ích hoặc chuyển cho người xem lại.
Bước tiếp theo và giới hạn
Tiếp tục hoàn thiện quy trình. Dùng bảng đánh giá mức sẵn sàng của đội doanh thu trước khi triển khai và mẫu bàn giao cho đội bán hàng cho nội dung gửi đến người phụ trách bán hàng.
Ranh giới bằng chứng. Ví dụ và điều kiện chỉ dùng để hướng dẫn, không phải chuẩn thị trường. Bản nháp không tuyên bố tính năng, tích hợp, độ chính xác sàng lọc, mức cải thiện phản hồi hay kết quả doanh thu của Easy AI.
