Product Management
Đăng nhập
ESC

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

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

Bài 5 — Phân loại & Định tuyến Ticket

Đã đọc 0/8 mục · còn khoảng 3 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.

Khi agent không deflect được, nhiệm vụ tiếp theo là đưa ticket đến đúng người, đúng độ ưu tiên. Định tuyến sai làm khách chờ lâu và nhân viên bực bội. Bài này bạn xây bộ phân loại đáng tin cậy.

Hai trục phân loại

  • Category (loại): ticket thuộc đội nào? Ví dụ: billing, technical, order, complaint, general.
  • Priority (độ ưu tiên): urgent / high / normal / low.
Mỗi (category, priority) ánh xạ tới một hàng đợi và một SLA (thời gian cam kết phản hồi).

Ma trận định tuyến (routing matrix)

                 urgent        high         normal       low
billing      → queue_bill_p1  queue_bill  queue_bill   queue_bill
technical    → oncall_eng     queue_tech  queue_tech   queue_tech
order        → queue_ops_p1   queue_ops   queue_ops    queue_ops
complaint    → team_lead      team_lead   queue_care   queue_care

Ma trận này là bảng tra cứu tĩnh do con người định nghĩa, không để LLM tự bịa tên hàng đợi. LLM chỉ xuất ra (category, priority); code của bạn tra bảng để lấy hàng đợi.

Prompt phân loại (tách riêng, model rẻ)

Dùng một lời gọi LLM chuyên biệt, đầu ra JSON gọn:

Phân loại ticket sau. Chỉ trả JSON.
Ticket: "{{noi_dung}}"

category: một trong [billing, technical, order, complaint, general]
priority: một trong [urgent, high, normal, low]
Tiêu chí urgent: mất tiền đang diễn ra, không đăng nhập được để làm việc gấp,
  vấn đề an toàn/sức khỏe, khách dọa hủy hợp đồng lớn.

Trả về: {"category": "...", "priority": "...", "confidence": 0-1, "reason": "..."}

Các bước triển khai

  • Định nghĩa taxonomy (danh sách category) khớp đúng cơ cấu đội thật — không nhiều hơn 6–8 loại lúc đầu.
  • Viết tiêu chí priority rõ ràng, đặc biệt định nghĩa "urgent" chặt chẽ để tránh lạm phát ưu tiên.
  • Xây routing matrix ánh xạ (category, priority) → queue.
  • Gọi LLM phân loại cho mỗi ticket cần route.
  • Áp cổng confidence: nếu confidence < 0.6, đẩy vào hàng đợi triage để người xem, thay vì đoán bừa.
  • Ghi lại dự đoán vs nhãn thật để đo routing accuracy hằng tuần.

Kết hợp luật cứng (không dựa hết vào LLM)

Một số quy tắc nên là code cứng, đặt TRƯỚC khi hỏi LLM:

def route(ticket):
    text = ticket.text.lower()
    # luật cứng ưu tiên
    if "không đăng nhập" in text and ticket.customer.is_enterprise:
        return "oncall_eng", "urgent"
    if any(w in text for w in ["dị ứng", "kích ứng", "sưng", "khó thở"]):
        return "team_lead", "urgent"   # an toàn sức khỏe
    # còn lại nhờ LLM
    cls = classify_with_llm(ticket.text)
    if cls.confidence < 0.6:
        return "triage", "normal"
    return MATRIX[cls.category][cls.priority]

Luật cứng bắt các ca sống-còn một cách xác định; LLM lo phần đa dạng còn lại.

Checklist định tuyến

  • [ ] Taxonomy khớp đội thật, ≤ 8 loại.
  • [ ] Định nghĩa "urgent" đủ chặt để không quá 10% ticket thành urgent.
  • [ ] Có hàng đợi triage cho ca confidence thấp.
  • [ ] Luật an toàn (sức khỏe, mất tiền) là code cứng, không phụ thuộc LLM.
  • [ ] Có bảng đo routing accuracy hằng tuần.

Sai lầm thường gặp

  • Quá nhiều category: 20 loại khiến cả LLM lẫn nhân viên nhầm. Bắt đầu ít, tách khi có dữ liệu.
  • Lạm phát urgent: Định nghĩa lỏng khiến 40% ticket "urgent", đội cháy, mất ý nghĩa ưu tiên.
  • Để LLM tự sinh tên hàng đợi: Nó sẽ bịa "queue_special" không tồn tại. LLM chỉ chọn từ enum; code tra bảng.
  • Không có đường thoát cho ca mơ hồ: Ép phân loại 100% ticket khiến ca khó bị gán sai. Hàng đợi triage là van an toàn.
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