Kiến thức / Tài chính – Ngân hàng – Bảo hiểm / Tài chính / NH / Bảo hiểm

Workflow AI Tư vấn tín dụng rà độ đầy đủ chứng từ

Workflow rà độ đầy đủ chứng từ cho Tư vấn tín dụng: từ hồ sơ đến nhắc bổ sung chờ duyệt

Tình huống thật khi một tệp được gửi nhiều lần

Một bộ tài liệu có thể đến qua cổng nội bộ, email và tin Zalo đã đăng ký. Người gửi bổ sung một tệp sau cuộc gọi, rồi gửi lại qua Messenger vì chưa thấy phản hồi. Chuyên viên Tư vấn tín dụng nhập trạng thái vào Google Sheets trong khi hệ thống chính đang chậm. Nếu luồng không có source_event_id và khóa chống trùng, cùng một tệp có thể được ghi hai lần, còn lời nhắc có thể được gửi sau khi tài liệu đã nhận.

Workflow AI cho Tư vấn tín dụng trong bài này chỉ quản lý việc tiếp nhận, rà sự hiện diện của chứng từ theo checklist, chuẩn bị nội dung nhắc bổ sung và lưu dấu vết. Agent không xác minh nội dung tài chính, không thay đổi trạng thái nghiệp vụ cuối và không gửi khi chưa có consent cùng người duyệt. Mỗi hành động dùng mã DEMO, trạng thái DRAFT/REVIEW và bằng chứng nguồn. Người có thẩm quyền xử lý mọi quyết định thuộc quy trình tín dụng.

Việc giao cho AI trong đường đi chứng từ

AI có thể kiểm tra envelope của sự kiện, chuẩn hóa tên loại tài liệu, đối chiếu manifest với checklist có phiên bản, phát hiện tệp không mở được, liệt kê mục chưa thấy và tạo câu hỏi bổ sung. Agent cũng có thể kiểm tra consent, thời gian liên hệ, trạng thái STOP_CONTACT và soạn tin nháp ngắn. Những tác vụ này đều dựa trên nguồn và không suy diễn nội dung không có.

AI không được xác nhận giấy tờ thật giả, diễn giải số liệu, gán kết quả, tự bỏ mục khỏi checklist hoặc đổi người duyệt. Nó không dùng một ảnh chụp giao dịch như bằng chứng đã được kiểm tra. Khi nguồn mâu thuẫn, tệp sai mã hoặc checklist không có phiên bản, workflow chuyển REVIEW. Khi consent không rõ hoặc STOP_CONTACT, luồng không tạo lời nhắc. Hành động ghi và gửi chỉ thực hiện sau phê duyệt.

Dữ liệu cần chuẩn bị và trạng thái luồng

Mỗi sự kiện cần source_event_id, package_id dạng DEMO, channel, received_at, file_hash, document_type, checklist_version, storage_ref và uploader_ref đã ẩn danh. Bảng consent có kênh được phép, phạm vi liên hệ, thời gian hiệu lực, trạng thái ACTIVE/STOP_CONTACT và nguồn xác nhận. Checklist chỉ mô tả tài liệu cần hiện diện, không chứa quy tắc ra quyết định.

State machine gồm NEW, DUPLICATE_CHECK, NEED_INFO, READY_FOR_REVIEW, DRAFT_MESSAGE, REVIEW, SENT và ERROR. READY_FOR_REVIEW nghĩa bộ tài liệu đã qua kiểm tra hình thức theo checklist, không mang nghĩa nghiệp vụ khác. Mỗi transition lưu actor, thời gian, rule_version và source_refs. Dữ liệu từ MISA hoặc nguồn kế toán chỉ được tham chiếu theo quyền; Agent không tự sao chép. Tệp PII nằm trong kho nội bộ, không đưa vào prompt thử nghiệm.

Workflow sáu bước có consent và retry an toàn

Bước 1 — Tiếp nhận: tạo package_id và lưu source_event_id; schema sai chuyển ERROR_INPUT. Bước 2 — Chống trùng: so source_event_id, file_hash và manifest; nghi trùng chuyển REVIEW_DUPLICATE, không tự gộp. Bước 3 — Rà độ đầy đủ: so loại tài liệu, kỳ, số trang và khả năng đọc với checklist_version; mục chưa thấy chuyển NEED_INFO kèm source_refs.

Bước 4 — Chuẩn bị lời nhắc: kiểm consent, STOP_CONTACT, lần liên hệ cuối và quiet hours; Agent tạo DRAFT_MESSAGE, chưa gửi. Bước 5 — Chuyên viên duyệt và gửi: đối chiếu package, danh sách bổ sung, người nhận và kênh; adapter dùng message_id chống gửi lặp. Bước 6 — Đối soát: xác nhận trạng thái gửi, cập nhật log và lịch xem lại. Timeout không đồng nghĩa gửi thất bại; phải tra message_id trước retry. Lỗi một phần chuyển ERROR_PARTIAL cho owner xử lý.

Workflow rà độ đầy đủ chứng từ và nhắc bổ sung có consent retry và người duyệt
Luồng minh họa có nhánh DUPLICATE, NEED_INFO, REVIEW và ERROR_PARTIAL.

Năm prompt mẫu cho các cổng workflow

Prompt 1 kiểm tra envelope sự kiện. Prompt 2 so manifest với checklist và chỉ liệt kê trạng thái hình thức. Prompt 3 kiểm consent cùng quiet hours. Prompt 4 đặc tả idempotency cho hành động gửi. Prompt 5 phân tích hàng lỗi và lập checklist phục hồi. Bộ prompt không tóm tắt nội dung hồ sơ, không viết câu hỏi chi tiết cho người gửi và không tổng hợp hàng đợi; các đầu ra đó thuộc prompt-pack riêng.

Prompt chỉ tạo đặc tả hoặc DRAFT. Người dùng thử các ca tệp trùng, tệp lỗi, checklist cũ, consent hết hiệu lực, STOP_CONTACT, timeout và gửi thành công nhưng callback thất bại. Agent không chạy lệnh hoặc retry. IT xác nhận idempotency; chủ quy trình xác nhận state transition; chuyên viên duyệt nội dung. Nếu thiếu một owner, bước đó không được tự động.

Công cụ phù hợp và kiến trúc tối thiểu

Cổng nội bộ hoặc form là nguồn ưu tiên; Google Sheets có thể làm hàng đợi DEMO; CRM/LOS nội bộ giữ trạng thái chính; Zalo hoặc Messenger chỉ là kênh được phép khi consent đã ghi nhận. MISA là nguồn tài liệu kế toán theo phạm vi nội bộ, không phải công cụ để Agent đưa ra kết luận. Một orchestration layer tạo mã, gọi AI ở vùng DRAFT và chờ phê duyệt.

Mỗi adapter có tài khoản dịch vụ riêng, quyền tối thiểu, timeout và retry budget. File hash hỗ trợ phát hiện tệp giống nhau nhưng không đủ để tự gộp hai package. Message adapter lưu message_id, delivery status và thời gian. Hàng lỗi chỉ giữ mã tham chiếu, không nhân bản PII. Dashboard tách lỗi đầu vào, consent, tệp, rule và kết nối.

Giao diện hàng đợi DEMO theo package id consent và trạng thái lỗi
Giao diện minh họa dùng mã DEMO; không chứa PII hoặc kết quả nghiệp vụ.

AI làm gì và người duyệt làm gì

AI chuẩn hóa metadata, so checklist, phát hiện mục chưa thấy, tạo stop_reason và bản nháp. Agent không mở rộng phạm vi, không tự xác nhận consent và không đổi rule_version. Mỗi dòng đầu ra dẫn source_id. Nếu tệp không đọc được, Agent ghi UNREADABLE thay vì suy đoán nội dung.

Chuyên viên xác nhận package, kiểm mục cần bổ sung, người nhận và ngôn ngữ. Chủ quy trình sở hữu checklist và state machine; tuân thủ xác nhận consent policy; IT sở hữu adapter và retry; người có thẩm quyền xử lý quyết định nghiệp vụ. Khi bản nháp sai, người duyệt sửa nguồn hoặc rule trước, không chỉ sửa câu chữ rồi tiếp tục.

Sai lầm và nhánh lỗi cần tránh

Sai lầm đầu tiên là dùng tên tệp làm khóa chống trùng. Sai lầm thứ hai là gửi lại ngay khi timeout, gây hai tin giống nhau. Sai lầm thứ ba là coi “không thấy trong manifest” như “không tồn tại”. Sai lầm thứ tư là dùng consent của kênh này cho kênh khác. Mỗi trường hợp cần trạng thái và owner riêng.

ERROR_PARTIAL xảy ra khi tin đã gửi nhưng log chưa cập nhật, hoặc tệp đã lưu nhưng manifest chưa ghi. Owner phải tra hệ thống đích trước retry. REVIEW_DUPLICATE cần chuyên viên xem source và thời gian. ERROR_POLICY xuất hiện khi checklist hết hiệu lực. Không xóa sự kiện lỗi; lưu mã, nguyên nhân, lần thử và hành động phục hồi. Rollback ưu tiên dừng gửi và khóa adapter, không xóa tài liệu nguồn.

Triển khai cá nhân, đội và tổ chức

Cá nhân thử với 20 package DEMO và chế độ không gửi. Tạo ca trùng, thiếu, unreadable và consent hết hiệu lực. Đội nhỏ mở một kênh, duyệt mọi DRAFT_MESSAGE và rà hàng lỗi hàng ngày. Chỉ dùng quiet hours cùng tần suất do chính sách nội bộ xác nhận.

Tổ chức tách staging, quản lý checklist và prompt theo phiên bản, kiểm tra quyền định kỳ và có runbook. Theo dõi tệp trùng bị chặn, mục NEED_INFO, tin nháp phải sửa, timeout, retry bị ngăn và ERROR_PARTIAL. Không dùng dashboard để suy luận về khách hàng. Chỉ mở rộng khi nghiệp vụ, IT, bảo mật và tuân thủ nghiệm thu cả đường chính lẫn đường lỗi.

Kết quả đầu ra mẫu và FAQ

Kết quả minh họa: package DEMO-PKG-027; checklist TD-DOC-v3; manifest có 5 loại; 1 loại trạng thái UNREADABLE; consent ZALO_ACTIVE; DRAFT_MESSAGE chờ reviewer; lần gửi gần nhất không có; message_id chưa tạo; trạng thái REVIEW.

READY_FOR_REVIEW có nghĩa gì?

Nó chỉ cho biết package đã qua rà hình thức theo checklist và sẵn sàng để chuyên viên xem.

Timeout có được gửi lại ngay không?

Không. Hãy tra message_id và delivery status trước khi retry.

STOP_CONTACT được xử lý thế nào?

Workflow dừng tạo lời nhắc, ghi stop_reason và chuyển người phụ trách nếu có yêu cầu khác.

Tệp không đọc được có bị coi là thiếu không?

Không. Gắn UNREADABLE, giữ nguồn và yêu cầu chuyên viên chọn cách bổ sung phù hợp.

Nếu cần rà state machine và consent, hãy liên hệ NganAds tại trang tư vấn hoặc số 0983543063.

Workflow

  1. Bước 1: Tiếp nhận có mã sự kiện — Tạo package_id từ source_event_id; schema lỗi chuyển ERROR_INPUT.
  2. Bước 2: Chống trùng — So source_event_id, file_hash và manifest; nghi trùng chuyển REVIEW_DUPLICATE.
  3. Bước 3: Rà độ đầy đủ theo checklist — Gắn PRESENT, NOT_SEEN, UNREADABLE hoặc REVIEW, luôn kèm source_id.
  4. Bước 4: Kiểm consent và tạo bản nháp — STOP_CONTACT dừng; trạng thái hợp lệ mới tạo DRAFT_MESSAGE, chưa gửi.
  5. Bước 5: Chuyên viên duyệt và gửi — Kiểm package, người nhận, kênh; adapter dùng message_id chống gửi lặp.
  6. Bước 6: Đối soát và xử lý lỗi — Tra delivery status trước retry; partial failure chuyển ERROR_PARTIAL cho owner.

Prompt mẫu

Kiểm tra envelope tiếp nhận

MỤC TIÊU: Kiểm tra một sự kiện tài liệu trước khi tạo package.
[ĐẦU VÀO]: source_event_id, channel, received_at, file_hash, document_type, storage_ref, schema và quyền nguồn.
ĐỊNH DẠNG ĐẦU RA: VALID/ERROR_INPUT, normalized_envelope, missing_fields, duplicate_hint, stop_reason và reviewer; không đọc sâu nội dung.
VÍ DỤ ĐIỀN SẴN: EVT-DEMO-81; portal; DOC-DEMO-A; hash DEMO-H1; thiếu checklist_version.

Rà manifest theo checklist

MỤC TIÊU: Đối chiếu sự hiện diện và khả năng đọc của tài liệu với checklist có phiên bản.
[ĐẦU VÀO]: package_id, checklist_version, manifest gồm document_type, kỳ, số trang, source_id và readable_status.
ĐỊNH DẠNG ĐẦU RA: Bảng mục, source_id, PRESENT/NOT_SEEN/UNREADABLE/REVIEW, lý do và câu hỏi kỹ thuật; không diễn giải số liệu.
VÍ DỤ ĐIỀN SẴN: DEMO-PKG-027; TD-DOC-v3; 5 loại; DOC-DEMO-C không mở được.

Kiểm tra consent và lịch liên hệ

MỤC TIÊU: Xác định workflow có được tạo DRAFT_MESSAGE cho kênh đã chọn hay phải dừng.
[ĐẦU VÀO]: consent_status, channel, scope, effective_at, expires_at, STOP_CONTACT, quiet_hours, lần liên hệ cuối và policy_version.
ĐỊNH DẠNG ĐẦU RA: ALLOW_DRAFT/STOP/REVIEW, evidence, reason, earliest_draft_time và reviewer; không gửi nội dung.
VÍ DỤ ĐIỀN SẴN: ZALO_ACTIVE; scope bổ sung tài liệu; quiet hours 20:00–08:00; chưa có lần gửi.

Đặc tả idempotency cho tin nhắn

MỤC TIÊU: Thiết kế chống gửi lặp và retry có giới hạn cho một bước gửi đã được phê duyệt.
[ĐẦU VÀO]: package_id, draft_version, channel, message_id, timeout, delivery lookup, retry_budget, owner và stop condition.
ĐỊNH DẠNG ĐẦU RA: idempotency_key, pre-check, success proof, timeout handling, retry rule, ERROR state, manual recovery và alert.
VÍ DỤ ĐIỀN SẴN: DEMO-PKG-027; draft v2; Zalo; timeout 10 giây; tra message_id trước retry; budget 1.

Thiết kế xử lý hàng lỗi

MỤC TIÊU: Phân loại lỗi workflow và tạo checklist phục hồi cho owner, không tự chạy hành động.
[ĐẦU VÀO]: package_id, failed_step, error_code, attempts, source_refs, target_proof, last_transition, owner và runbook.
ĐỊNH DẠNG ĐẦU RA: error_class, current_state, evidence_needed, safe_checks, prohibited_actions, recovery_steps, reviewer và close_condition.
VÍ DỤ ĐIỀN SẴN: DEMO-PKG-027; SEND_CALLBACK; timeout; target_proof chưa tra; ERROR_PARTIAL; owner OPS-DEMO.

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

READY_FOR_REVIEW có nghĩa gì?

Chỉ cho biết package đã qua rà hình thức theo checklist và sẵn sàng để chuyên viên xem.

Timeout có được gửi lại ngay không?

Không; phải tra message_id và delivery status trước khi retry.

STOP_CONTACT được xử lý thế nào?

Dừng tạo lời nhắc, ghi stop_reason và chuyển người phụ trách khi cần.

Tệp không đọc được có bị coi là thiếu không?

Không; gắn UNREADABLE, giữ nguồn và để chuyên viên chọn cách bổ sung.

Bài liên quan

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