Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 1 — Inbox Triage là gì và tại sao Agent phù hợp

Đã đọc 0/7 mục · còn khoảng 4 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Vấn đề thật

Một người bán hàng nhận 120 email/ngày: đơn hàng, khiếu nại, spam, hóa đơn từ nhà cung cấp, newsletter, và vài email sếp gắn cờ khẩn. Họ mất 2 giờ mỗi sáng chỉ để đọc lướt và sắp xếp trước khi thật sự làm việc. Đó chính là inbox triage: hành động phân loại luồng email đến theo mức độ quan trọng và loại xử lý, giống như phòng cấp cứu phân loại bệnh nhân.

Triage KHÔNG phải là trả lời hết mọi email. Nó là quyết định: email này thuộc nhóm nào, khẩn tới đâu, ai xử lý, bước tiếp theo là gì.

Vì sao AI Agent hợp với bài toán này

Email là dữ liệu ngôn ngữ tự nhiên, không cấu trúc. Luật cứng kiểu "nếu tiêu đề chứa từ hoàn tiền thì gắn nhãn Khiếu nại" sẽ vỡ ngay khi khách viết "sản phẩm không như mong đợi". LLM đọc hiểu ngữ nghĩa nên phân loại linh hoạt hơn nhiều.

Một agent khác một prompt đơn lẻ ở chỗ nó có vòng lặp: nhận đầu vào → suy luận → gọi công cụ (gắn nhãn, tạo nháp, chuyển tiếp) → quan sát kết quả. Nó hành động trên hệ thống thật, không chỉ trả về văn bản.

Khung tư duy 4 câu hỏi cho mỗi email

Mọi agent triage tốt đều trả lời 4 câu hỏi này cho từng email:

  • Category (Loại) — Đơn hàng? Khiếu nại? Nội bộ? Spam? Hóa đơn?
  • Priority (Ưu tiên) — Khẩn / Bình thường / Có thể chờ.
  • Action (Hành động) — Trả lời? Chuyển tiếp? Lưu trữ? Bỏ qua?
  • Owner (Người/bộ phận xử lý) — Sales? Kế toán? Chính mình?

Ví dụ cụ thể

Email đến:

> Tiêu đề: "Đơn #4821 giao thiếu 1 sản phẩm, tôi cần gấp" > Nội dung: "Tôi nhận hàng nhưng thiếu 1 áo. Có sự kiện ngày mai..."

Agent suy luận và xuất ra một quyết định có cấu trúc:

{
  "category": "Khiếu nại đơn hàng",
  "priority": "Khẩn",
  "action": "draft_reply + forward",
  "owner": "Bộ phận CSKH",
  "reason": "Khách nêu deadline ngày mai + thiếu hàng"
}

Điểm mấu chốt: agent luôn nên xuất JSON có cấu trúc, không phải văn xuôi. Vì các bước sau (gắn nhãn, chuyển tiếp) cần đọc máy được.

Các bước để bắt đầu tư duy về agent của bạn

  • Xuất 1 tuần email cũ ra CSV để làm dữ liệu mẫu (30–50 email đại diện).
  • Tự tay phân loại chúng theo 4 câu hỏi trên — đây là "đáp án chuẩn" để sau này đo độ chính xác agent.
  • Liệt kê các category thực tế của riêng bạn (đừng dùng danh sách chung chung). Ví dụ shop online khác hẳn phòng nhân sự.
  • Xác định ranh giới an toàn: hành động nào agent được tự làm (gắn nhãn), hành động nào cần bạn duyệt (gửi thư).
  • Chọn 1 hộp thư thử nghiệm — đừng bao giờ thử lần đầu trên inbox công việc chính.

Checklist trước khi bước sang thiết kế

  • [ ] Đã có tập dữ liệu email mẫu đã gán nhãn tay.
  • [ ] Danh sách 5–8 category cụ thể của tổ chức.
  • [ ] Quy tắc phân biệt Khẩn vs Bình thường (viết thành câu).
  • [ ] Danh sách hành động cho phép và hành động cần duyệt.
  • [ ] Một tài khoản email test riêng.

Sai lầm thường gặp

  • Đòi agent làm mọi thứ ngay (đọc, phân loại, trả lời, gửi tự động) trong lần đầu. Hãy bắt đầu chỉ với phân loại + gắn nhãn, chưa gửi gì.
  • Category quá trừu tượng như "Quan trọng" / "Không quan trọng". Category phải hành động được: mỗi loại dẫn tới một việc rõ ràng.
  • Không có đáp án chuẩn. Nếu không tự gán nhãn tay trước, bạn không có cách nào biết agent đúng hay sai.
  • Bỏ qua email nhạy cảm (pháp lý, HR, tài chính) — cần đánh dấu "luôn chuyển người thật", tuyệt đối không để agent tự trả lời.
  • Lẫn lộn priority và category. Một khiếu nại có thể khẩn hoặc không; đó là hai trục riêng biệt.
Bài sau ta sẽ thiết kế kiến trúc agent và luồng dữ liệu từ inbox tới hành động.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi