Kiến thức / Chủ shop online / Chủ shop

Bộ prompt phân tích chăm khách cũ và phục hồi case

Bộ prompt tạo mô tả, combo và kịch bản chốt đơn cho Chăm khách cũ: copy và tùy chỉnh

Tình huống thực tế

CARE-PROMPT-32 không tạo chiến dịch liên hệ. Nó dùng ticket đã đóng, lý do hoàn/đổi, correction của nhân viên và phản hồi được phép để tìm điểm phục vụ cần sửa. Dữ liệu từ Sapo, KiotViet, Shopee, Zalo, Messenger và Google Sheets được redaction, lấy mẫu và gắn purpose. Mỗi prompt tạo một artifact nội bộ: taxonomy tiếng nói khách, pattern lỗi, unresolved brief, handoff memo hoặc learning backlog. Không output nào được gửi cho khách tự động. Mốc kiểm CARE-PROMPT-32-1: artifact chỉ được chuyển tiếp khi nguồn, owner và điều kiện dừng đều hiện rõ; nếu không, người vận hành giữ trạng thái chờ và dùng đường thủ công đã phê duyệt.

Việc có thể giao cho AI

AI có thể nhóm câu theo vấn đề, trích evidence, so policy với cách xử lý, tìm case tương tự và gợi ý câu hỏi điều tra. Nó không kết luận lỗi thuộc nhân viên chỉ từ transcript, không suy cảm xúc hay đặc điểm nhạy cảm, không quyết định bồi thường và không chốt ưu đãi. Khi sample thiên lệch hoặc thiếu resolution, kết quả phải ghi LIMITATION và chuyển human review. Mốc kiểm CARE-PROMPT-32-2: artifact chỉ được chuyển tiếp khi nguồn, owner và điều kiện dừng đều hiện rõ; nếu không, người vận hành giữ trạng thái chờ và dùng đường thủ công đã phê duyệt.

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

Đầu vào cần ticket-id giả danh, timestamps, channel, issue code, product/order context tối thiểu, agent correction, resolution và policy-version. Dataset có sampling note để tránh chỉ nhìn case tiêu cực. PII, payment data và nội dung ngoài mục đích được loại. Một sample manifest ghi query, thời gian, số case và exclusions để reviewer tái hiện; file xuất tùy ý không được coi là corpus chuẩn. Mốc kiểm CARE-PROMPT-32-3: artifact chỉ được chuyển tiếp khi nguồn, owner và điều kiện dừng đều hiện rõ; nếu không, người vận hành giữ trạng thái chờ và dùng đường thủ công đã phê duyệt.

Workflow từng bước

Vòng phân tích đi qua SCOPE, SAMPLE, REDACT, ANALYZE, ADJUDICATE, ACTION_BACKLOG và RETEST. Issue không đủ evidence vào LIMITATION; nhãn mâu thuẫn vào ADJUDICATION; đề xuất vượt quyền vào REJECTED. Human owner chọn việc cải thiện và kiểm lại trên sample mới. Workflow này không mở kênh giao tiếp và không thay care-flow theo từng case ở bài khác. Mốc kiểm CARE-PROMPT-32-4: artifact chỉ được chuyển tiếp khi nguồn, owner và điều kiện dừng đều hiện rõ; nếu không, người vận hành giữ trạng thái chờ và dùng đường thủ công đã phê duyệt.

Bước 1: SCOPE câu hỏi học tập

Ghi purpose, owner, period, exclusions và quyết định sẽ không được tự động hóa. Tiêu chí qua bước 1 của CARE-PROMPT-32 là có evidence, next-state và đúng human owner; mọi lỗi phải giữ reason code để phục hồi đúng chặng.

Bước 2: SAMPLE có manifest

Lấy mẫu cân bằng, ghi query và nguồn; thiếu resolution chuyển LIMITATION. Tiêu chí qua bước 2 của CARE-PROMPT-32 là có evidence, next-state và đúng human owner; mọi lỗi phải giữ reason code để phục hồi đúng chặng.

Bước 3: REDACT và validate

Loại PII/secret, kiểm policy-version và schema trước khi AI đọc. Tiêu chí qua bước 3 của CARE-PROMPT-32 là có evidence, next-state và đúng human owner; mọi lỗi phải giữ reason code để phục hồi đúng chặng.

Bước 4: ANALYZE thành artifact

Chạy prompt riêng cho taxonomy/pattern/brief; mọi finding phải có case-ref. Tiêu chí qua bước 4 của CARE-PROMPT-32 là có evidence, next-state và đúng human owner; mọi lỗi phải giữ reason code để phục hồi đúng chặng.

Bước 5: ADJUDICATE

Hai reviewer xử lý nhãn mới, conflict và counterexample; model không tự kết luận root cause. Tiêu chí qua bước 5 của CARE-PROMPT-32 là có evidence, next-state và đúng human owner; mọi lỗi phải giữ reason code để phục hồi đúng chặng.

Bước 6: Lập ACTION_BACKLOG

Human owner chọn sửa tài liệu/quy trình, deadline và test; đề xuất vượt quyền bị loại. Tiêu chí qua bước 6 của CARE-PROMPT-32 là có evidence, next-state và đúng human owner; mọi lỗi phải giữ reason code để phục hồi đúng chặng.

Bước 7: RETEST và đóng vòng

Chạy sample mới, so evidence, ghi limitation và quyết định giữ/sửa action. Tiêu chí qua bước 7 của CARE-PROMPT-32 là có evidence, next-state và đúng human owner; mọi lỗi phải giữ reason code để phục hồi đúng chặng.

Sơ đồ bộ prompt học từ lịch sử phục vụ và phục hồi case
Sơ đồ minh họa CARE-PROMPT-32: state, nhánh lỗi, điều kiện dừng và Human-in-the-loop được hiển thị đầy đủ, không cắt ảnh.

Prompt thực hành

Năm prompt có nhiệm vụ khác nhau: xây taxonomy VOC, phân tích lỗi lặp, tạo unresolved-case brief, viết handoff memo và lập learning backlog. Mỗi prompt buộc chỉ evidence, limitations và owner. Ví dụ điền sẵn dùng case DEMO, không nêu số liệu như sự thật. Bộ prompt giúp copy nhanh nhưng phải được chạy trong môi trường đã phê duyệt và kết quả vẫn là DRAFT nội bộ. Mốc kiểm CARE-PROMPT-32-5: artifact chỉ được chuyển tiếp khi nguồn, owner và điều kiện dừng đều hiện rõ; nếu không, người vận hành giữ trạng thái chờ và dùng đường thủ công đã phê duyệt.

Prompt 1: Xây taxonomy tiếng nói khách

Nhóm vấn đề bằng evidence, không suy đặc điểm người. Bản copy nằm trong prompt pack, có biến đầu vào, định dạng trả về và ví dụ CARE-PROMPT-32; kết quả luôn là tài liệu chờ người duyệt — 4499A3E2-13-2.

Prompt 2: Phân tích pattern lỗi lặp

Tìm chuỗi sự kiện lặp và giả thuyết cần kiểm. Bản copy nằm trong prompt pack, có biến đầu vào, định dạng trả về và ví dụ CARE-PROMPT-32; kết quả luôn là tài liệu chờ người duyệt — 4499A3E2-14-2.

Prompt 3: Tạo unresolved-case brief

Tóm tắt case chưa đóng để service owner điều tra. Bản copy nằm trong prompt pack, có biến đầu vào, định dạng trả về và ví dụ CARE-PROMPT-32; kết quả luôn là tài liệu chờ người duyệt — 4499A3E2-15-2.

Prompt 4: Viết handoff memo liên phòng

Chuyển evidence từ CSKH sang product/ops mà không lộ PII. Bản copy nằm trong prompt pack, có biến đầu vào, định dạng trả về và ví dụ CARE-PROMPT-32; kết quả luôn là tài liệu chờ người duyệt — 4499A3E2-16-2.

Prompt 5: Lập learning backlog và retest

Chuyển finding đã adjudicate thành việc có phép thử. Bản copy nằm trong prompt pack, có biến đầu vào, định dạng trả về và ví dụ CARE-PROMPT-32; kết quả luôn là tài liệu chờ người duyệt — 4499A3E2-17-2.

Công cụ phù hợp

Helpdesk hoặc CRM là nguồn ticket; Sapo/KiotViet cho order context; Sheets/Airtable giữ sample manifest; Notion giữ policy và backlog; Looker Studio có thể hiển thị biểu đồ minh họa; Zalo/Messenger chỉ cung cấp đoạn hội thoại theo quyền. AI không giữ credential gửi. Access theo role, retention theo purpose và export được kiểm trước khi đưa vào prompt. Mốc kiểm CARE-PROMPT-32-6: artifact chỉ được chuyển tiếp khi nguồn, owner và điều kiện dừng đều hiện rõ; nếu không, người vận hành giữ trạng thái chờ và dùng đường thủ công đã phê duyệt.

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

AI nhóm pattern và soạn evidence table; QA lead adjudicate nhãn; service owner xác minh root cause; product/catalog owner xử lý vấn đề hàng hóa; CSKH lead chọn coaching; privacy owner duyệt sampling; quản lý quyết bồi thường hoặc policy. Không dùng cluster của model để chấm điểm cá nhân. Nếu cần đánh giá nhân sự, phải có quy trình riêng, bằng chứng đầy đủ và quyền giải trình. Mốc kiểm CARE-PROMPT-32-7: artifact chỉ được chuyển tiếp khi nguồn, owner và điều kiện dừng đều hiện rõ; nếu không, người vận hành giữ trạng thái chờ và dùng đường thủ công đã phê duyệt.

Bảng dữ liệu, quyền và kiểm duyệt cho Chăm khách cũ
Visual minh họa CARE-PROMPT-32; số liệu DEMO dùng để kiểm quy trình, không phải kết quả kinh doanh.

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

Sai lầm là lấy mọi hội thoại làm corpus, nhầm tương quan với nguyên nhân, sao chép câu khách làm nhãn nhạy cảm hoặc biến backlog thành tin nhắn marketing. Một lỗi nữa là lặp prompt đến khi có kết luận hợp ý. CARE-PROMPT-32 giữ sample manifest, prompt-version, adjudication và counterexample. Số lượng nhỏ được ghi “minh họa”; số liệu thật phải có nguồn và phương pháp. Mốc kiểm CARE-PROMPT-32-8: artifact chỉ được chuyển tiếp khi nguồn, owner và điều kiện dừng đều hiện rõ; nếu không, người vận hành giữ trạng thái chờ và dùng đường thủ công đã phê duyệt.

Triển khai theo quy mô

Cá nhân bắt đầu với 20 case đã đóng và một câu hỏi học tập. Đội nhỏ thêm hai reviewer cho nhãn mới; doanh nghiệp tạo benchmark, data retention, access review và lịch retest. Ưu tiên sửa tài liệu, quy trình hoặc nguồn dữ liệu trước khi tăng automation. Đo coverage của evidence, agreement của reviewer, tỷ lệ action backlog có owner và kết quả retest; không dùng số tin gửi hay doanh thu làm tiêu chí. Mốc kiểm CARE-PROMPT-32-9: artifact chỉ được chuyển tiếp khi nguồn, owner và điều kiện dừng đều hiện rõ; nếu không, người vận hành giữ trạng thái chờ và dùng đường thủ công đã phê duyệt.

Kết quả đầu ra mẫu

Kết quả minh họa CARE-PROMPT-32 gồm 20 case, sáu nhóm vấn đề, bốn limitation và năm action backlog. Nhóm DEMO-RET-02 có ba case cùng thiếu hướng dẫn đổi size; service owner kiểm policy và product team sửa trang hướng dẫn. Không ai được tự động nhắn lại, không bồi thường tự động và không quy lỗi cá nhân. Biểu đồ chỉ là dữ liệu minh họa cho cách ra quyết định. Mốc kiểm CARE-PROMPT-32-10: artifact chỉ được chuyển tiếp khi nguồn, owner và điều kiện dừng đều hiện rõ; nếu không, người vận hành giữ trạng thái chờ và dùng đường thủ công đã phê duyệt.

Ca 4499A3E2: Đọc tiếp: Hub Kiến thức AI Agent · Cụm Chủ shop · Ngành Chủ shop online · Landing nghề · Google Sheets bằng AI · Sale và CSKH

Bước tiếp theo: Chọn một fixture CARE-PROMPT-32, loại dữ liệu không cần thiết và gửi sơ đồ hiện trạng tại /lien-he để NganAds cùng thiết kế pilot DRAFT-only có người duyệt.

Workflow

  1. Bước 1: SCOPE câu hỏi học tập — Ghi purpose, owner, period, exclusions và quyết định sẽ không được tự động hóa.
  2. Bước 2: SAMPLE có manifest — Lấy mẫu cân bằng, ghi query và nguồn; thiếu resolution chuyển LIMITATION.
  3. Bước 3: REDACT và validate — Loại PII/secret, kiểm policy-version và schema trước khi AI đọc.
  4. Bước 4: ANALYZE thành artifact — Chạy prompt riêng cho taxonomy/pattern/brief; mọi finding phải có case-ref.
  5. Bước 5: ADJUDICATE — Hai reviewer xử lý nhãn mới, conflict và counterexample; model không tự kết luận root cause.
  6. Bước 6: Lập ACTION_BACKLOG — Human owner chọn sửa tài liệu/quy trình, deadline và test; đề xuất vượt quyền bị loại.
  7. Bước 7: RETEST và đóng vòng — Chạy sample mới, so evidence, ghi limitation và quyết định giữ/sửa action.

Prompt mẫu

Xây taxonomy tiếng nói khách

MỤC TIÊU: Nhóm vấn đề bằng evidence, không suy đặc điểm người.

[ĐẦU VÀO]
MÃ_ARTIFACT = [CARE-PROMPT-32-1]
CASE_SAMPLE, EXISTING_CODES, PRODUCT_CONTEXT, EXCLUSIONS = [điền dữ liệu đã kiểm tra]
PHẠM_VI = [DRAFT nội bộ, không gửi/đăng/chốt]

YÊU CẦU: Giữ UNKNOWN khi thiếu bằng chứng; nêu source-ref, limitation, stop condition và người duyệt. Không tạo hành động bên ngoài.

ĐỊNH DẠNG ĐẦU RA: Code | Definition | Evidence | Counterexample | Needs adjudication.

VÍ DỤ ĐIỀN SẴN: “khó tìm size chart” là issue điều hướng, không gắn nhãn khách thiếu hiểu biết.

Phân tích pattern lỗi lặp

MỤC TIÊU: Tìm chuỗi sự kiện lặp và giả thuyết cần kiểm.

[ĐẦU VÀO]
MÃ_ARTIFACT = [CARE-PROMPT-32-2]
EVENT_TIMELINE, RESOLUTION, POLICY_VERSION, AGENT_CORRECTION = [điền dữ liệu đã kiểm tra]
PHẠM_VI = [DRAFT nội bộ, không gửi/đăng/chốt]

YÊU CẦU: Giữ UNKNOWN khi thiếu bằng chứng; nêu source-ref, limitation, stop condition và người duyệt. Không tạo hành động bên ngoài.

ĐỊNH DẠNG ĐẦU RA: Pattern | Case refs | Hypothesis | Missing evidence | Owner.

VÍ DỤ ĐIỀN SẴN: Ba case DEMO cùng thiếu tài liệu đổi size; chưa kết luận lỗi nhân viên.

Tạo unresolved-case brief

MỤC TIÊU: Tóm tắt case chưa đóng để service owner điều tra.

[ĐẦU VÀO]
MÃ_ARTIFACT = [CARE-PROMPT-32-3]
TICKET, ORDER_FACTS, CONTACT_LOG, OPEN_QUESTIONS = [điền dữ liệu đã kiểm tra]
PHẠM_VI = [DRAFT nội bộ, không gửi/đăng/chốt]

YÊU CẦU: Giữ UNKNOWN khi thiếu bằng chứng; nêu source-ref, limitation, stop condition và người duyệt. Không tạo hành động bên ngoài.

ĐỊNH DẠNG ĐẦU RA: Known | Unknown | Attempts | Decision needed | Safe next step.

VÍ DỤ ĐIỀN SẴN: Không đề xuất nhắn bán hàng khi case bảo hành vẫn OPEN.

Viết handoff memo liên phòng

MỤC TIÊU: Chuyển evidence từ CSKH sang product/ops mà không lộ PII.

[ĐẦU VÀO]
MÃ_ARTIFACT = [CARE-PROMPT-32-4]
FINDING, CASE_REFS, REDACTION_RULE, OWNER_ROSTER = [điền dữ liệu đã kiểm tra]
PHẠM_VI = [DRAFT nội bộ, không gửi/đăng/chốt]

YÊU CẦU: Giữ UNKNOWN khi thiếu bằng chứng; nêu source-ref, limitation, stop condition và người duyệt. Không tạo hành động bên ngoài.

ĐỊNH DẠNG ĐẦU RA: Problem | Evidence | Impact scope | Question | Owner | Due date.

VÍ DỤ ĐIỀN SẴN: Memo DEMO-RET-02 chỉ dùng case-id giả danh và ảnh lỗi đã được duyệt.

Lập learning backlog và retest

MỤC TIÊU: Chuyển finding đã adjudicate thành việc có phép thử.

[ĐẦU VÀO]
MÃ_ARTIFACT = [CARE-PROMPT-32-5]
ADJUDICATED_FINDINGS, CAPACITY, POLICY, BASELINE_SAMPLE = [điền dữ liệu đã kiểm tra]
PHẠM_VI = [DRAFT nội bộ, không gửi/đăng/chốt]

YÊU CẦU: Giữ UNKNOWN khi thiếu bằng chứng; nêu source-ref, limitation, stop condition và người duyệt. Không tạo hành động bên ngoài.

ĐỊNH DẠNG ĐẦU RA: Action | Owner | Test | Stop rule | Retest sample | Limitation.

VÍ DỤ ĐIỀN SẴN: Sửa trang size guide, sau đó lấy sample mới; không gửi lại khách tự động.

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

Bài liên quan

Chọn một fixture CARE-PROMPT-32, loại dữ liệu không cần thiết và gửi sơ đồ hiện trạng tại /lien-he để NganAds cùng thiết kế pilot DRAFT-only có người duyệt.