# Hệ thống đã chạy nhưng không ai dùng: cách FDE đo và nâng adoption

> Dashboard báo xanh, pipeline không lỗi, nhưng người dùng của khách vẫn quay về bảng tính cũ. Đây là loại thất bại không có bug để sửa, và FDE vẫn phải tìm cho ra nguyên nhân.

Bản gốc: https://fdetimes.net/vi/bach-khoa/adoption-nhan-vien-khach-khong-dung-cong-cu-ai-ban-giao/

Buổi demo cuối dự án trôi chảy. Mô hình dự báo nhu cầu cho kết quả đúng, pipeline không lỗi, dashboard toàn màu xanh. Ba tuần sau, bạn mở log và thấy phần lớn planner vẫn xuất dữ liệu ra bảng tính cũ để tự tính.

Với một FDE, đây là kiểu thất bại khó chịu nhất, vì không có bug nào để sửa. Umbrex nhận xét rằng phần mềm doanh nghiệp hiếm khi tạo ra giá trị chỉ nhờ được cài đặt. Mô hình có đúng đến đâu, nếu planner không dùng thì giá trị nó tạo ra cho khách vẫn bằng không.

Vì thế, adoption là một phần của sản phẩm bàn giao, không phải việc bạn để lại cho người khác sau khi rời đi. Tryolabs đặt cho bước "Drive adoption" hai đầu ra cụ thể: một baseline số đo adoption và một đội champion nội bộ đã được đào tạo. Phần dưới đây hướng dẫn bạn làm ra cả hai.

## Bảng tính cũ đang làm được gì mà hệ thống của bạn chưa làm được?

Quay lại người planner ở trên. Bảng tính của họ không tồn tại vì người dùng bảo thủ. Umbrex đưa đúng ví dụ này: một supply planner vẫn bám vào bảng tính vì hệ thống ERP thiếu ngữ cảnh, và người dùng không đổi workflow chỉ vì có một hệ thống mới.

Bảng tính đang giữ một thứ mà hệ thống chính thức không có. Việc của bạn vì thế gồm hai phần. Phần đầu là đo trung thực để biết mình đang ở đâu. Phần sau là tìm ra đoạn còn thiếu giữa giải pháp và công việc hằng ngày của người dùng.

## Đăng nhập không có nghĩa là đang dùng

Sai lầm phổ biến nhất là đếm số lượt đăng nhập. Basedash nhấn mạnh rằng một người dùng chỉ được tính là "active" khi họ làm một hành động có ý nghĩa, và việc đăng nhập không được tính.

Mẫu số cũng quan trọng không kém.

Bốn chỉ số dưới đây đủ để làm baseline cho phần lớn dự án FDE:

| Chỉ số | Cách tính | Câu hỏi nó trả lời |
|---|---|---|
| Adoption rate | Số người làm hành động có ý nghĩa / tổng số người dùng dự kiến | Bao nhiêu người trong số cần dùng đã thực sự dùng? |
| WAU | Số người làm hành động có ý nghĩa trong 7 ngày | Có bao nhiêu người dùng đều đặn theo nhịp làm việc hằng tuần? |
| Activation rate | Số người đã hoàn thành hành động mở ra giá trị cốt lõi / số người bắt đầu dùng | Người mới có đến được "aha moment" không? |
| Time-to-value | Thời gian từ lần dùng đầu tiên đến lúc nhận được giá trị đầu tiên | Họ phải chờ bao lâu mới thấy giải pháp có ích? |

Basedash cho rằng với phần lớn sản phẩm B2B, WAU là chỉ số engagement chính hợp lý nhất. Lý do khá dễ hiểu: nhiều công việc ở doanh nghiệp chạy theo nhịp tuần, nên đo theo ngày dễ làm bạn đánh giá sai.

Basedash cũng đưa ra ngưỡng tham khảo cho DAU/MAU: trên 0.25 tức là người dùng trung bình mở sản phẩm ít nhất bốn ngày một lần, mức được coi là tốt với B2B. Dưới 0.10 là yếu.

**Điểm mấu chốt:** Đếm người làm ra giá trị, đừng đếm người chỉ đăng nhập.

## Một ví dụ: 40 planner, chỉ 6 người dùng thật

Thử hình dung một nhà phân phối có 40 planner được kỳ vọng dùng công cụ dự báo của bạn. Bạn định nghĩa hành động có ý nghĩa là duyệt hoặc chỉnh một đề xuất dự báo rồi đẩy nó sang đơn đặt hàng. Một truy vấn trên bảng sự kiện sẽ có dạng sau:

```sql
-- WAU theo hành động có ý nghĩa, mẫu số là người dùng dự kiến
SELECT
COUNT(DISTINCT e.user_id)                AS wau_meaningful,
(SELECT COUNT(*) FROM intended_users)    AS intended,
ROUND(COUNT(DISTINCT e.user_id) * 1.0
/ (SELECT COUNT(*) FROM intended_users), 3) AS adoption_rate
FROM events e
JOIN intended_users u ON u.user_id = e.user_id
WHERE e.event_type IN ('forecast_approved', 'forecast_edited_and_pushed')
AND e.created_at >= CURRENT_DATE - INTERVAL '7 days';
```

Giả sử tuần trước có 31 người đăng nhập. Nếu báo cáo theo đăng nhập, con số là 31/40, tức 77.5%, đủ để cả phòng vui vẻ. Nhưng truy vấn trên chỉ trả về 6 người. Adoption rate thật là 6/40 = 15%.

Tiếp theo, bạn tính DAU/MAU trên cùng định nghĩa. Giả sử trung bình mỗi ngày có 2 người làm hành động có ý nghĩa, và trong tháng có 16 người từng làm ít nhất một lần.

Tỷ lệ là 2/16 = 0.125, nằm giữa ngưỡng yếu 0.10 và ngưỡng tốt 0.25. Kết hợp lại, các con số cho thấy: nhiều người đã thử công cụ, nhưng ít người dùng nó thay cho cách làm cũ.

Con số cho bạn biết công cụ đang kẹt, nhưng không cho biết kẹt ở đâu. Invisible Technologies mô tả có những ngày FDE chỉ ngồi cạnh người dùng để hiểu quyết định thực sự được đưa ra như thế nào.

Giả sử khi ngồi cạnh một planner, bạn thấy chị ấy chép lịch khuyến mãi từ email của phòng marketing vào bảng tính, vì mô hình của bạn không biết tuần nào có khuyến mãi. Bảng tính đang chứa chính phần ngữ cảnh mà hệ thống còn thiếu.

Cách sửa lúc này nằm ở cả dữ liệu lẫn workflow. Bạn đưa lịch khuyến mãi vào làm feature, và hiển thị đề xuất ngay trên màn hình planner vẫn dùng để tạo đơn hàng, thay vì bắt họ mở thêm một tab khác.

Invisible Technologies gọi đây là thiết kế workflow phản ánh hành vi thật của người dùng. Sau đó, bạn chọn hai người trong nhóm 6 người đang dùng thật để đào tạo thành champion, vì đồng nghiệp tin lời đồng nghiệp hơn tin lời người của nhà cung cấp.

## Tự làm trong năm bước

1. Thống nhất với người bảo trợ dự án phía khách xem ai là người dùng dự kiến, và chốt danh sách đó thành một bảng dữ liệu.
2. Viết ra một câu định nghĩa hành động có ý nghĩa, rồi gắn event tracking cho đúng hành động đó trước khi go-live.

Chưa có event thì cũng chưa có baseline.
3. Tuần đầu sau go-live, chạy truy vấn để có adoption rate, WAU, activation rate và time-to-value. Gửi các con số này cho khách kèm định nghĩa, để không ai hiểu nhầm.
4.

Ngồi cạnh ít nhất ba người: một người dùng nhiều, một người đã thử rồi bỏ, và một người chưa từng mở công cụ.
5. Sửa đúng chỗ còn thiếu, đào tạo champion, rồi đo lại theo cùng định nghĩa để so sánh với baseline.

## Những lỗi khiến bạn tưởng mọi thứ đã ổn

Lỗi đầu tiên là chia cho số tài khoản thay vì số người dùng dự kiến. Nếu chỉ 10 trong 40 người được cấp tài khoản, tỷ lệ 100% trên 10 người vẫn che đi 30 người chưa bao giờ được tiếp cận. Lỗi thứ hai là dùng DAU cho một công cụ chỉ cần mở mỗi tuần một lần, rồi kết luận nhầm rằng người dùng không quan tâm.

Lỗi thứ ba là coi mọi vấn đề adoption là vấn đề đào tạo. Nếu bảng tính chứa ngữ cảnh mà hệ thống thiếu, mở thêm một buổi training cũng không giải quyết được gì. Lỗi cuối cùng là rời dự án khi chưa có champion: khi đó adoption sẽ giảm dần ngay khi bạn không còn ở đó.

Nếu bạn đang chuẩn bị chuyển sang FDE, hãy để ý trong JD những cụm như "drive adoption" hay "user enablement".

Trong CV, thay vì ghi "triển khai hệ thống X", hãy ghi bạn đã nâng số người làm một hành động cụ thể mỗi tuần từ bao nhiêu lên bao nhiêu, trên tổng số người dự kiến.

Một dòng như vậy cho thấy bạn hiểu rằng cài đặt xong chưa phải là xong việc.

Một dự án chưa thể coi là hoàn thành khi mô hình đã chạy. Nó chỉ hoàn thành khi người planner không còn cần mở bảng tính cũ nữa.

**Thử ngay tuần này:**

- Với một hệ thống bạn đang vận hành, viết ra một câu định nghĩa hành động có ý nghĩa, rồi chạy một truy vấn đếm WAU theo hành động đó, không đếm theo đăng nhập
- Xin 60 phút ngồi cạnh một người dùng đang làm việc thật. Ghi lại mỗi lần họ mở một công cụ khác ngoài giải pháp của bạn, và họ mở nó để làm gì
- Viết lại một dòng trong CV theo dạng 'nâng số người dùng làm [hành động] mỗi tuần từ X lên Y trên tổng Z người dự kiến'

## Nguồn

- [Forward Deployed Engineers | Tryolabs](https://tryolabs.com/services/forward-deployed-engineers)

- [When the FDE Model Creates Value (The Forward Deployed Engineer Playbook, Umbrex)](https://umbrex.com/resources/the-forward-deployed-engineer-playbook/when-the-fde-model-creates-value/)

- [What is Forward Deployed Engineering? A guide to the role, benefits, and real enterprise examples](https://invisibletech.ai/blog/what-is-forward-deployed-engineering)

- [B2B SaaS product metrics: DAU, WAU, MAU, activation, and engagement scoring | Basedash](https://www.basedash.com/startup-metrics/product-metrics)

- [20 Must-Track Product & User Adoption Metrics (2026)](https://whatfix.com/blog/product-adoption-metrics/)