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

Workflow AI quản lý đại lý & CTV có kiểm duyệt

Workflow đại lý & CTV: từ đăng ký đến hoa hồng và tranh chấp

Thuật ngữ: State machine là sơ đồ trạng thái; referral ledger là sổ lượt giới thiệu bất biến; attribution là quy nguồn; reconcile là đối soát; payout là chi trả; dispute là hồ sơ tranh chấp.

Consent hai chủ thể: consent xử lý dữ liệu ứng viên/CTV cho xét duyệt, onboarding và quan hệ hợp đồng không phải consent của khách được giới thiệu để nhận liên hệ theo purpose/channel. Hai ledger phải tách evidence, revocation và retention. STOP_CONTACT của khách dừng giao tiếp ngay; event giới thiệu tối thiểu có thể còn trong ledger theo retention hợp lệ để đối soát, nhưng bị giới hạn quyền và không được dùng lại để nhắn.

Tình huống thật khi CTV gửi lead qua Zalo

Workflow đại lý và CTV không kết thúc ở việc ghi tên khách vào Sheet. Một CTV gửi lead qua Zalo lúc 9 giờ, đại lý khác nhập form lúc 10 giờ, khách mua trên KiotViet sau một tuần. Cả hai inbox yêu cầu attribution; một người có referral_id, người kia chỉ có ảnh chụp.

Workflow phải giữ từng event, áp policy theo thời điểm và đưa conflict cho người duyệt. Nó cũng cần biết hợp đồng nào có hiệu lực, role nào được xem dữ liệu, đơn có hoàn/hủy hay không và rate card nào dùng. AI chuẩn bị evidence và statement DRAFT; channel owner cùng finance quyết định.

Bài này thiết kế state machine xuyên suốt application → review → active → referral → attribution → commission → dispute. Không tự động tuyển ồ ạt, không gửi tin bán hàng và không thanh toán. Dữ liệu ví dụ đều là dữ liệu minh họa, không đại diện hiệu suất thật.

Một nguyên tắc quan trọng là không dùng cùng một trạng thái cho quan hệ đối tác, quyền truy cập và tiền. Đối tác có thể đang ACTIVE nhưng một quyền đã hết hạn; referral có thể APPROVED nhưng commission còn chờ điều kiện hoàn trả; statement đã duyệt vẫn chưa phải payout thành công. Ba state machine liên kết bằng reference giúp dừng đúng lớp, tránh khóa toàn bộ đối tác hoặc chi tiền chỉ vì một cờ chung bị cập nhật.

Việc giao cho AI ở từng trạng thái

Ở `APPLICATION_RECEIVED`, AI validate schema và tạo completeness checklist. Ở `LEGAL_REVIEW`, nó chỉ sắp xếp metadata/tài liệu và ngày hiệu lực; người có chuyên môn xác minh. Sau approval, AI tạo onboarding plan theo role, territory, catalog và policy version, nhưng channel owner mới kích hoạt account.

Ở `REFERRAL_REGISTERED`, AI kiểm event_id, partner_id, customer_ref, consent và evidence. Nó phát hiện conflict candidate, không tự gán nguồn. Ở `ATTRIBUTION_REVIEW`, AI chạy policy simulation, liệt kê eligible events, exclusions và policy clauses. Reviewer chọn kết quả cùng reason.

Ở `COMMISSION_DRAFT`, AI nối approved attribution với eligible order, return/cancel status và rate card để lập calculation trace. Finance review adjustment, thuế/khấu trừ theo trách nhiệm và payout readiness. Dispute tạo case riêng; AI tóm tắt claim/evidence, không tự đảo quyết định hay giữ tiền.

Dữ liệu cần chuẩn bị cho state machine

Application schema gồm application_id, partner_ref, role_requested, territory, channel, consent, document_refs và submitted_at. Contract registry có contract_id, version, effective_from/to, accepted_at, scope và owner. Access matrix nêu resource/action theo role, không cấp quyền bằng một cột `active=true`.

Referral ledger dùng referral_id bất biến, source_event_id, partner_id, customer_ref, occurred_at, campaign, evidence_ref và consent_scope. Order view từ Sapo/KiotViet có order_ref, eligible status, net basis, return/cancel cùng timestamps. Attribution policy/rate card có version và effective date.

Commission statement cần line_id, attribution_decision_ref, rate_card_id, calculation inputs, adjustment, reviewer và status. Payout proof ở hệ finance/MISA, không trong prompt. Dispute case gồm claim, disputed lines, evidence, SLA, owner, decision và appeal path. Test set phải có trùng event, rate đổi, refund và timeout.

Workflow bảy bước, nhánh lỗi và dừng

Bước 1 — Application intake: xác minh event, schema và consent; trùng application_id trả trạng thái cũ. Bước 2 — Completeness/legal review: AI lập checklist; legal/compliance và channel owner approve hoặc yêu cầu bổ sung. Thiếu evidence thì `NEEDS_DOCUMENT`.

Bước 3 — Onboarding/access: tạo plan, material version và access request; owner duyệt từng quyền, có expiry/revoke. Bước 4 — Referral registration: ghi ledger idempotent; thiếu consent/evidence vào review, không gán khách.

Bước 5 — Attribution review: simulation dùng policy effective_at; conflict tạo packet cho channel owner. Bước 6 — Commission/finance: tạo statement DRAFT, reconcile order, finance duyệt; payout worker riêng có dual approval/idempotency. Bước 7 — Dispute: mở case, khóa disputed line, thu evidence, người có thẩm quyền quyết định. Dừng ngay nếu AI kích hoạt, cấp quyền, override, điều chỉnh hoặc trả tiền.

Workflow đại lý CTV từ application đến onboarding referral attribution commission và dispute
Sơ đồ minh họa bảy bước và các cổng người duyệt trước quyền truy cập, attribution và tài chính.

Năm prompt hỗ trợ workflow đối tác

Prompt 1 kiểm application completeness; Prompt 2 tạo onboarding plan theo role; Prompt 3 lập attribution evidence packet; Prompt 4 tạo commission statement DRAFT; Prompt 5 chuẩn bị dispute handoff. Mỗi prompt tạo artifact, không kích hoạt connector có quyền.

Input phải có contract/policy/rate version, source refs và dữ liệu DEMO. Nếu thiếu, trả `BLOCKED_INPUT`; nếu event mâu thuẫn, trả `REVIEW_CONFLICT`. Output nêu prohibited actions để reviewer không nhầm DRAFT với quyết định cuối.

Prompt không được đọc giấy tờ thô ngoài môi trường được duyệt; tài liệu nhạy cảm dùng reference và checklist result. Không đưa số tài khoản vào model. Finance calculation chỉ dùng trường đã xác nhận; mọi line có trace để tái tính bằng rule code.

Công cụ và phân quyền triển khai

Zalo OA/form nhận đăng ký và referral; MISA AMIS CRM giữ partner/customer refs; Sapo/KiotViet giữ order; Base.vn quản approval; Google Sheets hỗ trợ reconciliation pilot có quyền. MISA kế toán/hệ tài chính giữ payout, còn portal phân phối statement cho đúng partner.

n8n/Make có thể điều phối nhưng tách credential: intake read, proposal write, portal access, finance payout. AI node chỉ nhận view tối thiểu. Secret không nằm trong Sheet. Mỗi action có correlation_id, actor, target proof và retry policy; payout tuyệt đối không retry mù.

UI duyệt attribution và commission với evidence policy trace và trạng thái dispute
UI minh họa đặt evidence, policy clause và calculation trace cạnh nút duyệt; disputed line được khóa riêng.

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

AI validate, chuẩn hóa, tìm conflict, truy policy, tạo calculation trace và tóm tắt case. Nó không xác minh pháp lý, không phán gian lận, không giải thích điều khoản thay chuyên môn và không quyết định ai “xứng đáng” nhận hoa hồng.

Channel operations duyệt application, role, territory, access và attribution. Legal/compliance xử lý hồ sơ/hợp đồng. Finance xác nhận basis, rate, adjustment và payout. Sales/CSKH xác nhận event nghiệp vụ khi cần. IT/data quản ledger, quyền, log, retention cùng rollback.

Reviewer cần xem raw evidence reference, policy version, time ordering, exclusions, calculation inputs và tác động. Quyết định có reason code; ngoại lệ không tự biến thành rule. Nếu reviewer từ chối, case quay đúng bước với trường cần bổ sung, không bắt đầu lại toàn bộ lifecycle.

Sai lầm và cách xử lý sự cố

Sai lầm gồm dùng Sheet làm ledger có thể sửa, coi ảnh chụp là proof duy nhất, áp rate hiện tại cho đơn quá khứ, cấp quyền trước acceptance, tính commission trước trạng thái hoàn/hủy, retry payout và đóng dispute khi mới gửi thông báo.

Nhánh lỗi cần application quarantine, access review, referral conflict, attribution appeal, calculation exception, payout unknown và dispute escalation. `PAYOUT_UNKNOWN` phải tra provider/reference trước retry. `POLICY_CONFLICT` chuyển owner, không để AI chọn bản mới nhất nếu thời điểm hiệu lực khác.

Circuit breaker khi conflict tăng đột biến, statement lệch reconcile, access grant thiếu approval hoặc payout proof không khớp. Một unauthorized access/adjustment/payment dừng wave. Rollback thu hồi quyền, khóa batch và đưa disputed lines về review; không xóa ledger/audit.

Triển khai theo wave an toàn

Wave 1 application checklist và onboarding DRAFT trên partner DEMO. Wave 2 referral ledger với attribution shadow; vẫn quyết định thủ công. Wave 3 commission statement DRAFT và reconcile, chưa payout. Wave 4 mới cân nhắc kết nối finance sau dual approval, idempotency và diễn tập sự cố.

Test gồm hồ sơ thiếu, duplicate application, access expiry, referral trùng, shared attribution, đơn hoàn, rate transition, partial statement và payout timeout. Mỗi ca có expected state, reviewer, evidence và prohibited actions. Acceptance được ký bởi đúng owner.

Đo completeness, time-to-review, conflict reason, statement correction, reconcile gap, dispute aging và access exception. Dữ liệu pilot phải ghi “minh họa” khi chưa production. Không dùng số partner active hoặc tổng payout làm bằng chứng AI hoạt động tốt.

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

Dữ liệu minh họa: referral `REF-DEMO-77` từ Zalo thuộc CTV P-DEMO-08; form của đại lý P-DEMO-15 đến sau. Policy `ATTR-v4` ưu tiên event hợp lệ sớm nhưng yêu cầu consent/evidence. AI tạo conflict packet; channel owner duyệt P-DEMO-08. Order `ORD-DEMO-91` đã eligible; statement DRAFT dùng RATE-v3. Finance phát hiện return pending nên `HOLD_REVIEW`, chưa payout.

Có nên tự kích hoạt CTV sau khi đủ giấy tờ?

Không. Completeness không phải xác minh hay approval; channel owner và bộ phận chuyên môn quyết định.

Hai đối tác cùng khai một khách thì sao?

Giữ cả hai referral events, áp policy simulation và đưa evidence packet cho người có quyền duyệt.

AI được tự trả hoa hồng không?

Không. AI tạo statement DRAFT; finance duyệt, payout worker riêng và dual approval thực hiện.

Timeout payout có retry ngay không?

Không. Chuyển PAYOUT_UNKNOWN, tra provider/target proof bằng idempotency key rồi mới quyết định.

Xem bản đồ đại lý & CTV, dùng bộ prompt vận hành hoặc liên hệ NganAds qua Zalo 0983543063.

Workflow

  1. Bước 1: Nhận application — Xác minh event/schema và consent xử lý dữ liệu ứng viên/CTV; không dùng consent này thay consent khách được giới thiệu.
  2. Bước 2: Duyệt hồ sơ — AI tạo checklist; channel và legal/compliance xác minh rồi approve hoặc yêu cầu bổ sung.
  3. Bước 3: Onboarding và quyền — Tạo plan/request; người có quyền grant từng resource với expiry và revoke.
  4. Bước 4: Ghi referral — Kiểm consent khách theo purpose/channel rồi ghi ledger idempotent; STOP_CONTACT chặn giao tiếp, event tối thiểu giữ theo retention hợp lệ.
  5. Bước 5: Duyệt attribution — AI simulation theo policy; channel owner quyết định và ghi reason.
  6. Bước 6: DRAFT commission — Lập statement traceable; finance reconcile và duyệt, payout chạy riêng.
  7. Bước 7: Xử lý dispute — Khóa line tranh chấp, thu evidence, quyết định/appeal bởi đúng vai trò.

Prompt mẫu

Kiểm application completeness

MỤC TIÊU: Kiểm trường và evidence của hồ sơ đối tác mà không phê duyệt.
[ĐẦU VÀO]: [APPLICATION_DEMO, REQUIRED_CHECKLIST, CONTRACT_METADATA, ROLE_POLICY].
RÀNG BUỘC: Không xác minh pháp lý; giấy tờ dùng reference; thiếu item trả NEEDS_DOCUMENT.
ĐỊNH DẠNG ĐẦU RA: item | status | evidence_ref | expiry | owner | question | gate.
VÍ DỤ ĐIỀN SẴN: APP-DEMO-12 thiếu acceptance phụ lục v2; NEEDS_DOCUMENT; legal reviewer.

Tạo onboarding plan theo role

MỤC TIÊU: Soạn checklist onboarding theo role, territory và contract scope đã duyệt.
[ĐẦU VÀO]: [APPROVED_PARTNER, ROLE, TERRITORY, CONTRACT_VERSION, CATALOG_VERSION, ACCESS_MATRIX].
CẤM: Không grant access; mỗi quyền là request có approver/expiry/revoke trigger.
ĐỊNH DẠNG ĐẦU RA: task | resource | material_version | access_request | approver | due | proof.
VÍ DỤ ĐIỀN SẴN: CTV miền Bắc; catalog v5; request VIEW_OWN_REFERRALS; channel owner duyệt.

Tạo attribution evidence packet

MỤC TIÊU: So sánh referral events theo policy mà không tự gán nguồn.
[ĐẦU VÀO]: [REFERRAL_EVENTS, PARTNER_DATA_BASIS, CUSTOMER_CONSENT_BY_PURPOSE_CHANNEL, ATTRIBUTION_POLICY, ORDER_REF, PRIOR_DECISIONS].
YÊU CẦU: Không suy consent khách từ hồ sơ CTV; revocation/STOP_CONTACT chặn liên hệ, ledger tối thiểu theo retention hợp lệ; thiếu proof trả REVIEW_EVIDENCE.
ĐỊNH DẠNG ĐẦU RA: eligible_events, timeline, partner_basis, customer_consent, policy_clauses, conflicts, candidate, reviewer_questions.
VÍ DỤ ĐIỀN SẴN: REF-DEMO-77 sớm hơn nhưng consent khách thiếu đúng purpose; packet chuyển channel owner, không liên hệ.

Lập commission statement DRAFT

MỤC TIÊU: Tạo calculation trace từ approved attribution và order eligibility.
[ĐẦU VÀO]: [ATTRIBUTION_DECISION, ORDER_VIEW, RATE_CARD_VERSION, ADJUSTMENTS, RETURN_STATUS].
CẤM: Không quyết adjustment, thuế/khấu trừ hoặc payout; missing input trả HOLD_REVIEW.
ĐỊNH DẠNG ĐẦU RA: statement_lines, basis, rate, amount_demo, exclusions, gaps, finance_checklist.
VÍ DỤ ĐIỀN SẴN: ORD-DEMO-91; RATE-v3; return pending; line HOLD_REVIEW, chưa payout.

Chuẩn bị dispute handoff

MỤC TIÊU: Tóm tắt claim, evidence và decision history cho người xử lý tranh chấp.
[ĐẦU VÀO]: [DISPUTE_CASE, DISPUTED_LINES, EVIDENCE, POLICY_VERSION, PRIOR_DECISIONS, SLA].
RÀNG BUỘC: Không phán gian lận hoặc đảo quyết định; nêu rõ evidence thiếu.
ĐỊNH DẠNG ĐẦU RA: case_summary, timeline, claims, evidence_matrix, policy_refs, missing, next_owner.
VÍ DỤ ĐIỀN SẴN: DSP-DEMO-05 tranh chấp attribution; thiếu source event gốc; next_owner channel lead.

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

Có nên tự kích hoạt CTV sau khi đủ giấy tờ?

Không. Completeness không phải xác minh hay approval; channel owner và bộ phận chuyên môn quyết định.

Hai đối tác cùng khai một khách thì sao?

Giữ cả hai referral events, áp policy simulation và đưa evidence packet cho người có quyền duyệt.

AI được tự trả hoa hồng không?

Không. AI tạo statement DRAFT; finance duyệt, payout worker riêng và dual approval thực hiện.

Timeout payout có retry ngay không?

Không. Chuyển PAYOUT_UNKNOWN, tra provider hoặc target proof bằng idempotency key rồi mới quyết định.

Bài liên quan

Tách từng cổng hồ sơ, quyền, attribution và tài chính; AI chuẩn bị artifact, đúng người duyệt trước mọi tác động.