Khách cần tính năng chưa có: trả lời rõ mà không hứa thay đội sản phẩm

Buổi giới thiệu đang thuận lợi thì khách hỏi một tính năng chưa có. Câu “cái này bên em làm được” có thể giúp cuộc nói chuyện trôi tiếp, nhưng khiến khách đánh giá giải pháp trên một giả định sai. Hãy nói rõ trạng thái hiện tại, hỏi việc khách thực sự cần hoàn thành và chỉ đề xuất phương án đã được kiểm chứng.

Một ý tưởng trong lộ trình chưa phải cam kết về thời điểm, phạm vi hoặc giá. Tài liệu tiếp nhận yêu cầu tính năng của Mattermost cũng phân biệt thứ tự ưu tiên trong lộ trình với ngày phát hành đã cam kết. Sale cần phân biệt thông tin nội bộ có thể trao đổi với nội dung đã được phép cam kết cho khách.

Hỏi nhu cầu phía sau tên tính năng

“Xuất Excel” có thể là để gửi báo cáo, đối chiếu số liệu hoặc nhập sang phần mềm khác. Mỗi mục đích dẫn tới cách đánh giá khác nhau. Dùng câu hỏi tìm hiểu nhu cầu trước báo giá để ghi bốn điểm: người sử dụng, công việc, tần suất và hậu quả nếu chưa làm được.

Không dùng câu hỏi để làm nhẹ yêu cầu của khách. Nếu đó là điều kiện bắt buộc, ghi nhận đúng là điều kiện bắt buộc.

Bảng trạng thái để cả đội dùng cùng một cách nói

Trạng thái đã xác minh	Có thể nói	Không nên nói
Có sẵn trong phạm vi được kiểm tra	“Phiên bản này làm được bước A theo điều kiện B”	“Mọi trường hợp đều được”
Có cách làm thay thế đã kiểm thử	“Có phương án C, nhưng cần thêm bước D”	“Tương đương hoàn toàn”
Đang xem xét, chưa cam kết	“Bên em đã ghi nhận, hiện chưa có mốc cam kết”	“Chắc chắn có tháng tới”
Chưa hỗ trợ	“Hiện chưa đáp ứng yêu cầu này”	“Ký trước rồi bên em xử lý”

Bảng cần người phụ trách cập nhật và ngày xác minh. Nếu chưa biết trạng thái, trả lời rằng cần kiểm tra; không biến “chưa rõ” thành “có”.

Mẫu trả lời khi chưa đáp ứng

“Hiện phiên bản được giới thiệu chưa có […]. Em hiểu anh/chị cần nó để […]. Bên em sẽ kiểm tra phương án […] cùng bộ phận phụ trách. Trước khi có kết quả, mình chưa nên coi đây là phần đã được đáp ứng. Nếu đây là điều kiện bắt buộc để mua, em sẽ ghi rõ trong bảng tiêu chí.”

Chỉ đưa mốc phản hồi mà người phụ trách đã nhận việc. Mốc phản hồi kết quả kiểm tra khác với ngày phát hành tính năng.

Kiểm chứng phương án thay thế

Ví dụ giả lập: khách muốn chuyển dữ liệu sang một hệ thống khác mỗi ngày. Sản phẩm hiện chỉ cho xuất tệp thủ công. Sale không gọi đó là tích hợp tự động. Hai bên kiểm tra dữ liệu cần xuất, người thao tác, thời gian thực hiện và rủi ro sai định dạng. Nếu công việc thủ công không phù hợp, ghi nhận giải pháp hiện tại chưa đáp ứng.

Checklist thử phương án:

• Dùng tình huống đại diện do khách đồng ý, tránh dữ liệu nhạy cảm không cần thiết.
• Nêu rõ thao tác thêm, giới hạn và trách nhiệm vận hành.
• Để người dùng thực tế xác nhận kết quả, không chỉ người trình diễn.
• Ghi phần đạt, chưa đạt và điều kiện cần kiểm tra tiếp.
• Không ghép kết quả thử một trường hợp thành lời đảm bảo cho tất cả.

Nếu yêu cầu trở thành phần việc riêng, cần làm rõ phạm vi phát sinh, người có thẩm quyền quyết định và cách xác nhận trước khi đưa vào đề xuất.

Ghi nhận để đội sản phẩm có thể dùng

Mỗi yêu cầu nên có: công việc cần làm, mức độ bắt buộc, giải pháp đang dùng, giới hạn đã kiểm chứng, người cần phản hồi và tác động đến quyết định mua. Tránh chỉ ghi “khách muốn thêm chức năng X”. AI có thể giúp sắp xếp ghi chú, nhưng người phụ trách vẫn phải xác nhận trạng thái sản phẩm và lời gửi khách.

Nếu cơ hội dừng vì thiếu năng lực quan trọng, ghi nguyên nhân cụ thể vào bảng phân tích lý do mất đơn. Một ghi nhận trung thực giúp công ty quyết định tốt hơn nhiều so với một đơn “sắp thắng” dựa trên lời hứa chưa được duyệt.