Bài 6 — Phân phối đa kênh tự động: email, Slack/Telegram, in-app, wiki

Sinh xong chưa phải là xong

Bạn đã có 4 bản release notes theo đối tượng. Nhưng mỗi đối tượng nhận qua kênh khác, định dạng khác: email cần tiêu đề + HTML, Slack cần markdown ngắn, banner in-app cần 1 câu, Confluence cần cấu trúc đầy đủ. Việc định dạng lại và bấm gửi từng kênh là phần tốn thời gian còn lại — và cũng tự động hóa được.

Nguyên tắc: một nội dung, nhiều "đầu ra định dạng"

Agent không viết lại nội dung cho mỗi kênh — nó định dạng lại cùng một sự thật cho đúng khuôn kênh. Điều này giữ nhất quán và tránh ảo giác mới phát sinh khi "viết lại".

Ví dụ cụ thể + Prompt mẫu

Đầu vào: 4 bản release notes đã DUYỆT (không được thay đổi nội dung, chỉ định dạng).
Hãy xuất cho từng kênh:
1. EMAIL (khách hàng): dòng tiêu đề ≤60 ký tự + thân email HTML đơn giản,
   mở đầu 1 câu, danh sách gạch đầu dòng, kết bằng lời mời phản hồi.
2. SLACK (#product-updates): markdown ngắn, tối đa 6 dòng, có link "Xem chi tiết".
3. TELEGRAM (nhóm nội bộ): text thuần, ngắn gọn, không HTML.
4. IN-APP BANNER: đúng 1 câu ≤120 ký tự, kèm nhãn phiên bản.
5. CONFLUENCE (nội bộ): tiêu đề, mục lục, đầy đủ mục kỹ thuật + breaking change.
RÀNG BUỘC: không thêm nội dung mới; chỉ chuyển định dạng. Giữ nguyên số liệu.

Nối vào agent (mở rộng từ Bài 5)

Sau bước "người duyệt bấm Đã duyệt", agent chạy tiếp:

• Email: đẩy sang công cụ gửi mail (Mailchimp/SendGrid) ở trạng thái nháp để bạn bấm gửi.
• Slack/Telegram: đăng vào kênh tương ứng (đây là kênh nội bộ, rủi ro thấp — có thể tự đăng).
• In-app: ghi banner vào bảng cấu hình (như announcements trong hệ thống của bạn).
• Wiki: tạo trang Confluence mới theo template.

Mẹo phân tầng rủi ro: kênh nội bộ (Slack, wiki) có thể tự đăng; kênh ra khách (email, in-app) luôn dừng ở nháp chờ người bấm.

Các bước làm (numbered)

• Liệt kê kênh và khuôn định dạng chuẩn của mỗi kênh.
• Chuẩn hóa mỗi kênh thành một "formatter prompt" như trên.
• Phân tầng rủi ro: đánh dấu kênh nào tự đăng, kênh nào chờ duyệt.
• Nối các connector (email/Slack/Telegram/wiki) vào agent sau điểm duyệt.
• Chạy thử một release và kiểm định dạng từng kênh trên thiết bị thật (email mobile, banner in-app).
• Kiểm link: đảm bảo mọi link "Xem chi tiết" trỏ đúng, không 404.
• Lên lịch: gắn thời điểm gửi (ví dụ 10h sáng) thay vì gửi tức thì lúc nửa đêm.

Template: Ma trận phân phối (checklist tái dùng)

Sai lầm thường gặp

• Agent tự gửi email cho toàn bộ khách: nếu bản có lỗi, thiệt hại lớn và khó thu hồi. Email luôn dừng ở nháp.
• Định dạng vỡ trên mobile: email HTML phức tạp dễ lỗi. Ưu tiên định dạng đơn giản và test thật.
• Ảo giác khi "viết lại" cho kênh: nếu để AI viết lại thay vì định dạng lại, nó có thể thêm câu mới sai sự thật. Ràng buộc "chỉ đổi định dạng".
• Rò rỉ chéo kênh: vô tình đăng bản nội bộ (có chi tiết kỹ thuật/tên KH) vào kênh khách hàng. Gắn nhãn rõ ràng và kiểm đích đến.
• Phụ thuộc quá mức vào lịch tự động: nếu release bị hoãn phút chót mà agent vẫn gửi theo lịch → tin sai. Luôn có nút hủy/hoãn.

Điều rút ra

Phân phối đa kênh là "định dạng lại một sự thật", không phải viết lại. Phân tầng rủi ro (nội bộ tự đăng, ra khách chờ duyệt), test định dạng thật, và giữ nút hoãn — bạn khép kín vòng tự động mà vẫn an toàn.