Agent công việc: thử nhỏ trước khi mua lớn

Agent công việc: thử nhỏ trước khi mua lớn

Đừng chọn AI assistant vì demo biết làm nhiều việc. Hãy chọn bằng một hồ sơ thử nghiệm: việc nào đáng giao, đo ra sao, khi nào phải dừng.

“Em chỉ cần AI giúp sales bớt nhập CRM thôi, sao vendor demo xong thành nguyên phi thuyền vậy chị?”

Một bạn lead sales nhắn mình câu đó sau buổi xem demo assistant mới. Màn hình thì mượt: hỏi lead nào nên gọi trước, AI trả lời; bảo soạn email, AI viết; nhắc cập nhật pipeline, AI làm tiếp. Nhìn qua rất đã. Nhưng nếu bạn là người phải triển khai thật trong team, câu hỏi không phải là “tool này thông minh cỡ nào?”. Câu hỏi khó hơn là: việc nào đủ lặp, đủ đau, đủ đo được để giao cho AI mà không biến cả team thành đội sửa lỗi cho nó?

Amazon Quick đang được đẩy như một agentic AI teammate — hiểu nôm na là trợ lý AI không chỉ trả lời, mà còn có thể đi qua nhiều bước để biến câu hỏi thành hành động trong công việc. Với sales, lời hứa nghe rất đúng chỗ đau: bớt nhảy qua lại giữa CRM, email, research prospect, dashboard. Meta cũng đang đưa assistant vào luồng làm việc của creator. Google AI Mode thì tiến từ trả lời sang thao tác trong app như Instacart, Canva, YouTube. Claude Reflect lại thêm lớp dashboard để người dùng nhìn lại mình đang dùng AI vào việc gì.

Nhìn rộng ra, đây không còn là cuộc đua “chatbot nào nói hay hơn”. Đây là cuộc đua ai chen được vào workflow hằng ngày mà ít gây ma sát nhất.

Sơ đồ minh họa cho bài Agent công việc: thử nhỏ trước khi mua lớn

Sơ đồ tóm tắt ý chính của bài viết.

Hiện trường thật: AI assistant đang rời khỏi ô chat

Trước đây, nhiều team dùng AI kiểu mở một tab riêng, copy dữ liệu từ hệ thống A, dán vào chatbot, rồi copy kết quả sang hệ thống B. Cách này giống điều tra viên phải chạy qua ba căn phòng chỉ để xem một dấu vân tay: làm được, nhưng mệt và dễ rơi mất manh mối.

Các release mới đang đi theo hướng ngược lại: đưa assistant vào nơi công việc vốn đã diễn ra.

CRM là hệ thống quản lý quan hệ khách hàng; trong thực tế, nó thường là nơi sales phải nhập ghi chú, trạng thái deal, lịch sử tương tác. Dashboard là màn hình theo dõi chỉ số để ra quyết định nhanh. Tool calling là khả năng AI gọi công cụ hoặc API thay vì chỉ trả lời bằng chữ. Ba thứ này gặp nhau thì assistant bắt đầu có quyền đụng vào công việc thật.

Và đây là điểm nhiều team dễ hiểu sai: assistant càng làm được nhiều việc không có nghĩa là nên bật nhiều việc ngay từ đầu.

Mổ xẻ lời hứa: “từ câu hỏi đến kết quả” gồm ba lớp

Một demo agent công việc thường nén mọi thứ thành một câu chuyện liền mạch: bạn hỏi, AI hiểu, AI hành động, kết quả xuất hiện. Nhưng dưới lớp sơn bóng đó có ba lớp cần soi riêng.

Lớp 1: tìm thông tin đúng.
Assistant phải biết lấy dữ liệu từ đâu: CRM, email, tài liệu sản phẩm, dashboard pipeline, lịch sử khách hàng. Nếu dữ liệu lộn xộn, AI chỉ đang soi đèn pin vào một hiện trường chưa niêm phong.

Lớp 2: đề xuất hành động hợp lý.
Ví dụ: lead nào nên gọi trước, email nên nhấn mạnh pain point nào, account nào có dấu hiệu nguội. Đây là phần cần tiêu chí kinh doanh rõ. Nếu team bạn chưa thống nhất thế nào là “lead tốt”, AI sẽ học theo sự mơ hồ đó.

Lớp 3: thực hiện hoặc cập nhật hệ thống.
Đây là phần nhạy cảm nhất. Soạn draft email khác với gửi email. Gợi ý cập nhật CRM khác với tự sửa dữ liệu trong CRM. Một cái là hỗ trợ, một cái là quyền ghi vào hệ thống vận hành.

Nói thẳng ra thì: đừng đánh giá assistant bằng số tính năng, hãy đánh giá bằng mức độ rủi ro của hành động mà nó được phép làm.

Một buổi thử đủ để biết có nên đi tiếp

Nếu là team Việt Nam cỡ nhỏ hoặc vừa, mình sẽ không bắt đầu bằng rollout toàn bộ sales org. Làm một bài test trong một buổi chiều là đủ để phát hiện 70% vấn đề vận hành ban đầu — không phải để kết luận thắng thua, mà để biết có đáng đào tiếp không.

Ví dụ cụ thể: giả sử team bạn có 5 sales, đang dùng CRM và mỗi người mất kha khá thời gian cho việc chuẩn bị trước cuộc gọi. Chọn một workflow — tức một chuỗi việc lặp lại trong ngày — để thử.

Workflow nên chọn

Chọn một trong ba việc này:

  1. Tóm tắt account trước cuộc gọi

Input: tên khách hàng, lịch sử tương tác, ghi chú CRM.
Output: 5 gạch đầu dòng: tình trạng deal, nhu cầu, rủi ro, câu hỏi nên hỏi, bước tiếp theo.

  1. Soạn email follow-up sau meeting

Input: note cuộc họp, sản phẩm quan tâm, deadline.
Output: draft email, chưa gửi tự động.

  1. Gợi ý lead ưu tiên trong ngày

Input: danh sách lead, ngày tương tác gần nhất, nguồn lead, quy mô cơ hội nếu có.
Output: top lead nên gọi và lý do.

Mình sẽ tránh ngay các workflow như “tự động cập nhật forecast”, “tự gửi báo giá”, “tự đổi stage deal”. Những việc đó có hậu quả dây chuyền nếu sai.

Cách chạy trong một buổi

Tạo một bảng nhỏ, không cần hệ thống phức tạp:

| Hạng mục | Cách ghi |
|---|---|
| Việc thử | Ví dụ: tóm tắt account trước cuộc gọi |
| Người thử | 2 sales, 1 sales ops |
| Dữ liệu dùng | 10 account thật nhưng bỏ thông tin quá nhạy cảm nếu cần |
| Kết quả mong muốn | Sales đọc xong biết nên hỏi gì trong cuộc gọi |
| Người duyệt | Sales owner xác nhận đúng/sai |
| Quyền của AI | Chỉ đọc và tạo draft, không ghi dữ liệu |

Sau đó chấm từng output theo 4 tiêu chí:

Đừng cần điểm số phức tạp. Chỉ cần đánh dấu: đạt, cần sửa, nguy hiểm. Nếu nhiều output rơi vào “nguy hiểm”, dừng quyền hành động lại.

Guardrail: đừng để assistant cầm bút ký thay bạn

Guardrail là hàng rào kiểm soát để AI không vượt quá phạm vi được giao. Với agent công việc, guardrail quan trọng hơn prompt hay ho.

Mình sẽ đặt bốn luật ngay từ ngày đầu:

1. Read trước, write sau.
Tuần đầu chỉ cho AI đọc dữ liệu và tạo draft. Chưa cho tự ghi vào CRM, chưa gửi email, chưa đổi trạng thái deal.

2. Mọi đề xuất phải có lý do.
Nếu AI bảo “gọi lead A trước”, nó phải nêu bằng chứng: tương tác gần đây, tín hiệu quan tâm, quy mô cơ hội, hoặc deadline. Không có lý do thì coi như chưa đạt.

3. Log lại output xấu.
Log là nhật ký hoạt động. Mỗi lần AI bịa, lấy nhầm account, viết email lệch giọng thương hiệu, hoặc đề xuất vô duyên, ghi lại mẫu lỗi. Đây là hồ sơ vụ án của bạn; không có nó thì tuần sau họp chỉ còn cảm giác mơ hồ.

4. Có nút dừng rõ ràng.
Nếu lỗi liên quan dữ liệu nhạy cảm, nhầm khách hàng, hoặc tự tin khẳng định điều không có trong CRM, dừng ngay workflow đó. Không sửa bằng cách “prompt thêm tí nữa” khi rủi ro thuộc về dữ liệu hoặc quyền truy cập.

Dấu hiệu nên scale, và dấu hiệu nên bỏ qua

Một assistant đáng scale không nhất thiết phải làm mọi thứ. Nó chỉ cần làm tốt một đoạn việc đủ đau.

Bạn có thể mở rộng nếu thấy các dấu hiệu này:

Ngược lại, nên tạm dừng nếu:

Ở đây Claude Reflect gợi một ý đáng học: analytics không chỉ để khoe dùng nhiều, mà để nhìn lại AI đang ăn vào phần nào của ngày làm việc. Với team, bạn cũng nên có “Reflect phiên bản nghèo”: mỗi tuần xem AI được dùng cho việc gì, lỗi gì lặp lại, việc nào nên giữ cho con người tự làm.

Còn Mobile Layout của Amazon Quick dashboards nhắc một chi tiết rất đời: nếu quyết định diễn ra trên điện thoại giữa hai cuộc họp, dashboard desktop đẹp mấy cũng chưa chắc dùng được. AI assistant cũng vậy. Nếu nó không nằm đúng nơi nhân viên đang làm việc, adoption sẽ chết vì bất tiện, không phải vì model dở.

Sau bài này, nên đổi cách nghĩ thế nào?

Đừng nhìn các release agent công việc như cuộc thi tính năng. Hãy nhìn chúng như một quyết định vận hành: giao việc nào, cho quyền đến đâu, đo bằng dấu hiệu gì, và dừng khi nào.

Nếu là mình, mình sẽ bắt đầu với một workflow đọc-nhiều-viết-ít, có người duyệt, có log lỗi, có tiêu chí scale sau một tuần. Khi assistant chứng minh được nó xử lý tốt phần việc nhỏ, lúc đó mới tăng quyền. Làm ngược lại thì giống điều tra chưa đủ manh mối đã vội kết án — nhanh thật, nhưng dễ bắt nhầm người.

AI assistant tốt không phải đứa nói “để em lo hết”; nó là đồng đội biết để lại dấu vết cho bạn kiểm tra. Và trong production, dấu vết đáng tin hơn màn trình diễn đẹp.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo