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

Workflow AI quản lý CRM: từ event đến bản ghi duyệt

Workflow quản trị CRM: từ source event đến bản ghi được duyệt

Thuật ngữ: Source event là sự kiện nguồn bất biến; schema validation là kiểm cấu trúc dữ liệu; identity candidate là hồ sơ có khả năng trùng; routing là định tuyến; write approval là phê duyệt trước khi ghi.

Tình huống thật khi form mới làm lệch CRM

Workflow AI cho Quản lý CRM cần xử lý nguồn và schema trước khi nghĩ đến follow-up. Marketing thêm trường “quy mô” vào landing page dưới dạng văn bản tự do, trong khi CRM dùng enum. Zalo OA và Sapo đồng thời đổ form vào CRM lúc nhân viên đang chốt đơn; một đợt import vừa tạo giá trị mới, vừa tạo record trùng theo email, vừa gán owner mặc định. Nếu automation ghi thẳng, báo cáo pipeline và consent downstream có thể sai trước khi ai nhận ra.

Workflow an toàn giữ source event bất biến, validate theo schema version, tạo candidate chứ không merge, mô phỏng routing và chuẩn bị patch. Con người duyệt identity, consent, lifecycle và owner. Write worker chỉ chạy khi nhận approval token đúng scope và expected_version. Mỗi thay đổi có batch_id để rollback.

Bài này không hướng dẫn AI viết tin bán hàng. “Follow-up” trong ngữ cảnh quản lý CRM là bảo đảm record có trạng thái, owner và next_action đúng theo policy; nội dung liên hệ thuộc workflow bán hàng riêng. Mục tiêu ở đây là tính toàn vẹn của dữ liệu và khả năng truy nguyên.

Việc giao cho AI trong pipeline CRM

AI có thể đọc event đã giảm định danh, map field theo registry, phát hiện unknown field, chuẩn hóa candidate value, gắn validation error và mô tả schema drift. Nó tìm duplicate candidate bằng deterministic keys trước, fuzzy signals sau, nhưng không biến similarity thành quyết định merge.

AI có thể mô phỏng routing theo territory, segment, capacity và lifecycle rule đã duyệt; output là owner_candidate với rule_id. Nó tạo patch proposal gồm before, after, source, confidence, downstream impact và rollback key. Nó cũng tổng hợp batch report theo lỗi, không chấm giá trị con người hay khả năng mua.

Con người giữ quyền merge/split, consent update, lifecycle transition, owner assignment, delete và write production. Khi event thiếu evidence, schema version không khớp, record đã đổi sau lúc đọc hoặc approval hết hạn, hệ thống dừng. Không dùng last-write-wins để che conflict.

Dữ liệu cần chuẩn bị cho từng cổng

Event contract gồm event_id, source, occurred_at, received_at, entity_type, payload_version, purpose, consent_ref và checksum. Schema registry có field, datatype, enum, nullable, definition, owner cùng effective version. Raw event chỉ đọc; normalized staging giữ transform log và không ghi đè payload gốc.

Identity policy nêu match keys, collision cases, review threshold và rule household. Routing table có rule_id, priority, condition, target role, capacity source, effective_at và fallback. Write policy chỉ rõ field nào được patch, ai approve, expected_version, transaction boundary và rollback method.

Chuẩn bị evaluation set cho event trùng, event đến muộn, field lạ, enum sai, shared phone, email đổi, consent rút, record concurrent update, owner unavailable và partial write. Mỗi ca có expected gate và prohibited actions. Dữ liệu minh họa dùng `EVT-DEMO`, `REC-DEMO`; không dùng export khách thật trong tài liệu.

Workflow bảy bước có Human-in-the-loop

Bước 1 — Ingest: xác minh source, checksum và event_id; trùng key thì trả trạng thái đã xử lý. Bước 2 — Validate schema: kiểm payload_version, type, enum và required fields; drift vào quarantine, không cố map theo tên gần giống.

Bước 3 — Identity candidate: tìm exact match, sau đó tạo fuzzy candidate có evidence. Không đủ bằng chứng thì `NEW_OR_REVIEW`; chỉ steward merge. Bước 4 — Consent/lifecycle gate: kiểm purpose, ledger và transition criteria; conflict chuyển privacy hoặc CRM owner.

Bước 5 — Routing simulation: chạy rule theo effective_at, trả target và lý do; owner unavailable dùng fallback đã định nghĩa. Bước 6 — Approval và write: reviewer xem diff, downstream impact, cấp token; worker kiểm expected_version rồi patch idempotent. Bước 7 — Audit/reconcile: so target proof với proposal, tạo batch summary và rollback nếu partial. Dừng ngay khi merge sai, consent mismatch, unauthorized write hoặc không truy được before state.

Workflow CRM bảy bước từ source event đến approval, write và audit — Sơ đồ minh họa các cổng schema, identity, consent, routing và write; mỗi cổng có nhánh quarantine hoặc review.

Năm prompt phục vụ từng cổng workflow

Prompt 1 phân tích schema drift; Prompt 2 tạo duplicate evidence packet; Prompt 3 lập field lineage; Prompt 4 mô phỏng routing; Prompt 5 tổng hợp quality exceptions. Không prompt nào viết lời chăm sóc khách, thay owner hoặc phát lệnh ghi. Output là artifact cho reviewer hoặc worker xác định.

Mỗi prompt nhận version, policy và dữ liệu DEMO; nếu thiếu, trả `BLOCKED_INPUT`. Cấu trúc đầu ra có source refs, unknowns và reviewer role. Prompt không tự bịa mapping cho field lạ. Chỉ registry owner phê duyệt map mới và ghi effective_at.

Prompt trong `promptPack` có thể chạy độc lập ở shadow mode. Kết quả được so với expected fixture, không với cảm giác “có vẻ đúng”. Khi prompt version đổi, chạy lại toàn bộ ca shared identifier, consent và concurrent update trước khi đưa vào pipeline.

Công cụ và kiến trúc triển khai

CRM có thể là MISA AMIS, Getfly, HubSpot hoặc hệ nội bộ. Form/Zalo OA tạo event; n8n, Make hay service riêng điều phối; BigQuery/PostgreSQL giữ staging và audit theo thiết kế. Google Sheets chỉ phù hợp làm bảng rule nhỏ có quyền chặt, không làm transaction log hay consent ledger.

Tách service account read, proposal và write. Write worker không có prompt và không tự quyết định; nó nhận patch đã ký, kiểm scope, expiry, expected_version cùng idempotency key. Queue lỗi có dead-letter, retry giới hạn và operator. Secret nằm trong vault, không trong Sheet hoặc prompt.

UI duyệt patch CRM hiển thị before, after, lineage, impact và rollback — UI minh họa review một patch CRM: người duyệt thấy diff và tác động trước khi cấp token ghi.

AI làm gì và người duyệt chịu trách nhiệm gì

AI validate, phân nhóm lỗi, tạo candidate, giải thích rule match, mô phỏng routing và soạn patch proposal. Nó không chứng minh danh tính thật, không suy consent, không sửa record để tăng completeness và không chọn owner dựa trên nhận xét chủ quan.

Data steward duyệt identity và patch; CRM owner duyệt stage/routing; privacy owner xử lý consent; sales operations xác nhận capacity; IT vận hành connector và rollback. Approval token phải gắn đúng proposal hash. Một phê duyệt qua chat không đủ nếu không được liên kết vào audit.

Sau write, hệ thống reconcile target version và field values. Reviewer không chỉ xem “thành công”; họ xem record nào bỏ qua, conflict nào phát sinh và downstream nào chưa đồng bộ. Nếu batch partial, dừng batch tiếp, cô lập record đã ghi và rollback theo policy.

Sai lầm và nhánh lỗi cần thiết kế trước

Lỗi phổ biến là map field lạ bằng tên gần giống, dùng phone làm unique key, coi consent trống là đồng ý, route theo owner cũ và retry update không có expected_version. Các lỗi này thường không tạo exception kỹ thuật nhưng làm dữ liệu sai âm thầm.

Nhánh quarantine xử lý schema/payload không hợp lệ; identity review xử lý candidate mơ hồ; privacy review xử lý consent; conflict queue xử lý concurrent update; dead-letter xử lý connector. Mỗi queue có owner, SLA nội bộ và replay rule. Không replay nếu raw event hoặc target state đã đổi mà chưa tạo proposal mới.

Circuit breaker bật khi schema drift tăng, candidate merge bị từ chối liên tiếp, write conflict vượt ngưỡng vận hành hoặc audit proof thiếu. Một unauthorized write, consent đảo hoặc record gộp sai dừng ngay. Log và raw event được giữ theo retention để phân tích; không xóa dấu vết bằng một import “sửa lại”.

Triển khai theo wave cho đội CRM

Wave 1 chỉ ingest và schema report trên export DEMO. Wave 2 tạo identity candidates và routing simulation trong shadow mode. Wave 3 cho phép patch field rủi ro thấp như normalized enum sau approval từng record. Merge, consent, delete và owner change tiếp tục human-only cho tới khi có quy trình riêng được duyệt.

Acceptance test kiểm idempotency, late event, version conflict, rollback, quyền và audit. Người nghiệp vụ duyệt expected result trước khi chạy. Đo event validity, proposal acceptance theo reason, false candidate, conflict rate, batch reconcile và rollback time. Mọi tỷ lệ từ test phải ghi dữ liệu minh họa.

Khi mở rộng, giới hạn batch, đặt canary source và theo dõi downstream. Đừng mở đồng thời nguồn mới, schema mới và quyền write mới vì sẽ khó truy nguyên. Mỗi thay đổi có change ticket, owner, start/end, rollback trigger và review sau wave.

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

Dữ liệu minh họa: event `EVT-DEMO-204` từ form v3 có `company_size_text=11-50`. Schema v5 yêu cầu enum `SMALL_11_50`; AI tạo proposal P-18, lineage FORM-3 → CRM.company_size_band và routing candidate `SMB_NORTH`. Steward duyệt mapping, CRM owner duyệt routing; write token hết hạn sau mười phút. Worker patch record `REC-DEMO-44` ở expected_version 7 và reconcile version 8.

Tại sao AI không ghi thẳng vào CRM?

Vì identity, consent, lifecycle và owner có tác động downstream; proposal cùng approval giúp kiểm diff và rollback.

Event đến hai lần thì sao?

Dùng event_id/idempotency key. Lần sau trả trạng thái đã xử lý, không tạo record hoặc patch mới.

Record đổi trong lúc chờ duyệt thì sao?

Expected_version không còn khớp nên write dừng; hệ thống tạo proposal mới từ trạng thái hiện tại.

Có thể tự động route owner không?

Chỉ sau khi rule, capacity source và fallback được duyệt; giai đoạn đầu AI mô phỏng và CRM owner xác nhận.

Xem bản đồ quản lý CRM, dùng bộ prompt kiểm dữ liệu hoặc liên hệ NganAds qua Zalo 0983543063 để thiết kế state machine phù hợp CRM hiện có.

Workflow

Bước 1: Nhận source event — Xác minh source, checksum và idempotency; raw event được giữ bất biến.
Bước 2: Kiểm schema — Validate version, type, enum và required field; drift vào quarantine.
Bước 3: Tạo identity candidate — Dùng exact keys rồi fuzzy signals; steward quyết định merge hoặc split.
Bước 4: Kiểm consent và lifecycle — Đối chiếu purpose, ledger và transition; conflict chuyển đúng reviewer.
Bước 5: Mô phỏng routing — Áp rule có effective_at và capacity; trả candidate cùng lý do, chưa đổi owner.
Bước 6: Duyệt và ghi — Reviewer cấp token theo proposal; worker kiểm expected_version và patch idempotent.
Bước 7: Audit và reconcile — So target proof, tổng hợp batch và rollback nếu partial hoặc sai quyền.

Prompt mẫu

Phân tích schema drift

MỤC TIÊU: So sánh source event với schema registry và phân loại drift.
[ĐẦU VÀO]: [EVENT_PAYLOAD, PAYLOAD_VERSION, SCHEMA_VERSION, FIELD_REGISTRY].
RÀNG BUỘC: Không tự map field lạ; nêu source và owner; thiếu version trả BLOCKED_INPUT.
ĐỊNH DẠNG ĐẦU RA: valid_fields, unknown_fields, type_errors, enum_errors, proposed_questions, gate_status.
VÍ DỤ ĐIỀN SẴN: EVT-DEMO-204 có company_size_text; schema cần enum; QUARANTINE_MAPPING_REVIEW.

Tạo duplicate evidence packet

MỤC TIÊU: Chuẩn bị bằng chứng để steward quyết định new, link, merge hoặc split.
[ĐẦU VÀO]: [NEW_RECORD, CANDIDATES, IDENTITY_POLICY, SOURCE_LINEAGE].
CẤM: Không tự merge; fuzzy match không được mô tả là danh tính đã xác minh.
ĐỊNH DẠNG ĐẦU RA: candidate_id | exact_keys | fuzzy_signals | conflicts | collision_risk | reviewer_question.
VÍ DỤ ĐIỀN SẴN: shared phone nhưng email khác; collision_risk HIGH; recommendation REVIEW_SPLIT.

Lập field lineage

MỤC TIÊU: Theo dấu field từ source event qua transform tới CRM và downstream.
[ĐẦU VÀO]: [FIELD, SOURCE_EVENT, TRANSFORM_RULES, TARGET_SCHEMA, DOWNSTREAM_MAP].
YÊU CẦU: Không đoán transform thiếu; đánh dấu owner và effective version cho từng cạnh.
ĐỊNH DẠNG ĐẦU RA: lineage_nodes, transformations, owners, versions, consumers, unknown_edges.
VÍ DỤ ĐIỀN SẴN: FORM-3.company_size_text → MAP-12 → CRM.company_size_band → BI.segment.

Mô phỏng routing CRM

MỤC TIÊU: Tính owner candidate theo rule đã duyệt mà không thay owner.
[ĐẦU VÀO]: [NORMALIZED_RECORD, ROUTING_RULES, CAPACITY_VIEW, CURRENT_OWNER, EFFECTIVE_AT].
RÀNG BUỘC: Không dùng thuộc tính suy đoán; rule không khớp trả REVIEW_ROUTING.
ĐỊNH DẠNG ĐẦU RA: candidate_owner, matched_rule_id, facts_used, alternatives, conflicts, reviewer.
VÍ DỤ ĐIỀN SẴN: SMB_NORTH theo RULE-08; owner A đầy capacity nên fallback TEAM-N; CRM owner duyệt.

Tổng hợp quality exception

MỤC TIÊU: Tạo báo cáo batch theo loại lỗi, nguồn và owner khắc phục.
[ĐẦU VÀO]: [BATCH_ID, VALIDATION_RESULTS, REVIEW_DECISIONS, WRITE_RESULTS, RECONCILE_RESULTS].
YÊU CẦU: Nêu denominator; số test ghi dữ liệu minh họa; không chấm nhân viên.
ĐỊNH DẠNG ĐẦU RA: summary, exception_groups, source_breakdown, unresolved, stop_signals, owners.
VÍ DỤ ĐIỀN SẴN: B-DEMO-09 có 40 event; 3 schema drift, 2 identity review, 0 unauthorized write.

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

Tại sao AI không ghi thẳng vào CRM?

Vì identity, consent, lifecycle và owner có tác động downstream; proposal cùng approval giúp kiểm diff và rollback.

Event đến hai lần thì sao?

Dùng event_id hoặc idempotency key. Lần sau trả trạng thái đã xử lý, không tạo record hoặc patch mới.

Record đổi trong lúc chờ duyệt thì sao?

Expected_version không còn khớp nên write dừng; hệ thống tạo proposal mới từ trạng thái hiện tại.

Có thể tự động route owner không?

Chỉ sau khi rule, capacity source và fallback được duyệt; giai đoạn đầu AI mô phỏng và CRM owner xác nhận.

Bài liên quan

Chạy shadow mode từ event đến proposal; chỉ write sau khi reviewer xem diff, token đúng scope và rollback đã được diễn tập.