Ba ngoại lệ cũ quyết định email nào được gửi tự động

Bạn đã có một quy trình khá ổn: sau cuộc họp, AI đọc ghi chú, tạo danh sách việc cần làm và soạn email follow-up. Vấn đề xuất hiện ở bước cuối. Nếu nối thẳng đầu ra đó với nút Send, một lỗi nhỏ về người phụ trách, thời hạn hay cam kết có thể đi ra ngoài trước khi ai kịp nhìn thấy.

Thay vì hỏi “AI đã đủ chính xác để tự gửi chưa?”, hãy lấy những ngoại lệ bạn từng phải sửa và dùng chúng để quyết định trường hợp nào được phép đi qua bước gửi. Đây là bước khác với kiểm tra từng action item: bạn đang thiết kế ranh giới cho hệ thống.

Ví dụ dưới đây là dữ liệu giả lập để minh họa cách làm, không phải kết quả đo từ một hệ thống production.

Bắt đầu bằng ba record từng khiến bạn phải dừng lại

Giả sử nhật ký ngoại lệ của nhóm có ba trường hợp:

• Record A: ghi chú có việc “gửi bản giá mới”, nhưng không ghi ai phụ trách. AI điền tên người đã nói nhiều nhất trong đoạn đó.
• Record B: ghi chú nói “gửi lại vào tuần tới”, nhưng email AI tự chuyển thành “trước thứ Ba”.
• Record C: ghi chú có owner và deadline rõ, nhưng email thêm câu “chúng tôi cam kết hoàn tất toàn bộ migration trong tháng này” dù cuộc họp không có cam kết đó.

Ba record này hữu ích hơn một tỷ lệ accuracy chung. Chúng cho biết loại bằng chứng nào còn thiếu ngay trước hành động gửi. Nếu hệ thống không phân biệt được chúng, chưa nên cho nó quyền gửi tự động.

Đặt ranh giới theo dữ liệu, không theo độ tự tin của AI

Một rule đầu tiên có thể rất hẹp.

Auto-send chỉ khi người nhận đã được xác định từ danh sách tham dự hoặc trường dữ liệu tin cậy; owner và deadline đều có dòng nguồn tương ứng; email không thêm giá, phạm vi, lời hứa hay quyết định mới; và loại follow-up này đã từng qua kiểm tra mà không cần sửa nội dung quan trọng.

Draft-only khi thông tin cốt lõi có nguồn nhưng câu chữ vẫn cần người chịu trách nhiệm nhìn qua — chẳng hạn email gửi khách hàng hoặc lãnh đạo, hoặc nội dung có thể tạo kỳ vọng dù không thay đổi cam kết. Hệ thống được phép soạn và đặt vào Drafts, nhưng không được gửi.

Human-review khi thiếu bằng chứng cho owner/deadline/người nhận, có xung đột giữa các nguồn, hoặc bản nháp xuất hiện một cam kết mới. Nhánh này không nên được “AI tự sửa rồi thử lại cho tới khi qua”; nó phải dừng ở người có thẩm quyền quyết định.

Điểm quan trọng là route được quyết định bằng các trường có thể kiểm tra, không bằng câu như “model confidence > 90%”. Một mô hình có thể rất tự tin khi suy ra deadline không tồn tại trong ghi chú.

Chạy lại ba ngoại lệ cũ trước khi nối nút Send

Bây giờ dùng ba record trên như một regression test nhỏ.

Record A phải vào human-review vì owner không có nguồn. Record B cũng phải dừng vì deadline cụ thể là suy diễn. Record C có owner và deadline nhưng thêm cam kết mới, nên vẫn phải vào human-review. Nếu một trong ba record rơi vào auto-send, đừng chỉnh prompt để làm ví dụ “đẹp” hơn; hãy thu hẹp rule.

Sau đó thêm vài record bình thường đã từng được người kiểm tra chấp nhận mà không sửa phần quan trọng. Mục tiêu không phải đẩy càng nhiều email sang auto-send càng tốt. Mục tiêu là xem rule có tách được nhóm ít rủi ro khỏi những ngoại lệ đã biết hay không.

Bạn cũng nên giữ lại route cùng lý do, ví dụ human-review: missing_owner_source. Khi có lỗi mới, record đó trở thành một test mới cho lần sửa rule sau. Nhờ vậy, lịch sử vận hành dần biến thành bộ kiểm tra thay vì một danh sách sự cố bị quên.

Approval phải nằm trước hành động gửi

Nếu triển khai bằng Power Automate, Microsoft tài liệu hóa action Start and wait for an approval: flow gửi yêu cầu phê duyệt và chờ phản hồi trước khi các bước sau chạy. Microsoft cũng phân biệt nó với Create an approval, action tạo yêu cầu nhưng không tự chặn execution; muốn lấy phản hồi trước khi đi tiếp thì cần thêm Wait for an approval.

Điều đó quan trọng với nhánh human-review. Approval không nên là một thông báo gửi song song trong khi email bên ngoài đã được gửi. Hành động gửi phải nằm sau điều kiện phê duyệt, và bạn cần test một case bị Reject để xác nhận nhánh Send không chạy.

Tài liệu Microsoft chứng minh cơ chế approval/wait tồn tại trong Power Automate; nó không chứng minh routing rule ở bài này phù hợp với mọi tổ chức. Rule vẫn phải dựa trên loại dữ liệu, quyền hạn và hậu quả thực tế của nhóm bạn.

Đừng tự động hóa những gì chưa có người chịu trách nhiệm

Ngay cả khi regression test chạy đúng, một số follow-up vẫn nên ở draft-only hoặc human-review lâu dài: thông báo pháp lý, thay đổi giá, cam kết với khách hàng, dữ liệu nhạy cảm, quyết định nhân sự hoặc bất kỳ nội dung nào mà tổ chức yêu cầu phê duyệt.

Cũng đừng coi “không phải sửa trong 20 email gần nhất” là giấy phép mở toàn bộ quyền gửi. Khi loại cuộc họp, người nhận hoặc nguồn dữ liệu thay đổi, ranh giới cũ có thể không còn phù hợp. Hãy mở rộng auto-send theo từng lớp nhiệm vụ hẹp và giữ khả năng quay lại draft-only.

Bước trưởng thành ở đây không phải để AI viết email hay hơn. Đó là biến các lỗi đã gặp thành điều kiện có thể chặn hành động trước khi lỗi rời khỏi hệ thống. Khi ba ngoại lệ cũ đều bị định tuyến đúng và các case bình thường vẫn đi đúng đường, bạn mới có bằng chứng thực tế để cân nhắc cấp quyền gửi cho một phạm vi nhỏ.

Nguồn

• Microsoft Learn — Get started with Power Automate approvals: mô tả Start and wait for an approval và hành vi chờ phản hồi trước khi flow đi tiếp.
• Microsoft Learn — Differences between flow approval actions: phân biệt Start and wait for an approval, Create an approval và Wait for an approval.

Nguồn tham khảo

1. learn.microsoft.com
2. learn.microsoft.com