Dòng phản hồi khách hàng vào đội sản phẩm

"Góp ý mãi không ai nghe"

Ở QuầyNhanh, câu này được nói ở mọi buổi họp với sales. Không phải vì PM không quan tâm. Phản hồi đến từ quá nhiều nơi: ticket CS, nhóm Zalo của nhân viên kinh doanh, đánh giá trên kho ứng dụng, bình luận khảo sát NPS. Không nơi nào được coi là kho chung. Khi một PM nghe về một vấn đề, thường là qua một tin nhắn chuyển tiếp, không biết bao nhiêu quán gặp phải, cũng không biết quán đó trả bao nhiêu.

Chị Mai đếm phản hồi của quý 3 ở QuầyNhanh:

Trung vị từ lúc phản hồi được ghi đến lúc nó tới đúng squad là 23 ngày. Nhiều phản hồi không bao giờ tới.

Ba bước của dòng thông tin khách hàng

Một dòng phản hồi tốt có ba bước, mỗi bước có người sở hữu rõ ràng:

flowchart TD
    A["Sales, CS, khảo sát, đánh giá ứng dụng"] --> B["Kho phản hồi chung"]
    B --> C["Gắn nhãn hằng tuần"]
    C --> D["Báo cáo insight một trang"]
    D --> E["Review insight hằng tháng"]
    E --> F["Gán cho squad"]
    E --> G["Loại, có ghi lý do"]
    F --> H["Báo lại người đã gửi"]
    G --> H

• Gom về một nơi. Sales và CS ghi phản hồi vào kho phản hồi bằng một biểu mẫu năm trường: quán nào, nói gì (nguyên văn), bối cảnh, mức nghiêm trọng theo khách, người ghi. Đánh giá ứng dụng và bình luận NPS được nhập tự động.
• Gắn nhãn và gom chủ đề. Mỗi tuần, người làm product ops dành khoảng hai giờ gắn nhãn: squad liên quan, chủ đề, loại (lỗi, thiếu tính năng, khó dùng, giá). Phản hồi trùng chủ đề được gom lại, kèm số quán và tổng phí thuê bao của các quán đó.
• Quyết định và báo lại. Buổi review insight hằng tháng quyết định mỗi chủ đề lớn được gán cho squad nào, hay bị loại có lý do. Rồi người đã gửi phản hồi được báo kết quả.

Bước 3 là bước bị bỏ nhiều nhất và quan trọng nhất. Sales ngừng ghi phản hồi không phải vì không bao giờ được làm, mà vì không bao giờ được trả lời.

Gom chủ đề và đo bằng số quán, không bằng số lần nhắc

Một quán lớn có thể gọi tổng đài năm lần về cùng một việc. Nếu đếm số lần nhắc, chủ đề đó trông lớn hơn thật. QuầyNhanh đếm theo số quán khác nhau và tổng phí thuê bao của các quán đó.

Báo cáo insight tháng 10 có ba chủ đề lớn nhất:

Chủ đề in phiếu bếp có nhiều lần nhắc nhất, nhưng xếp thứ hai về số quán. Con số không tự quyết thay người — chủ đề in phiếu bếp là lỗi làm quán mất khách ngay lúc đông nhất, nên vẫn được ưu tiên. Nhưng nhờ bảng này, cuộc thảo luận bắt đầu từ cùng một bộ dữ liệu thay vì từ ai nói to hơn.

Phản hồi là bằng chứng, không phải yêu cầu

Một lỗi thường gặp là biến kho phản hồi thành hàng đợi yêu cầu tính năng: khách xin gì, ghi đó, rồi đếm. Khách hàng giỏi mô tả vấn đề, không giỏi thiết kế giải pháp. Ba quán xin "nút xuất Excel" có thể thật ra cần báo cáo theo ca để đối chiếu tiền mặt với nhân viên.

Vì vậy biểu mẫu của QuầyNhanh bắt buộc trường "nói gì (nguyên văn)" và "bối cảnh", và nhãn chủ đề mô tả vấn đề, không mô tả tính năng. PM nhận chủ đề vẫn phải tự phỏng vấn khách trước khi quyết định giải pháp.

Báo lại — vòng khép kín

Mỗi chủ đề sau review insight nhận một trong ba trạng thái: đã gán cho squad (có tên PM), đang theo dõi (chưa đủ bằng chứng, xem lại tháng sau), hoặc không làm (có lý do). Người làm product ops gửi một tin tổng hợp cho sales và CS sau mỗi buổi. Với các quán lớn, sales tự gọi lại cho khách.

Sau một quý chạy dòng mới, trung vị từ phản hồi đến squad giảm từ 23 xuống 6 ngày, và số phản hồi sales ghi vào kho tăng lên, vì họ thấy phản hồi của mình đi đến đâu.

Ai sở hữu từng bước

Chú ý dòng thứ ba: product ops không quyết định chủ đề nào được làm. Họ đảm bảo quyết định được đưa ra, có bằng chứng, và được báo lại. Quyết định ưu tiên vẫn thuộc PM và Head of Product.

Làm ngay

Đếm phản hồi khách hàng của đội bạn trong tháng gần nhất theo từng nguồn, như bảng đầu bài. Chọn ba chủ đề nghe nhiều nhất và tính lại theo số khách hàng khác nhau và tổng doanh thu của họ. Thứ tự có đổi không? Rồi thiết kế biểu mẫu ghi phản hồi của bạn với tối đa năm trường, và chọn ngày cho buổi review insight đầu tiên.