Dashboard từ pull sang push: báo cáo chủ động thay vì mở màn hình chờ số

TL;DR: Dashboard kiểu pull — người quản lý tự mở màn hình dò số — có một lỗi thiết kế ẩn: nó biến con người thành cảm biến. Phần lớn lần mở màn hình, số liệu ổn; và đúng hôm bạn bận nhất, cái bất thường nằm im không ai nhìn. Mô hình push đảo chiều luồng thông tin: dữ liệu nằm im, quy tắc và agent giám sát theo ngưỡng, tin nhắn tự tìm đến đúng người phụ trách. Dashboard không chết — nó xuống làm lớp drill-down khi cần bóc sâu (nhận định của chúng tôi). Và với SME đang chạy Lark + n8n, mô hình push dựng được từ hôm nay, không cần đợi sản phẩm của ngày mai.

Đây là bài thứ năm trong series Agentic Operations. Bài trước: Lark có agent thật không: kiểm chứng MCP, Lark CLI, Aily/Workmates và 4 đường nối agent.

1. Căn bệnh "mở màn hình chờ số"

Hình dung một quản lý cấp trung của SME điển hình:

• 8 giờ sáng: mở CRM lướt pipeline, mở bảng công nợ xem khoản chưa đối soát, mở trang vận đơn xem đơn kẹt kho, lướt nhóm CSKH xem khách nào đang giận.
• 3 giờ chiều: lặp lại một vòng. Trước họp weekly: lần nữa cho chắc.

Từng dashboard đều có lý do tồn tại. Vấn đề không phải dashboard xấu — vấn đề là mô hình pull: thông tin đứng yên, con người phải chủ động đến lấy. Pull đặt lên vai quản lý ba việc không thuộc vai họ:

1. Nhớ mở. Việc hệ thống "phát hiện" bất thường phụ thuộc vào chuyện một con người có mở màn hình hôm đó hay không.
2. Nhớ ngưỡng. Con số nào là bình thường, con số nào là dấu hiệu — nằm trong đầu từng người, không nằm trong hệ thống.
3. Coi như có người coi. Dashboard càng nhiều, mỗi người càng tin "chắc có ai đó cũng đang xem" — và kết thúc bằng không ai chịu trách nhiệm theo dõi cái nào.

Chi phí lặng lẽ nhưng thật: thời gian quét những con số đang ổn, và rủi ro bỏ sót đúng bất thường xuất hiện vào hôm bận nhất tháng. Đây là căn bệnh "chết chìm trong dashboard" mà chúng tôi gặp nhiều nhất khi khảo sát quy trình báo cáo của khách.

2. Mô hình push: tin đến tìm người, thay vì người đi tìm tin

Push giữ nguyên dữ liệu, giữ nguyên dashboard — chỉ đổi một thứ: ai chủ động. Dữ liệu nằm im trong system of record; quy tắc và agent giám sát theo ngưỡng; khi có việc cần quyết định, tin nhắn tự đến đúng người phụ trách.

Một tin nhắn buổi sáng trong nhóm vận hành có thể trông như thế này:

Báo cáo 6h30 — 3 việc cần xử lý hôm nay:

1. 3 deal chậm tiến độ so với SLA đã cam kết, đã nhắc sale phụ trách.
2. 1 khách hàng lớn không tương tác trong thời gian bất thường so với tần suất cũ — cần người nhìn lại.
3. 2 khoản công nợ chưa đối soát sau kỳ hạn chốt — kèm link từng phiếu.

Chi tiết từng việc: [link drill-down].

(Ví dụ minh hoạ do chúng tôi soạn — không phải số liệu thật từ hệ thống nào.)

Điểm khác của tin nhắn này so với một dashboard không nằm ở "đẹp hơn" mà ở ba tính chất:

• Có ngưỡng rõ ràng: mỗi dòng sinh ra vì một quy tắc cụ thể bị kích hoạt, không phải vì "đến giờ tổng hợp hết mọi thứ".
• Có người nhận rõ ràng: tin đến nhóm hoặc cá nhân chịu trách nhiệm xử lý, không đến "tất cả mọi người".
• Mỗi dòng là một việc, không phải một màn hình: người đọc xong tin là biết bước tiếp theo làm gì với ai.

Một cảnh báo: push không phải cảnh báo mọi thứ. Không ngưỡng, không người nhận rõ, push chỉ tạo ra một inbox thứ hai đốt thời gian như dashboard cũ. Push chỉ sống khi khan hiếm có chủ đích.

3. Dashboard không chết — nó xuống làm lớp drill-down

Đừng đọc bài này thành "xoá hết dashboard". Khi cảnh báo đã đến, việc kế tiếp là bóc sâu: lọc theo người bán, nhóm theo khách hàng, so với kỳ trước, xem từng bản ghi. Dashboard mạnh đúng ở chỗ đó — và còn mạnh lâu.

Cái đổi là vai trò: dashboard chuyển từ giao diện chính để canh số thành lớp phân tích tra cứu khi cần bóc sâu (nhận định của chúng tôi). Cùng một chuyển dịch mà phần 1 của series đã bàn với giao diện CRM và phần 3 đã bàn với chat: giao diện mỏng đi, việc đến tay người qua hội thoại. Không có số liệu nào chứng minh tốc độ chuyển dịch — nhưng logic nhất quán ở cả ba lớp: con người bỏ dần vai "cảm biến", giữ vai người ra quyết định.

4. Dựng push hôm nay với n8n + Lark IM/Base (khái niệm, chưa cần code)

Phần thực dụng nhất của bài. Toàn bộ mô hình push trên đây dựng được bằng n8n + Lark IM/Base ngay với hạ tầng SME đang có, theo năm mảnh ghép:

1. Một nguồn dữ liệu đáng tin. Push đặt ngưỡng trên dữ liệu — nếu dữ liệu bẩn, cảnh báo chỉ là nhiễu được đóng khung đẹp. Nên rà chất lượng dữ liệu trước khi đặt ngưỡng (chúng tôi đã viết cách audit chất lượng dữ liệu LarkBase bằng AI). Dữ liệu rải nhiều hệ thống thì gom về một kho trung gian trước — ví dụ kiểu upsert dữ liệu LarkBase lên BigQuery bằng n8n.
2. Scheduled digest. Workflow chạy theo lịch, tổng hợp vài con số cốt lõi và gửi vào nhóm Lark buổi sáng — kiểu chúng tôi đã triển khai cho chuỗi F&B (báo cáo sáng cho chuỗi mỗi sáng). Digest là bước push dễ nhất: không cần ngưỡng, chỉ cần gom và tóm tắt.
3. Ngưỡng cảnh báo. Từ digest nâng lên: quy tắc if-then chạy theo lịch hoặc webhook — vượt ngưỡng thì nhắn đúng người phụ trách, kèm link đến bản ghi gây cảnh báo. Ngưỡng viết ra hệ thống thay vì nằm trong đầu người.
4. Từ cảnh báo đến hành động phải có người duyệt. Nhắc việc nội bộ thì để agent làm luôn; nhưng hành động đụng đến khách hay đụng đến tiền thì phải qua phiếu duyệt — ranh giới này là chủ đề của phần cuối series.
5. Log mọi tin đã push. Mỗi cảnh báo để lại dấu vết: gửi ai, ai xử lý, kết quả gì — để không quay lại tình trạng cảnh báo chìm.

Một lưu ý về công nghệ: phần lớn push bắt đầu bằng quy tắc, không cần AI. If-then rẻ, đo được, ai cũng đọc được. Agent/LLM vào đúng chỗ quy tắc không phủ: tóm tắt diễn biến, đọc tin nhắn tự do, gán việc cho người phù hợp. Mô hình này bền chính vì thế: không phụ thuộc năng lực "thông minh", phụ thuộc kỷ luật đặt ngưỡng.

5. Việc nào đáng push, việc nào để pull: tần suất kiểm × chi phí bỏ sót

Không phải gì cũng đẩy thành push. Phép phân loại đơn giản nhất chúng tôi dùng: ghép tần suất phải kiểm với chi phí nếu bỏ sót.

Hai lưu ý: "chi phí bỏ sót" mỗi doanh nghiệp tự đánh giá theo nghiệp vụ; và hãy ép push giữ độ khan hiếm — mỗi cảnh báo không ai đọc là một bước biến kênh push thành dashboard thứ hai, rồi lại chết chìm.

6. Tín hiệu từ hội nghị: cùng một cơ chế, ở quy mô trang trại

Một dữ kiện tham chiếu: tại hội nghị Feishu Future 2026 (15/09/2026), phần trình bày về bốn trụ cột đưa AI vào doanh nghiệp kể ví dụ về một trang trại bò sữa (mốc 02:02–02:18 trong video): dữ liệu nằm rải nhiều hệ thống, khó nhận biết bất thường kịp thời. Cách AI tham gia, theo diễn giả: kết nối thông tin giữa các hệ thống và dùng Agent báo cho người phụ trách khi có vấn đề. Mô tả này do diễn giả công bố tại sự kiện, chưa kiểm chứng độc lập.

Tính năng được công bố tại sự kiện Feishu (thị trường Trung Quốc) ngày 15/09/2026; chưa kiểm chứng tính sẵn có trên LarkSuite quốc tế và tại Việt Nam.

Ngành và quy mô khác SME Việt, nhưng cơ chế y hệt mục 2: dữ liệu rải nhiều nơi, agent đóng vai cảm biến và bộ định tuyến — bất thường tự tìm đến người chịu trách nhiệm, thay vì người ấy đi dò từng hệ thống. Điểm đáng học không phải công nghệ bên trang trại, mà là nguyên tắc: việc bất thường phải chủ động đến tay người phụ trách.

Tóm lại

• Pull biến con người thành cảm biến: phải nhớ mở, nhớ ngưỡng, và tin rằng "chắc có ai đó đang xem".
• Push đảo chiều: ngưỡng nằm trong hệ thống, tin nhắn đến đúng người, mỗi dòng là một việc.
• Dashboard không chết — xuống làm lớp drill-down (nhận định), cùng chuyển dịch "giao diện mỏng, tầng nền dày" của cả series.
• Dựng được hôm nay với n8n + Lark: nguồn dữ liệu tin được, digest, ngưỡng, duyệt hành động, log.
• Phân loại bằng tần suất kiểm × chi phí bỏ sót — và giữ push khan hiếm.

Phần cuối của series: Khi nào KHÔNG cho agent tự hành động — khi tin push đã đến và việc cần xử lý, ranh giới nào agent tự làm tiếp, ranh giới nào phải chờ người duyệt.