AI & Automation (vnROM)

Cover image for Muốn AI lead scoring chạy thật trong n8n, hãy viết rubric trước khi chọn model
Mascot
Mascot

Posted on • Originally published at reddit.com

Muốn AI lead scoring chạy thật trong n8n, hãy viết rubric trước khi chọn model

#n8n #automation #ai #sales

Trong nhiều dự án tự động hóa có AI, phần dễ gây chú ý nhất thường là tên model: GPT-4, GPT-4o-mini, Claude, DeepSeek, hay một model mới nào đó. Nhưng case lead qualifier đang được bàn trong cộng đồng n8n nhắc lại một bài học rất thực tế: thứ quyết định hệ thống có chạy được trong vận hành hay không thường không phải model, mà là rubric.

Cụ thể, workflow được chia sẻ xử lý form inbound cho một SaaS logistics khoảng 220 nhân sự, khoảng 120 lead mỗi tuần. Trước đó, hai AE mất nhiều giờ để copy thông tin qua Apollo, đoán mức độ phù hợp, rồi đưa lead tốt vào Slack. Điểm đáng chú ý không nằm ở việc gọi GPT-4, mà ở chỗ scoring được ép về một bảng điểm rõ ràng chỉ khoảng vài dòng.

Rubric biến AI từ “đoán hay” thành “chấm có kiểm soát”

Một lỗi phổ biến khi làm AI lead scoring là đưa lead vào model rồi hỏi kiểu: “lead này hot hay không?”. Cách đó nghe nhanh, nhưng khi đưa vào team sales sẽ gặp vấn đề:

  • Không biết model dựa vào tiêu chí nào để chấm.
  • AE không thể phản biện từng điểm cụ thể.
  • Kết quả khó debug khi lead bị phân loại sai.
  • Workflow phía sau phải parse text tự do, dễ gãy.

Cách làm tốt hơn là viết rubric trước, sau đó để model áp rubric đó lên dữ liệu. Ví dụ trong case Reddit, điểm được chia như sau:

  • Title fit: 30 điểm
  • Industry match: 25 điểm
  • Company size: 20 điểm
  • Intent keyword trong message: 15 điểm
  • Tech stack fit: 10 điểm

Tổng 100 điểm, rồi chia tier:

  • Hot: từ 75 trở lên
  • Warm: 45 đến 74
  • Cold: dưới 45

Điểm hay là sales team có thể hiểu ngay vì sao lead được xếp hot. Nếu thấy sai, họ không cần tranh luận mơ hồ với AI. Họ chỉ cần hỏi: “title fit nên 30 điểm hay 20 điểm?”, hoặc “industry match này có thật sự đáng 25 điểm không?”.

Structured output là phần bắt buộc, không phải trang trí

Một điểm nữa đáng học là workflow trả về object có cấu trúc, ví dụ:

{
  "score": 82,
  "tier": "hot",
  "reason": "Lead có title phù hợp, ngành khớp ICP và message thể hiện nhu cầu rõ",
  "signals": ["VP Operations", "logistics", "mentions dispatch automation"]
}
Enter fullscreen mode Exit fullscreen mode

Khi output có cấu trúc, n8n downstream xử lý rất sạch:

  • Switch node chỉ cần đọc tier.
  • Slack message có thể hiển thị score, reason, signals.
  • CRM có thể lưu điểm và lý do vào field riêng.
  • Sau này audit lại được vì sao lead được đẩy cho sales.

Ngược lại, nếu để model trả về văn bản tự do kiểu “This looks like a pretty strong lead”, workflow sẽ phải đoán lại ý của model. Đó là cách tự tạo lỗi trong hệ thống automation.

Rubric nên ngu vừa đủ để vận hành được

Có một câu rất đúng trong case này: rubric không cần “thông minh” theo nghĩa học liên tục. Nó cần chỉnh được trong 30 giây, audit được và khiến team vận hành tin để hành động.

Với mình, đây là tiêu chuẩn tốt cho rubric trong workflow có AI:

  1. Mỗi tiêu chí phải quan sát được từ dữ liệu đầu vào.
  2. Tổng điểm và ngưỡng tier phải rõ.
  3. Người nghiệp vụ có thể sửa weight mà không phải viết lại workflow.
  4. Output phải có lý do ngắn gọn, không chỉ có điểm.
  5. Có log lại input, score, tier, reason để review định kỳ.

Nếu muốn làm chắc hơn, anh em có thể lưu rubric trong Google Sheet, Airtable, Supabase hoặc một config table. n8n đọc rubric trước, rồi mới gọi model. Như vậy sales lead hoặc ops lead có thể tinh chỉnh scoring mà không cần đụng vào canvas chính.

Một checklist triển khai thực tế trong n8n

Nếu anh em đang muốn làm lead qualifier tương tự, có thể bắt đầu theo khung này:

  • Trigger: form submission, webhook, email inbound hoặc CRM new lead.
  • Normalize data: chuẩn hóa title, company, domain, message, source.
  • Enrich nếu cần: company size, industry, website summary, LinkedIn data.
  • Load rubric: lấy rubric từ static prompt hoặc config table.
  • AI scoring: yêu cầu model trả JSON schema cố định.
  • Validate output: nếu thiếu score hoặc tier, đưa vào nhánh review thủ công.
  • Route: hot vào Slack hoặc CRM task, warm vào nurture, cold vào archive.
  • Log: lưu score, reason, model, rubric version và timestamp.
  • Review hàng tuần: so lead closed-won hoặc SQL với score để chỉnh weight.

Phần “rubric version” rất đáng làm. Khi đổi cách chấm, mình biết lead nào được chấm theo phiên bản nào, tránh việc so sánh dữ liệu cũ mới lẫn lộn.

Bài học vận hành

Case này không mới về mặt kỹ thuật, nhưng rất đáng chú ý vì nó đi đúng hướng sản phẩm nội bộ: dùng AI để thực thi một tiêu chuẩn rõ ràng, không dùng AI để thay thế tiêu chuẩn.

Trong automation doanh nghiệp, model là engine. Rubric mới là tri thức vận hành. Nếu rubric mơ hồ, model mạnh cũng chỉ tạo ra quyết định khó tin. Nếu rubric rõ, thậm chí model rẻ hơn vẫn có thể tạo ra workflow đủ ổn để giảm thời gian phản hồi, giảm thao tác tay và giúp team sales ưu tiên đúng lead hơn.

Điểm thực chiến nhất: trước khi hỏi “dùng model nào?”, hãy hỏi “team đang chấm lead bằng tiêu chí nào, và có viết nó thành bảng điểm được không?”. Nếu câu trả lời là chưa, đó mới là phần cần làm trước.

Top comments (0)