Các bài trong khoáBài 26/30

30 bài

Domain 5: Context Management & Reliability·Task 5.2

Khi nào chuyển cho người, và xử lý yêu cầu mơ hồ

Ba trường hợp agent nên chuyển cho nhân viên, vì sao không dựa vào mức độ bực bội hay điểm tự tin, và phải làm gì khi tra ra nhiều khách trùng tên.

  • 8 phút đọc
  • Đối chiếu docs 02/11/2026
  • 3 nguồn

Đọc xong bạn nắm được

  • Nhận ra ba trường hợp agent nên chuyển cho nhân viên
  • Chuyển ngay khi khách đòi gặp người, nhưng vẫn tự giải quyết khi khách chỉ bực
  • Hiểu vì sao mức độ bực bội và điểm tự tin không dùng để quyết định chuyển được
  • Viết tiêu chí chuyển kèm ví dụ mẫu vào system prompt
  • Biết hỏi thêm thông tin khi tra ra nhiều người khớp

Một agent chăm sóc khách hàng tốt không phải là agent tự làm hết mọi việc. Nó cần biết lúc nào nên dừng lại và chuyển cho nhân viên. Việc chuyển này tiếng Anh gọi là escalation, hay động từ escalate to a human. Chuyển quá nhiều thì nhân viên quá tải, mà chuyển quá ít thì agent tự quyết những việc nó không có quyền quyết.

Bài này giúp bạn trả lời ba câu hỏi: dấu hiệu nào cho thấy nên chuyển cho người, dấu hiệu nào nghe hợp lý mà không dùng được, và nên làm gì khi yêu cầu của khách chưa đủ rõ.

Ví dụ xuyên suốt: agent của một chuỗi phòng gym

Một chuỗi phòng gym dùng agent để trả lời hội viên qua chat. Agent được dùng bốn tool:

  • find_member: tìm hội viên theo tên, có thể kèm số điện thoại.
  • freeze_membership: tạm dừng thẻ. Theo chính sách, mỗi năm được dừng tối đa 2 tháng.
  • refund_charge: hoàn lại một khoản đã trừ tiền.
  • escalate_to_staff: chuyển cuộc trò chuyện cho nhân viên, kèm một bản tóm tắt.

Trong một buổi sáng, agent nhận bốn tin nhắn:

  1. "Cho tôi nói chuyện với nhân viên."
  2. "Tháng này bị trừ tiền hai lần, bực quá!"
  3. "Tôi muốn chuyển thẻ còn 5 tháng cho em gái."
  4. "Tôi tên Nguyễn Thị Lan, muốn dừng thẻ 1 tháng."

Mỗi tin nhắn cần một cách xử lý khác nhau. Các mục dưới đây đi qua từng tin.

Ba trường hợp nên chuyển cho nhân viên

Đề thi gọi các trường hợp này là escalation triggers:

Trường hợpTrong ví dụAgent nên làm gì
Khách nói rõ muốn gặp ngườiTin 1Chuyển ngay, không tra cứu hay hỏi thêm gì trước
Chính sách không nói tới, hoặc nói không rõTin 3: chính sách có nói về dừng thẻ và huỷ thẻ, nhưng không nhắc gì tới chuyển thẻ cho người khácChuyển. Không tự đồng ý, cũng không tự từ chối
Đã thử mà không làm đượcGiả sử ở tin 2, refund_charge báo lỗi hệ thống hai lần liềnChuyển, ghi rõ đã thử những gì

Trường hợp thứ hai, đề thi gọi là policy gap (chính sách có khoảng trống), là chỗ dễ sai nhất. Chính sách không cấm chuyển thẻ, nhưng cũng không cho phép. Agent không có quyền tự quyết chuyện đó, dù câu trả lời nó nghĩ ra nghe rất hợp lý.

Bài viết Building effective agents của Anthropic cũng nói một ý tương tự: agent nên dừng lại chờ người khi gặp chỗ vướng, thay vì cố đoán.

Khách đòi gặp người, và khách chỉ đang bực

Hai tin nhắn đầu nghe có vẻ giống nhau, nhưng cách xử lý khác hẳn.

Tin 1: khách đã nói rõ muốn gặp nhân viên. Agent chuyển luôn. Không nói "để em kiểm tra trước đã", cũng không cố thuyết phục khách ở lại nói chuyện với agent.

Tin 2: khách đang bực, nhưng không đòi gặp ai. Bị trừ tiền hai lần là chuyện agent tự giải quyết được. Agent nên xin lỗi, nói sẽ kiểm tra và hoàn tiền, rồi làm. Nếu khách vẫn nói muốn gặp nhân viên, lúc đó mới chuyển.

Hai dấu hiệu nghe hợp lý nhưng không dùng được

Nhiều người nghĩ tới hai cách sau để quyết định khi nào chuyển. Cả hai đều không ổn:

Dấu hiệuVì sao không dùng được
Đo mức độ bực bội của khách (sentiment-based escalation), bực quá thì chuyểnBực không có nghĩa là ca khó. Tin 2 rất bực nhưng dễ giải quyết, còn tin 3 lịch sự mà vẫn phải chuyển
Cho model tự chấm mình chắc chắn bao nhiêu (self-reported confidence score, ví dụ thang 1–10), thấp quá thì chuyểnModel thường tự tin sai, nhất là ở đúng những ca khó. Đặt ngưỡng cho con số này không giúp agent hiểu ranh giới chính sách

Tài liệu của Anthropic về agent chăm sóc khách hàng có nhắc tới việc đo cảm xúc của khách lúc đầu và lúc cuối cuộc trò chuyện. Nhưng đó là để đánh giá chất lượng cuộc trò chuyện, không phải để quyết định chuyển. Tài liệu đó cũng gợi ý theo dõi tỉ lệ chuyển đúng, và nhắm từ 95% trở lên.

Viết tiêu chí chuyển vào system prompt

Cách sửa đúng là ghi tiêu chí chuyển (escalation criteria) thật cụ thể trong system prompt, kèm vài ví dụ mẫu cho cả hai phía: ca nên chuyển và ca nên tự làm. Cách đưa ví dụ mẫu vào prompt như vậy gọi là few-shot. Nếu chỉ có ví dụ của một phía, agent dễ nghiêng hẳn về phía đó.

Với agent phòng gym, đoạn system prompt có thể như sau:

Chuyển cho nhân viên (gọi escalate_to_staff) khi và chỉ khi:
1. Hội viên nói rõ muốn gặp nhân viên. Chuyển ngay, không tra cứu trước.
2. Yêu cầu không có trong chính sách, hoặc chính sách không rõ.
   Ví dụ: chuyển thẻ cho người khác.
3. Bạn đã thử xử lý mà công cụ báo lỗi nhiều lần.

Không chuyển chỉ vì hội viên bực bội hay yêu cầu có nhiều bước.

Ví dụ tự xử lý:
Hội viên: "Bị trừ tiền hai lần, bực quá!"
Bạn: xin lỗi, kiểm tra giao dịch, hoàn khoản bị trừ thừa.

Ví dụ chuyển:
Hội viên: "Cho tôi chuyển thẻ sang tên em gái."
Bạn: báo sẽ chuyển cho nhân viên, gọi escalate_to_staff.

Khi chuyển, bản tóm tắt gửi kèm nên đủ để nhân viên làm tiếp mà không phải đọc lại cả cuộc trò chuyện: mã hội viên, khách muốn gì, agent đã làm gì, vì sao chuyển. Cách viết bản tóm tắt này nằm ở bài 1.4.

Tra ra nhiều người trùng tên

Tin 4: agent gọi find_member với tên "Nguyễn Thị Lan" và nhận về ba hội viên. Agent không được tự chọn một người theo kiểu "chọn người đăng ký gần đây nhất" hay "chọn người ở chi nhánh gần nhất". Chọn sai là dừng thẻ của người khác.

Đề thi gọi tình huống này là multiple matches, và cách sai là heuristic selection (chọn theo một quy tắc đoán mò). Việc đúng là hỏi khách thêm một thông tin để biết chắc là ai (additional identifiers), như số điện thoại hoặc mã thẻ, rồi tra lại.

Gom cả bài lại, agent có thể kiểm theo thứ tự sau:

  1. Khách nói rõ muốn gặp nhân viên?Chuyển ngay, không tra cứu trước
  2. Chính sách không nói tới hoặc nói không rõ?Chuyển, kèm bản tóm tắt cho nhân viên
  3. Đã thử mà công cụ báo lỗi nhiều lần?Chuyển, ghi rõ đã thử những gì
  4. Tra ra nhiều hội viên khớp?Hỏi số điện thoại hoặc mã thẻ rồi tra lại
  5. Còn lạiTự xử lý; khách bực thì xin lỗi rồi đề nghị cách giải quyết

Nguồn

  1. Exam Guide CCAR-F v1.0, Task Statement 5.2(mở tab mới)
  2. Customer support agent (Claude Docs)(mở tab mới)
  3. Building effective agents (Anthropic)(mở tab mới)

Nắm rồi thì thử sức với đề

Xem khoá luyện thi
Khi nào chuyển cho người, và xử lý yêu cầu mơ hồ · Anthropic Exam Pro