Kiến thức / Bán hàng – Chăm sóc khách hàng / Sale / CSKH

Workflow AI cho Sale bảo hiểm: lead đến follow-up

Workflow từ lead mới đến phân loại, tư vấn và follow-up dành cho Sale bảo hiểm

Tình huống thật khi một khách để lại thông tin ở hai kênh

Một khách điền biểu mẫu trên website lúc 9 giờ với nhu cầu “tìm hiểu giải pháp bảo vệ gia đình”, sau đó nhắn Zalo cho tư vấn viên lúc 9 giờ 12. CRM tạo hai lead; chatbot lại hỏi cùng một câu; nhân viên thứ hai gọi khi khách vừa trao đổi với người thứ nhất. Đây không phải lỗi viết nội dung. Nó là lỗi orchestration: thiếu khóa chống trùng, thiếu owner duy nhất và không có trạng thái chung để các kênh cùng đọc.

Trong bảo hiểm, tự động hóa sai còn kéo theo rủi ro lớn hơn. Ghi chú có thể bị hiểu thành kết luận nhu cầu, bảng quyền lợi có thể thuộc phiên bản cũ, hoặc follow-up được gửi dù consent marketing chưa có. Vì vậy workflow AI cho Sale bảo hiểm không bắt đầu bằng câu “hãy tư vấn gói phù hợp”. Nó bắt đầu bằng event envelope, needs packet chỉ chứa sự kiện đã xác nhận, source register có version và một điểm duyệt của tư vấn viên.

Mục tiêu của bài này là điều phối một lead từ lúc tiếp nhận đến khi có bản nháp follow-up hợp lệ, không thay tư vấn viên đưa ra kết luận quyền lợi, không dự đoán chấp thuận và không phê duyệt hồ sơ. Những câu hỏi về phạm vi bảo vệ, loại trừ, thời gian chờ, phí hoặc điều kiện chỉ được trích từ nguồn đang hiệu lực và phải được người có chuyên môn kiểm tra trong đúng ngữ cảnh.

Việc giao cho AI trong orchestration và ranh giới

AI phù hợp với các việc có tiêu chí kiểm được: chuẩn hóa số điện thoại, nối hai event có cùng định danh, phát hiện trường còn thiếu, gắn owner, tạo needs packet, kiểm source-id, so version, lập danh sách câu hỏi và soạn bản nháp theo mẫu đã duyệt. Mỗi hành động phải trả về state, evidence, confidence, missing_fields và next_owner; không được âm thầm điền dữ liệu không có.

AI chỉ phân loại trạng thái tác nghiệp, chẳng hạn NEW, DUPLICATE_REVIEW, NEEDS_REVIEW hoặc SOURCE_REVIEW. Nó không được phân loại khách “nên mua”, “khả năng chốt cao” từ dữ liệu nhạy cảm; không suy đoán sức khỏe, thu nhập hay trách nhiệm gia đình. Nếu ghi chú mơ hồ, đầu ra đúng là UNKNOWN cùng câu hỏi làm rõ, không phải một hồ sơ trông hoàn chỉnh nhưng dựa trên giả định.

Tư vấn viên giữ quyền xác nhận nhu cầu, giải thích tài liệu, chọn thông tin cần trao đổi và phê duyệt bản nháp. Chủ sản phẩm giữ quyền đối với bảng quyền lợi, điều khoản, phụ lục và minh họa phí. Khách hàng là chủ thể cấp hoặc rút consent. Bộ phận dữ liệu chỉ xác minh bằng chứng, ghi nhận trạng thái và thực thi đúng phạm vi cùng retention; không quyết định consent thay khách. AI không kết luận quyền lợi áp dụng, không kết luận hồ sơ được chấp thuận, không gửi thông điệp và không chuyển trạng thái CLOSED thay con người.

Dữ liệu và state machine cho một lead bảo hiểm

Event envelope tối thiểu có event_id, occurred_at, channel, raw_reference, normalized_phone_hash, consent_scope, campaign_source và ingest_status. Lead record có lead_id, owner_id, current_state, last_event_at, next_action_at và stop_reason. Needs packet tách facts có trích dẫn, UNKNOWN, câu hỏi chờ xác nhận và dữ liệu nhạy cảm đã loại bỏ. Không chép toàn bộ hội thoại vào mọi hệ thống chỉ để AI dễ đọc.

Product source packet dùng source_id theo nhóm BEN, TERMS, FEE và FAQ; mỗi nguồn có product_id, version, effective_at, expires_at, owner, reviewer và allowed_use. Một câu về quyền lợi phải nối được tới đoạn nguồn cụ thể. Hai tài liệu cùng loại nhưng khác phiên bản không được gộp. Nếu thiếu ngày hiệu lực, owner hoặc source mâu thuẫn, state phải là SOURCE_REVIEW thay vì tiếp tục tạo nội dung.

State machine đề xuất gồm QUARANTINE, NORMALIZED, MERGE_REVIEW, NEEDS_REVIEW, SOURCE_REVIEW, ADVISOR_REVIEW, FOLLOWUP_DUE, STOPPED, ERROR_PARTIAL và CLOSED. Mỗi lần chuyển trạng thái cần transition_id duy nhất, actor, input_version, rule_version và result. Idempotency key bằng lead_id cộng event_id cộng action_type giúp một webhook gửi lại không tạo hai tác vụ hoặc hai tin nhắn.

Workflow sáu bước từ lead mới đến bản nháp follow-up

Bước 1 — Tiếp nhận có kiểm dịch: webhook ghi event vào QUARANTINE, quét trường bắt buộc và che dữ liệu không cần thiết. Bước 2 — Identity candidate và MERGE_REVIEW: chuẩn hóa định danh và chỉ tạo merge candidate, không tự hợp nhất dù khóa trùng mạnh. Mọi candidate bắt buộc vào MERGE_REVIEW; tư vấn viên hoặc Data Steward xác nhận gộp hay giữ riêng. Quyết định merge ghi actor, evidence, before/after, reason, audit log và rollback key trước khi record thay đổi.

Bước 3 — Lập needs packet: Agent tách câu khách đã nói, UNKNOWN và câu hỏi làm rõ; không kết luận nhu cầu. Bước 4 — Đóng gói nguồn: hệ thống lấy đúng bộ quyền lợi–điều khoản đang hiệu lực, phát hiện conflict và ghi source_ref. Thiếu nguồn thì dừng ở SOURCE_REVIEW, không lấy kiến thức chung của mô hình để bù.

Bước 5 — Tư vấn viên duyệt: người phụ trách kiểm needs packet, nguồn, phạm vi consent và bản nháp agenda. Chỉ sau APPROVED_BY_ADVISOR mới tạo tác vụ follow-up. Bước 6 — Theo dõi có điều kiện: hệ thống lên lịch theo kênh được phép, nhận kết quả và cập nhật trạng thái. Mọi hành động gửi vẫn do người hoặc cơ chế đã được doanh nghiệp phê duyệt thực hiện.

Workflow sáu bước cho Sale bảo hiểm có chống trùng, nguồn phiên bản và tư vấn viên duyệt
Workflow minh họa: Agent điều phối trạng thái và bằng chứng; tư vấn viên duyệt trước follow-up.

Sai lầm, nhánh lỗi và điều kiện dừng

Nếu webhook tới hai lần, idempotency key trả kết quả cũ và không tạo task mới. Nếu CRM đã cập nhật nhưng lịch follow-up lỗi, transition đi ERROR_PARTIAL, giữ crm_write_id và cho phép replay riêng bước lịch; không chạy lại toàn bộ chuỗi. Nếu khóa owner thất bại do hai nhân viên cùng nhận, hệ thống giữ MERGE_REVIEW và quản lý phân công một người.

Nếu BEN-DEMO-v4 và TERMS-DEMO-v5 không cùng product_id hoặc hiệu lực, hệ thống không được “chọn bản mới hơn” theo tên file; nó mở SOURCE_REVIEW cho chủ tài liệu. Nếu câu hỏi của khách đòi kết luận quyền lợi cá nhân, Agent trả ESCALATE_ADVISOR và dẫn nguồn liên quan để tư vấn viên giải thích. Nếu consent bị rút, state chuyển STOPPED và mọi lịch chưa gửi bị hủy.

Điều kiện dừng cứng gồm thiếu định danh tối thiểu, source hết hạn, quyền lợi–điều khoản mâu thuẫn, thiếu advisor, dữ liệu nhạy cảm ngoài phạm vi, yêu cầu dự đoán chấp thuận hoặc hành động SEND không được cấp quyền. Dead-letter queue phải có owner, lý do, lần thử, thời hạn xử lý và nút hủy. Một lỗi không được biến mất chỉ vì workflow đã chạy sang bước sau.

Năm prompt vận hành workflow mà không thay tư vấn viên

Prompt 1 chuẩn hóa event envelope. Prompt 2 tạo danh sách candidate chống trùng. Prompt 3 lập needs packet chỉ từ lời khách. Prompt 4 kiểm bộ nguồn quyền lợi–điều khoản có phiên bản. Prompt 5 chẩn đoán lỗi và tạo replay plan. Chúng phục vụ orchestration, không xử lý phản đối, không đề xuất sản phẩm và không viết lời khẳng định về quyền lợi.

Mỗi prompt bên dưới có mục tiêu, biến đầu vào, định dạng trả về và ví dụ bảo hiểm riêng. Rule quan trọng là preserve_unknown=true: dữ liệu không có phải giữ UNKNOWN. Mọi đầu ra đều cần lead_id, evidence_ref, next_state, next_owner và forbidden_actions để reviewer nhìn thấy ranh giới ngay trên card duyệt.

Không đưa nguyên tài liệu khách hàng hoặc thông tin sức khỏe vào prompt minh họa. Khi triển khai thật, lớp truy xuất chỉ cấp trường tối thiểu theo vai trò. Prompt version được ghim trong transition log; thay prompt phải chạy lại bộ regression trước, vì cùng dữ liệu nhưng chỉ một thay đổi nhỏ trong hướng dẫn cũng có thể tạo state khác.

Công cụ và quyền truy cập tối thiểu

Một cấu hình dễ bắt đầu là MISA AMIS CRM hoặc HubSpot làm bản ghi chính, Google Sheets làm hàng đợi kiểm thử, Drive giữ source packet, Base.vn quản lý bước duyệt và n8n hoặc Make điều phối webhook. Zalo OA, email và điện thoại là adapter kênh, không phải nơi giữ truth. Mỗi adapter chỉ nhận payload đã được duyệt cho đúng consent.

Service account của Agent chỉ cần READ nguồn, CREATE_DRAFT trong CRM và CREATE_TASK. Quyền MERGE_LEAD, CHANGE_OWNER, SEND, DELETE và APPROVE không cấp trong pilot. Secret nằm trong vault; log không ghi raw token hay toàn bộ nội dung nhạy cảm. Retention của event, prompt input và output phải theo chính sách doanh nghiệp, không mặc định lưu vô hạn.

State machine lead bảo hiểm với các điểm review và nhánh lỗi
State machine minh họa tách trạng thái dữ liệu, nguồn, advisor review và lỗi từng phần.

AI làm gì và người duyệt quyết định gì

AI nhận biết cấu trúc, so khớp có bằng chứng, kiểm schema, nối source-id, tạo câu hỏi thiếu và đề xuất next_state. Nó có thể cảnh báo bảng quyền lợi hết hạn hoặc consent không phù hợp với kênh. Đó là hỗ trợ kiểm soát quy trình, không phải quyền diễn giải điều khoản cho một trường hợp cụ thể hay quyết định khách nên chọn phương án nào.

Tư vấn viên đọc lời khách trong ngữ cảnh, xác nhận nhu cầu, giải thích quyền lợi cùng giới hạn, chọn nội dung trao đổi và chịu trách nhiệm phê duyệt. Chủ sản phẩm xác nhận source packet; quản lý duyệt rule và KPI; khách hàng cấp hoặc rút consent; Data Protection hoặc vai trò tương ứng chỉ xác minh bằng chứng, ghi nhận và thực thi phạm vi cùng retention; IT quản quyền, webhook, retry và rollback. Không gộp những chữ ký này thành một nút “AI approved”.

Card duyệt tốt phải cho thấy bản nháp, dữ kiện gốc, UNKNOWN, nguồn cùng version, các thay đổi so với lần trước, consent, hành động tiếp theo và thời hạn. Nút APPROVE không xuất hiện khi blocker còn mở. Người duyệt có thể sửa, từ chối, yêu cầu bổ sung hoặc dừng; mọi lựa chọn đều có reason_code để cải thiện rule, không dùng ngầm làm nhãn suy đoán nhạy cảm.

Triển khai pilot và đo đúng hiệu quả

Tuần đầu dùng 30 lead DEMO đã ẩn danh, gồm event trùng, consent rút, source hết hạn và lỗi từng phần. Tuần hai chạy shadow mode trên dữ liệu được phép: Agent đề xuất state nhưng nhân viên vẫn làm quy trình cũ. So expected với actual, sửa rule và khóa danh sách trường. Chỉ khi lỗi dừng bằng không mới cho CREATE_TASK trong phạm vi hẹp.

Tuần ba mở cho hai tư vấn viên và một source packet cố định; không cấp SEND. Daily review xem duplicate precision, tỷ lệ UNKNOWN đúng, source coverage, số escalation hợp lệ, thời gian review và replay thành công. Tuần bốn mới cân nhắc adapter kênh đã phê duyệt, vẫn giữ advisor gate. Một lần phát tán sai nguồn hoặc liên hệ sau STOP_CONTACT là điều kiện rollback.

Đo thời gian từ event đến owner, số task trùng tránh được, tỷ lệ draft có đủ evidence, tỷ lệ reviewer sửa lớn, lỗi version và follow-up quá hạn. Không lấy số tin gửi hoặc tỷ lệ chốt làm chứng cứ trực tiếp rằng AI tư vấn tốt. Báo cáo phải tách dữ liệu minh họa với dữ liệu vận hành thật và ghi rõ thay đổi nào đến từ workflow, thay đổi nào từ đội ngũ.

Kết quả minh họa và câu hỏi thường gặp

Kết quả minh họa: lead DEMO-BH-018 có hai event WEB-91 và ZALO-22 được đưa MERGE_REVIEW; tư vấn viên xác nhận cùng người; needs packet giữ hai UNKNOWN; BEN-DEMO-v4 hợp lệ nhưng TERMS-DEMO-v5 thiếu effective_at nên SOURCE_REVIEW. Không có bản nháp follow-up được tạo cho tới khi chủ tài liệu bổ sung nguồn và advisor duyệt. Đây là dữ liệu minh họa, không phải kết quả kinh doanh thật.

Workflow có tự chọn sản phẩm cho khách không?

Không. Nó chuẩn hóa và điều phối bằng chứng; tư vấn viên mới là người trao đổi nhu cầu và nội dung theo quy trình được phê duyệt.

Lead candidate có bao giờ được tự động hợp nhất không?

Không. Identity service chỉ tạo candidate; mọi merge bắt buộc qua MERGE_REVIEW và do tư vấn viên hoặc Data Steward xác nhận. Quyết định phải có evidence, audit log và rollback key.

AI có được kết luận quyền lợi áp dụng không?

Không. Agent chỉ trích nguồn có version và chuyển câu hỏi cho advisor; không kết luận quyền lợi, chấp thuận hoặc bồi thường.

Consent bị rút giữa workflow thì xử lý thế nào?

Chuyển STOPPED, hủy lịch chưa gửi, ghi lý do và chỉ giữ dữ liệu theo retention hợp lệ. Không tạo follow-up mới.

Xem bản đồ AI cho Sale bảo hiểm, dùng prompt pack có dẫn nguồn, mở cụm nghề Sale bảo hiểm hoặc liên hệ NganAds.

Workflow

  1. Bước 1: Tiếp nhận có kiểm dịch — Ghi event vào QUARANTINE, che dữ liệu thừa và kiểm schema.
  2. Bước 2: Identity candidate và MERGE_REVIEW — Dùng idempotency để chặn event lặp; chỉ tạo merge candidate, mọi merge do tư vấn viên hoặc Data Steward xác nhận với evidence, audit log và rollback key.
  3. Bước 3: Lập needs packet — Tách facts, UNKNOWN và câu hỏi mà không suy luận dữ liệu nhạy cảm.
  4. Bước 4: Kiểm source packet — Xác minh BEN, TERMS, FEE theo version và dừng khi mâu thuẫn.
  5. Bước 5: Tư vấn viên duyệt — Advisor xác nhận nhu cầu, nguồn, bản nháp; chỉ xác minh và thực thi phạm vi consent do khách cấp/rút.
  6. Bước 6: Follow-up có điều kiện — Tạo DRAFT/task trong phạm vi consent khách đã cấp; STOP khi khách rút, ghi kết quả và replay riêng bước lỗi.

Prompt mẫu

Chuẩn hóa event envelope

MỤC TIÊU: Chuyển một sự kiện lead thành envelope kiểm được mà không suy đoán.
[ĐẦU VÀO]: raw_event, channel, occurred_at, consent_scope, schema và trường cấm suy luận.
ĐỊNH DẠNG ĐẦU RA: JSON event_id, normalized_fields, evidence_ref, missing_fields, ingest_status, next_state; giữ UNKNOWN.
VÍ DỤ ĐIỀN SẴN: WEB-91; kênh website; khách nói tìm hiểu bảo vệ gia đình; chưa có thời hạn; consent chỉ cho tư vấn một lần; next_state=NORMALIZED.

Tạo candidate chống trùng

MỤC TIÊU: Tìm lead có khả năng trùng nhưng không tự hợp nhất khi bằng chứng yếu.
[ĐẦU VÀO]: event envelope, lead index, khóa định danh, ngưỡng rule và owner hiện tại.
ĐỊNH DẠNG ĐẦU RA: Bảng candidate_id, exact_keys, weak_signals, conflicts, confidence_rule, action và reviewer.
VÍ DỤ ĐIỀN SẴN: WEB-91 và ZALO-22 cùng phone_hash, khác channel, cùng consent purpose; action=MERGE_REVIEW; advisor xác nhận.

Lập needs packet không suy diễn

MỤC TIÊU: Tách điều khách tự nói khỏi khoảng trống cần tư vấn viên làm rõ.
[ĐẦU VÀO]: Hội thoại đã ẩn, lead_id, danh sách trường nhu cầu và sensitive_fields.
ĐỊNH DẠNG ĐẦU RA: facts có quote_ref, UNKNOWN, clarification_questions, removed_fields, status và next_owner.
VÍ DỤ ĐIỀN SẴN: Khách nói muốn bảo vệ gia đình; người được bảo vệ, thời hạn và mức phí đều UNKNOWN; không suy đoán sức khỏe.

Kiểm source packet có phiên bản

MỤC TIÊU: Kiểm bộ quyền lợi–điều khoản trước khi advisor review.
[ĐẦU VÀO]: product_id, BEN source, TERMS source, FEE source, effective_at, expires_at, owner và allowed_use.
ĐỊNH DẠNG ĐẦU RA: Bảng source_id, version, validity, conflicts, missing_fields, READY/REVIEW/BLOCKED và escalation_owner.
VÍ DỤ ĐIỀN SẴN: BEN-DEMO-v4 hợp lệ; TERMS-DEMO-v5 thiếu effective_at; status=SOURCE_REVIEW; không tạo nội dung.

Chẩn đoán lỗi và lập replay plan

MỤC TIÊU: Khôi phục đúng bước lỗi mà không nhân đôi tác vụ.
[ĐẦU VÀO]: lead_id, transition log, idempotency_key, completed_writes, error, retry_count và stop rules.
ĐỊNH DẠNG ĐẦU RA: root_cause, safe_to_retry, replay_step, preserved_ids, rollback, owner và deadline.
VÍ DỤ ĐIỀN SẴN: CRM write BH-771 đã xong, tạo lịch lỗi timeout; replay chỉ calendar_step với cùng key; không ghi lại CRM.

Câu hỏi thường gặp

Workflow có tự chọn sản phẩm cho khách không?

Không. Nó chuẩn hóa và điều phối bằng chứng; tư vấn viên mới là người trao đổi nhu cầu và nội dung theo quy trình được phê duyệt.

Lead candidate có bao giờ được tự động hợp nhất không?

Không. Identity service chỉ tạo candidate; mọi merge bắt buộc qua MERGE_REVIEW và do tư vấn viên hoặc Data Steward xác nhận. Quyết định phải có evidence, audit log và rollback key.

AI có được kết luận quyền lợi áp dụng không?

Không. Agent chỉ trích nguồn có version và chuyển câu hỏi cho advisor; không kết luận quyền lợi, chấp thuận hoặc bồi thường.

Consent bị rút giữa workflow thì xử lý thế nào?

Chuyển STOPPED, hủy lịch chưa gửi, ghi lý do và chỉ giữ dữ liệu theo retention hợp lệ. Không tạo follow-up mới.

Bài liên quan

Muốn cài AI Agent cá nhân 499K (support 7 ngày)? Inbox / Zalo 0983543063.