Case Study: Customer Support Copilot #15

Trả lời ngắn: Support copilot là trợ lý gợi ý cho nhân viên support: đọc ticket trong phạm vi, tìm policy, tạo draft reply và chỉ ra điều chưa chắc. Nhân viên vẫn quyết định, chỉnh sửa và bấm gửi. Thiết kế tốt cần context contract, tenant boundary, PII guardrail, escalation state, evidence và fallback khi system không đủ chắc.

Đọc xong, bạn sẽ hiểu:

• Cách đặt boundary cho ticket, account và policy.
• Cách nối context, retrieval, draft reply và escalation.
• Cách đo groundedness, policy correctness và escalation quality.
• Cách luyện bằng bốn ticket giả mà không gửi message thật.

Lưu ý giáo dục: Ví dụ chỉ dùng ticket giả hoặc public policy. Không nhập customer data, PII, credentials, production transcript hay payment information. Bài không hứa SLA, refund, legal outcome hoặc accuracy tuyệt đối; support staff phải kiểm policy trước khi gửi.

1. Case study: support copilot giải bài toán nào?

Support copilot là trợ lý gợi ý cho nhân viên; nhân viên vẫn quyết định và gửi. Case giả: một user hỏi “Đơn #12345 của tôi có được đổi gói không?”. Copilot cần giúp support nhìn context, tìm policy version phù hợp, soạn câu trả lời lịch sự và ghi rõ nếu thiếu dữ liệu.

Copilot khác chatbot tự trả lời ở quyền và user journey. Chatbot có thể đứng trước khách hàng. Copilot ngồi trong workbench của nhân viên, nơi người có quyền thấy draft, source, confidence và escalation reason trước send. Autonomous agent có thể tự gọi action; trong case này, ta giữ action read-only để giảm risk.

Chốt outcome trước khi chọn model:

• Support thấy đúng ticket, tenant và language.
• Draft chỉ nói điều policy/evidence support.
• Thiếu order field thì hỏi thêm hoặc chuyển người, không đoán.
• PII được tối thiểu hóa và không chảy vào log ngoài cần thiết.
• Refund, account change, compensation hoặc send message cần approval.

Ví dụ đời thường: copilot giống đồng nghiệp ngồi cạnh gợi ý cách tra bảng policy. Bạn vẫn cầm điện thoại nói với khách. Nếu case vượt quyền, gọi trưởng ca; không vì đồng nghiệp gợi ý nhanh mà bỏ qua sổ quy trình.

Hình 1 — Workbench để nhân viên xem ticket, context, policy, draft và quyết định send hoặc escalation.

2. Context contract và customer data boundary

Context contract là field và boundary cần có để trả lời trong phạm vi. Với ticket giả, contract có thể gồm ticket_id, tenant_id, customer_language, order_id, plan, question, channel và timestamp. Tenant là nhóm tài khoản/khách hàng cần được tách dữ liệu; tenant mismatch phải chặn retrieval.

PII là thông tin có thể nhận diện một người, như email, số điện thoại hoặc địa chỉ. Copilot chỉ cần phần tối thiểu để xử lý; không copy toàn bộ transcript vào prompt hoặc trace. Nếu ticket chứa PII không cần thiết, redact trước khi log. Nếu data scope không rõ, UNKNOWN là trạng thái đúng hơn một câu trả lời chắc chắn.

Retrieval nên lọc tenant, policy version và access role trước khi đưa context vào model. Policy cũ có thể nói điều khác policy mới; source càng gần decision càng cần date/version. Context đúng giúp groundedness, nhưng vẫn không biến draft thành approval.

3. Draft reply flow và escalation states

Flow read-only của support copilot:

1. RECEIVED: nhận ticket, kiểm field và tenant.
2. CONTEXT_READY: lấy policy/order record được phép, ghi source/date.
3. DRAFTED: tạo reply ngắn, evidence và confidence.
4. NEEDS_REVIEW: thiếu field, policy conflict, confidence thấp hoặc action nhạy cảm.
5. ESCALATED: chuyển trưởng ca, billing hoặc specialist với reason rõ.
6. SENT: chỉ sau khi nhân viên chỉnh/duyệt và bấm gửi.

Tool get_order_status có thể read-only. Tool refund_order, change_plan hoặc send_message có side effect và không nằm trong quyền mặc định của copilot. Nếu một system muốn mở các tool đó, cần allowlist, approval, state check, idempotency và audit riêng.

Escalation không phải “AI chịu thua”. Nó là đường đi được thiết kế khi case có risk hoặc nằm ngoài scope: policy conflict, customer asks exception, account ownership unclear, PII sensitive, payment issue hoặc angry user cần người xử lý. Reason tốt là “policy v2.1 và record v2.0 khác nhau”, không phải “AI không biết”.

Hình 2 — State và owner làm rõ khi nào copilot draft, khi nào hỏi thêm, escalation hoặc dừng.

4. Quality, safety và support metrics

Groundedness là mức câu trả lời bám evidence/policy đã chọn. Một draft lịch sự nhưng nói sai chính sách vẫn fail. Checklist nên tách:

• Policy correctness: câu trả lời khớp rule và version chưa?
• Groundedness: claim có source trực tiếp không?
• Context accuracy: đúng tenant, order và language chưa?
• Tone: lịch sự, rõ, không hứa quá mức chưa?
• Escalation quality: case khó có chuyển đúng owner và reason chưa?
• PII safety: dữ liệu nhạy cảm có bị copy, log hoặc hiển thị thừa không?
• Operations: latency, error, retry và audit có quan sát được không?

Không lấy “tỷ lệ draft được gửi” làm metric duy nhất. Tỷ lệ cao có thể là automation bias — xu hướng tin output máy chỉ vì nó có vẻ chắc. Nên xem thêm tỷ lệ reviewer sửa, tỷ lệ escalation đúng, claim correction, policy conflict và feedback sau send. Các tỷ lệ trong bảng practice chỉ là demo, không phải benchmark của sản phẩm.

Audit là dấu vết ai làm gì, dựa source nào, khi nào. Một audit nhỏ nhưng đủ có ticket_id giả, policy version, draft state, reviewer decision, tool call và timestamp; tránh lưu raw PII không cần. Microsoft và OpenAI đều nhấn mạnh việc ghép search/tools với state, guardrails và tracing khi xây agent/workflow. Microsoft search/tool architectures và OpenAI Agents guide

Hình 3 — Safety matrix nối lỗi context với response, stop, redact, escalation và owner.

5. Sai lầm, giới hạn và fallback

Các lỗi và rủi ro thường gặp:

• Overconfident reply: draft khẳng định refund dù policy chỉ nói “có thể xem xét”.
• Wrong tenant: retrieval lấy record của account khác vì tenant field thiếu hoặc filter sai.
• Stale policy: dùng version cũ nhưng không nói ngày hiệu lực.
• Empathy theater: câu xin lỗi dài nhưng không có bước tiếp theo đúng policy.
• Automation bias: nhân viên bấm gửi vì draft nhìn chuyên nghiệp mà không mở source.
• Duplicate send: retry sau timeout tạo hai message.
• Missing audit: không biết ai duyệt ngoại lệ hoặc source nào đã dùng.
• SLA overclaim: agent hứa thời gian xử lý mà policy không cho phép.

Fallback phải có hành động cụ thể: thiếu order ID → hỏi field; tenant mismatch → block; PII thừa → redact; policy conflict → escalation; low confidence → human review; tool timeout → queue thủ công và kiểm state. Không tự hạ threshold để trả lời nhanh hơn.

Một câu trả lời tốt cũng cần nói rõ giới hạn: “Mình tìm thấy policy v2.1 cho plan này, nhưng chưa xác minh được order đang ở trạng thái nào.” Câu đó có thể chậm hơn một reply chắc nịch, nhưng giúp support biết phần nào cần kiểm tiếp. Nếu khách hỏi ngoại lệ, copilot không nên tự “chiều” khách; nó ghi request, policy liên quan và chuyển đúng owner. Nhờ vậy, escalation có bằng chứng, còn nhân viên không phải bắt đầu lại từ đầu.

NIST AI RMF đặt govern, map, measure và manage xuyên vòng đời; với support copilot, owner và escalation policy phải có trước khi xem demo là thành công. NIST AI RMF Core

6. Practice Bridge 15 phút

Bắt đầu từ đâu

Mở Google Sheets hoặc notes miễn phí, tạo bốn ticket giả và đặt timer 15 phút. Case 1 đủ order/tenant; case 2 thiếu order; case 3 có PII; case 4 có hai policy version conflict. Không gửi message, không dùng transcript thật và không gọi refund/payment.

Mẫu đối chiếu đã điền

Kết quả mong đợi là map được mỗi ticket tới state và owner, không phải làm copilot trả lời nhanh nhất. Nếu bạn không biết policy nào có hiệu lực, ghi UNKNOWN và dừng. Nếu reviewer sửa gần như mọi draft, đó là tín hiệu cần xem lại context contract hoặc acceptance criteria.

7. Tổng kết: gợi ý nhanh, quyết định có người

a. Năm ý chính

• Support copilot gợi ý cho nhân viên; nhân viên vẫn quyết định, chỉnh sửa và gửi.
• Context contract phải giữ đúng ticket, tenant, order, policy version, language và boundary dữ liệu.
• State NEEDS_REVIEW/ESCALATED là cơ chế an toàn, không phải lỗi cần che.
• Groundedness, policy correctness, escalation quality, PII safety và audit quan trọng hơn tỷ lệ draft được gửi.
• Thiếu field, tenant mismatch, policy conflict, PII, low confidence hoặc timeout phải hỏi, block, redact hay handoff.

b. Câu hỏi tự kiểm tra

• Copilot khác chatbot tự trả lời ở quyền nào?
• Vì sao tenant field cần trước retrieval?
• Khi policy version xung đột, state nào phù hợp?
• Metric nào giúp phát hiện automation bias?

c. Gợi ý đáp án

Xem gợi ý câu 1

Copilot ở workbench của nhân viên và không tự send; chatbot có thể đối thoại trực tiếp với customer. Xem lại mục 1.

Xem gợi ý câu 2

Tenant field giúp tách account/data scope; thiếu hoặc mismatch có thể làm lộ dữ liệu và phải block retrieval. Xem lại mục 2.

Xem gợi ý câu 3

NEEDS_REVIEW hoặc ESCALATED, giữ cả source/version để policy owner quyết định; không tự chọn bản thuận tai. Xem lại mục 3 và mục 5.

Xem gợi ý câu 4

Xem reviewer correction, send approval và escalation quality thay vì chỉ nhìn tỷ lệ draft được gửi. Xem lại mục 4.

d. Thuật ngữ cần nhớ

e. Nguồn tham khảo

• Microsoft search and tool use architectures — search, skills, tools và boundary.
• OpenAI Agents guide — tools, guardrails, state và tracing.
• NIST AI RMF Core — governance, measurement và lifecycle.
• Azure RAG evaluation — groundedness và evaluation nhiều chiều.

Bài trước là Case Study: Content Production Agent #14. Bài tiếp theo là Case Study: Coding Agent #16.

Lưu ý giáo dục: Hãy giữ support copilot ở draft/read-only cho tới khi context, policy, PII, reviewer và escalation state rõ. Không dùng ticket thật hoặc tự gửi message từ bài tập này.