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

AI Agent cho quản lý CRM: schema, quyền và dữ liệu

AI Agent cho Quản lý CRM: schema, danh tính, consent và quyền ghi

Thuật ngữ: Schema là cấu trúc trường dữ liệu; identity resolution là đối sánh danh tính; consent là sự đồng ý theo mục đích và kênh; routing là định tuyến tới đúng người; proposal patch là bản vá đề xuất chưa được ghi.

Tình huống thật khi một khách có nhiều hồ sơ

AI Agent cho Quản lý CRM thường được kỳ vọng “dọn sạch data”, nhưng một hồ sơ không chỉ là tên và số điện thoại. Một khách có thể điền form bằng email công ty, nhắn Zalo bằng số cá nhân, mua tại cửa hàng dưới số người thân và yêu cầu ngừng quảng cáo ở một kênh. Gộp tất cả vì tên gần giống có thể làm sai consent, lịch sử giao dịch và owner.

Quản lý CRM cần biết nguồn nào tạo field, mục đích sử dụng, độ tin cậy, thời hạn lưu và ai được sửa. AI phù hợp để phát hiện thiếu schema, tạo candidate duplicate, mô tả xung đột, chuẩn bị routing simulation và báo cáo ngoại lệ. Nó không phải chủ dữ liệu và không được tự merge, xóa, đổi owner hay bật quyền liên hệ.

Bài này là bản đồ nghề: chọn use case nào đáng thử và khóa ranh giới nào trước khi kết nối. Bài workflow cùng cụm đi vào state machine ghi dữ liệu; bài prompt tập trung schema drift, duplicate packet, lineage, routing simulation và quality report. Ba intent tách nhau để không biến một công cụ dọn data thành hệ thống tự sửa CRM.

Việc giao cho AI và quyết định giữ cho con người

AI có thể kiểm field bắt buộc, chuẩn hóa định dạng ngày hoặc mã tỉnh trên bản sao, so sánh record với schema registry, liệt kê candidate duplicate và tạo diff. Nó cũng có thể gom thống kê completeness theo source, phát hiện giá trị ngoài enum, map field cũ sang field mới ở chế độ proposal và lập phiếu cho data steward.

Nhóm cần duyệt gồm merge/split danh tính, sửa consent, đổi lifecycle stage, chuyển owner, thay attribution source và xóa dữ liệu. Mỗi đề xuất cần record_ids, matched keys, conflicting facts, lineage, confidence cùng rollback plan. Data steward kiểm; owner nghiệp vụ xác nhận nghĩa field; privacy owner xử lý consent và retention.

AI không được suy ra giới tính, thu nhập, khả năng mua hoặc độ uy tín từ nội dung tự do; không dùng sentiment để hạ ưu tiên; không nối dữ liệu cá nhân ngoài purpose. Nếu identifier không đủ, nguồn mâu thuẫn hoặc field không có owner, output phải `REVIEW` hay `BLOCKED`, không cố tạo “golden record”.

Dữ liệu cần chuẩn bị cho quản trị CRM

Schema registry cần entity, field_name, datatype, allowed_values, nullable, business_definition, source_of_truth, field_owner và effective_version. Identity policy định nghĩa deterministic key, fuzzy signal chỉ dùng làm candidate, ngưỡng review, quy tắc household và trường không được dùng để gộp. Không lấy tên tương tự làm khóa duy nhất.

Consent ledger ghi subject_ref, channel, purpose, status, captured_at, source, evidence_ref, expires_at và revoked_at. Lifecycle dictionary định nghĩa stage, entry criteria, exit criteria, owner và event tạo chuyển đổi. Attribution policy nêu source event, lookback, manual override và người duyệt để tránh AI đổi nguồn vì một tương tác muộn.

Data lineage nối field đến form, import, webhook hoặc thao tác người dùng; audit log ghi before, after, actor, reason, approval và correlation_id. Bộ test dùng record DEMO cho trùng thật, trùng giả, shared phone, đổi email, consent rút, schema version lệch, owner nghỉ việc và import rollback. Mỗi ca có expected proposal, prohibited write cùng reviewer.

Workflow sáu bước chọn tác vụ CRM phù hợp

Bước 1 — Kiểm kê data jobs: tách kiểm schema, duplicate review, lineage, routing và reporting thành use case riêng. Bước 2 — Gắn source of truth: mỗi field có owner, purpose, version và proof; field vô chủ nhận `NEEDS_GOVERNANCE`.

Bước 3 — Chấm rủi ro ghi: READ/ANALYZE thấp hơn PROPOSE_PATCH; MERGE, CONSENT_EDIT, DELETE và OWNER_CHANGE là human-only mặc định. Bước 4 — Tạo evaluation set: dùng ca biên về shared identifier, consent và schema drift, đo false candidate chứ không chỉ completeness.

Bước 5 — Chạy shadow mode: AI tạo proposal không ghi; steward so sánh với quyết định thật và ghi reason. Bước 6 — Duyệt pilot charter: CRM owner, data steward, privacy và IT khóa scope, metric, stop condition, rollback. Dừng nếu có write chưa duyệt, consent bị đảo, record gộp sai hoặc log thiếu.

Sơ đồ chọn use case AI quản lý CRM theo schema, nguồn, quyền ghi và reviewer — Workflow minh họa chọn pilot bắt đầu ở READ và PROPOSE, trước các hành động merge hoặc sửa consent.

Năm prompt thiết kế bản đồ quản trị CRM

Prompt 1 lập schema inventory; Prompt 2 chấm identity risk; Prompt 3 vẽ consent lineage; Prompt 4 lập permission boundary; Prompt 5 tạo scorecard use case. Chúng phục vụ quyết định kiến trúc, không tạo tin chăm sóc khách và không tự chuẩn hóa dữ liệu production.

Mỗi prompt yêu cầu đầu vào có version và owner. Output dùng trạng thái `READY`, `NEEDS_WORK`, `REVIEW` hoặc `BLOCKED`; điểm số luôn kèm lý do. Ví dụ phải dùng record DEMO. Nếu không biết field là hệ nguồn hay bản sao, AI ghi unknown thay vì suy đoán từ tên cột.

Đội có thể copy prompt để workshop giữa Sales Ops, CRM owner và privacy. Người điều phối xác nhận định nghĩa trước khi chấm. Không dùng output của model như chính sách chính thức; chính sách sau duyệt cần được ghi trong registry có effective_at và changelog.

Công cụ phù hợp theo lớp dữ liệu

MISA AMIS CRM, Getfly, HubSpot hoặc CRM nội bộ giữ entity và state; Sapo/KiotViet cung cấp giao dịch theo quyền; Zalo OA và form website là event sources. BigQuery hoặc kho dữ liệu có thể giữ snapshot phân tích; Google Sheets phù hợp cho data dictionary nhỏ và test case, nhưng không phải master cho consent.

dbt hoặc công cụ ETL quản transformation; n8n/Make có thể điều phối event nếu được khóa credential, retry và idempotency. Base.vn/Notion hỗ trợ ticket duyệt; Git hoặc document registry giữ version schema/prompt. Dù dùng công cụ nào, service account chỉ đọc view tối thiểu và ghi proposal table.

Ma trận dữ liệu CRM gồm schema, nguồn, consent, quyền và chủ sở hữu — Ma trận minh họa buộc mỗi field có nghĩa nghiệp vụ, nguồn, purpose và người chịu trách nhiệm.

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

AI phát hiện schema drift, tạo duplicate candidate, mô tả xung đột, kiểm lineage, mô phỏng routing và tổng hợp ngoại lệ. Nó không xác định danh tính thật khi evidence không đủ, không biến dữ liệu suy ra thành fact, không sửa consent hoặc tạo điểm khách hàng để quyết định quyền lợi.

Data steward duyệt merge/split và patch; CRM owner duyệt lifecycle, routing cùng owner assignment; privacy owner duyệt purpose, consent, retention và xóa; Sales/CSKH xác nhận nghĩa sử dụng; IT quản credential, connector, audit và rollback. Quyết định cần actor cụ thể, không ghi chung “đã được team duyệt”.

Màn review phải hiển thị before/after, matched keys, conflict, source lineage, tác động downstream và nút reject. Với batch, reviewer chọn từng record hoặc policy-approved rule; không có “approve all” cho consent/identity. AI học từ reason code ở chu kỳ sau, nhưng không tự thay policy dựa trên phản hồi.

Sai lầm và rủi ro cần tránh

Sai lầm lớn là xem số điện thoại như danh tính vĩnh viễn; số có thể dùng chung hoặc tái cấp. Sai lầm khác là tự gộp theo similarity, ghi đè raw source, sửa trực tiếp khi schema drift, suy ra consent từ việc khách từng mua và đổi owner mà không kiểm account plan.

Rủi ro lan truyền khi một patch sai được đồng bộ tới marketing, CSKH, báo cáo và tài chính. Vì vậy proposal cần impact list, transaction boundary và rollback key. Import phải có batch_id; update phải có expected_version; conflict thì dừng thay vì last-write-wins.

Không đo “data sạch” bằng tỷ lệ field được điền nếu AI có thể tự bịa. Đo completeness có nguồn, false merge candidate, unresolved conflict, consent mismatch, reviewer correction và rollback success. Một merge sai hoặc consent write chưa duyệt là stop condition; không chờ đủ mẫu thống kê.

Triển khai cho đội nhỏ và doanh nghiệp

Đội nhỏ bắt đầu bằng schema lint trên file export đã giảm định danh, chỉ phát hiện lỗi định dạng và field ngoài enum. Sau đó thử duplicate candidate trên dữ liệu DEMO, mỗi candidate được steward duyệt. Không ghi vào CRM cho tới khi shadow mode ổn định và rollback được diễn tập.

Doanh nghiệp tạo schema registry, identity policy, consent ledger, event contract, proposal store và audit log. Tách worker đọc khỏi worker ghi; write worker chỉ nhận approval token có scope, expiry và expected_version. Mọi batch có dry-run summary trước khi reviewer duyệt.

Lộ trình bốn tuần có thể gồm: tuần 1 định nghĩa, tuần 2 test set, tuần 3 shadow, tuần 4 limited write cho field rủi ro thấp. Đây là khung minh họa, không phải cam kết thời gian. Mở rộng dựa trên error budget và bằng chứng, không dựa trên số record xử lý nhanh.

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

Dữ liệu minh họa: use case `CRM-MAP-DEMO-06` là schema lint cho `company_size_band`. AI phát hiện 12 giá trị ngoài enum trong batch DEMO, tạo proposal map cho 8, đưa 4 vào `NEEDS_OWNER`, không ghi production. Quyền `READ_EXPORT` và `CREATE_PROPOSAL`; `MERGE`, `CONSENT_EDIT`, `DELETE` bị cấm. CRM owner duyệt pilot, data steward review từng patch.

Nên bắt đầu AI trong CRM từ đâu?

Từ schema lint hoặc báo cáo ngoại lệ trên bản sao đã giảm định danh; đầu ra dễ kiểm và chưa làm thay đổi hồ sơ.

AI có được tự gộp khách trùng không?

Không. AI tạo candidate cùng evidence; data steward quyết định merge hoặc split theo identity policy.

Consent có thể suy ra từ giao dịch không?

Không. Consent cần purpose, kênh và evidence riêng; mua hàng không mặc nhiên cho phép mọi liên hệ.

Khi nào dừng pilot?

Dừng ngay khi có write chưa duyệt, merge sai, consent bị đổi, dữ liệu vượt purpose hoặc không thể rollback theo batch.

Tiếp tục với workflow quản trị CRM, dùng bộ prompt CRM hoặc liên hệ NganAds qua Zalo 0983543063 để thiết kế pilot có lineage và rollback.

Workflow

Bước 1: Kiểm kê data jobs — Tách schema, identity, consent, routing và reporting thành use case có output riêng.
Bước 2: Gắn source và owner — Mỗi field có định nghĩa, source of truth, purpose, version và người chịu trách nhiệm.
Bước 3: Chấm rủi ro quyền — Ưu tiên READ/PROPOSE; merge, consent, delete và owner change giữ human-only.
Bước 4: Tạo evaluation set — Dùng dữ liệu DEMO cho shared key, trùng giả, consent rút và schema drift.
Bước 5: Chạy shadow mode — AI chỉ tạo proposal; steward đối chiếu và ghi reason code cho từng quyết định.
Bước 6: Duyệt pilot charter — CRM, data, privacy và IT khóa metric, stop condition, quyền cùng rollback.

Prompt mẫu

Lập schema inventory

MỤC TIÊU: Kiểm kê field CRM theo nghĩa nghiệp vụ, kiểu dữ liệu và nguồn sự thật.
[ĐẦU VÀO]: [ENTITY, FIELD_LIST, SAMPLE_DEMO, CURRENT_SCHEMA, SYSTEM_SOURCES].
RÀNG BUỘC: Không tự định nghĩa field; thiếu owner hoặc source ghi NEEDS_GOVERNANCE.
ĐỊNH DẠNG ĐẦU RA: field | datatype | allowed_values | definition | source_of_truth | owner | gap.
VÍ DỤ ĐIỀN SẴN: company_size_band; enum; CRM owner; hai giá trị ngoài enum cần review.

Chấm identity risk

MỤC TIÊU: Đánh giá khóa danh tính và nguy cơ merge sai trước pilot.
[ĐẦU VÀO]: [IDENTITY_POLICY, IDENTIFIERS, SHARED_KEY_CASES, DUPLICATE_SAMPLES].
YÊU CẦU: Similarity chỉ tạo candidate; không coi phone hoặc name là khóa tuyệt đối.
ĐỊNH DẠNG ĐẦU RA: key | strength | collision_case | allowed_use | reviewer | prohibited_action.
VÍ DỤ ĐIỀN SẴN: shared_phone có collision cao; chỉ dùng candidate; MERGE bị cấm.

Vẽ consent lineage

MỤC TIÊU: Nối consent với purpose, kênh, evidence và hệ thống sử dụng.
[ĐẦU VÀO]: [CONSENT_LEDGER, SOURCE_EVENTS, PURPOSES, DOWNSTREAM_SYSTEMS, RETENTION].
CẤM: Không suy consent từ giao dịch; trạng thái không có evidence ghi BLOCKED.
ĐỊNH DẠNG ĐẦU RA: subject_ref | channel | purpose | status | evidence_ref | consumers | expiry | gaps.
VÍ DỤ ĐIỀN SẴN: C-DEMO-08 rút Zalo marketing; CSKH giao dịch vẫn theo purpose riêng.

Lập permission boundary CRM

MỤC TIÊU: Tách READ, ANALYZE, PROPOSE, APPROVE và WRITE theo entity/field.
[ĐẦU VÀO]: [ROLES, ENTITIES, FIELDS, ACTIONS, RISK_CLASS, AUDIT_REQUIREMENTS].
YÊU CẦU: AI không MERGE, CONSENT_EDIT, DELETE hoặc OWNER_CHANGE; quyền có expiry.
ĐỊNH DẠNG ĐẦU RA: role-resource-action | allow/deny | approval | expiry | log | rollback.
VÍ DỤ ĐIỀN SẴN: agent đọc export và tạo proposal; steward duyệt patch; privacy duyệt consent.

Tạo scorecard use case CRM

MỤC TIÊU: Chọn use case CRM có dữ liệu, khả năng kiểm và rollback phù hợp.
[ĐẦU VÀO]: [JOB_INVENTORY, SCHEMA_REGISTRY, IDENTITY_POLICY, PERMISSION_MATRIX, TEST_SET].
RÀNG BUỘC: Điểm không thay reviewer; thiếu source, owner hoặc rollback trả BLOCKED.
ĐỊNH DẠNG ĐẦU RA: use_case | value | data_readiness | risk | verify | rollback | decision | reason.
VÍ DỤ ĐIỀN SẴN: schema lint → PILOT; tự merge duplicate → REJECT.

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

Nên bắt đầu AI trong CRM từ đâu?

Từ schema lint hoặc báo cáo ngoại lệ trên bản sao đã giảm định danh; đầu ra dễ kiểm và chưa làm thay đổi hồ sơ.

AI có được tự gộp khách trùng không?

Không. AI tạo candidate cùng evidence; data steward quyết định merge hoặc split theo identity policy.

Consent có thể suy ra từ giao dịch không?

Không. Consent cần purpose, kênh và evidence riêng; mua hàng không mặc nhiên cho phép mọi liên hệ.

Khi nào dừng pilot?

Dừng ngay khi có write chưa duyệt, merge sai, consent bị đổi, dữ liệu vượt purpose hoặc không thể rollback theo batch.

Bài liên quan

Bắt đầu bằng schema lint trên bản sao đã giảm định danh; mọi sửa đổi CRM ở proposal store và chờ đúng data owner duyệt.