Làm thế nào để bán hàng khi người dùng không phải là người mua
(writings.founderlabs.io)- Trong tình huống 'người dùng sử dụng sản phẩm nhưng không phải là người có quyền thanh toán', điều cốt lõi là xác định ai thực sự nắm quyền hạn và sức ảnh hưởng
- Người ra quyết định có quyền thực tế có thể không phải là cùng một người với người mua hoặc người dùng đầu tiên
- Ở các tổ chức nhỏ, việc tiết kiệm thời gian là quan trọng, nên lập trình viên trực tiếp đưa công cụ vào sử dụng rồi thuyết phục cấp trên để đi đến mua hàng là khả năng lớn
- Ở các tổ chức lớn, các ràng buộc về bảo mật và quy trình rất mạnh, nên quyền quyết định mua thuộc về CTO hoặc ban lãnh đạo, và cần chu kỳ bán hàng dài
- Người có quyền mua không nhất thiết trùng với người nắm ngân sách; người cảm nhận rõ nhất giá trị sản phẩm và có thể thúc đẩy nó mới là mục tiêu then chốt
- Chiến lược hiệu quả là cung cấp dữ liệu cụ thể và tài liệu thuyết phục để người dùng có thể thuyết phục ban lãnh đạo, đồng thời hỗ trợ quá trình đó
- Thành công cuối cùng là thiết kế quy trình hỗ trợ để người dùng có thể đóng vai trò bán hàng nội bộ
Mở đầu – Điểm khởi phát của câu hỏi
- Nên tiếp cận thế nào khi người thực sự dùng sản phẩm và khách hàng đưa ra quyết định mua là hai người khác nhau?
- Bối cảnh là bán hàng phần mềm B2B, nơi thông thường lập trình viên thử sản phẩm trước, còn CTO hoặc Director of Engineering đưa ra quyết định cuối cùng
Câu hỏi cốt lõi về quyền lực
- Câu hỏi 'ai thực sự có quyền lực?' là điểm quan trọng nhất
- Không chỉ là quyền thanh toán bằng thẻ hay mức độ ưu tiên khi dùng thử sản phẩm, mà ảnh hưởng thực tế và động lực mới là yếu tố quyết định trong dòng chảy mua hàng
Các kịch bản theo cấu trúc tổ chức
Trường hợp tổ chức nhỏ: cấu trúc phẳng và ra quyết định nhanh
- Lập trình viên thường là người tìm hiểu sản phẩm và trực tiếp dẫn dắt việc triển khai
- Động lực chính của CTO là ra thị trường nhanh và lặp lại nhanh, nên đề xuất công cụ từ lập trình viên có ảnh hưởng lớn đến quyết định
- Mô hình lan rộng kiểu Trojan horse, trong đó lập trình viên nhanh chóng thử công cụ miễn phí rồi sau đó chuyển sang trả phí, xuất hiện khá thường xuyên
Trường hợp tổ chức lớn: bảo mật và tuân thủ là ràng buộc chính
- Tồn tại các ràng buộc ngoài yếu tố thời gian như bảo mật, và quyết định của lãnh đạo ảnh hưởng quan trọng đến toàn bộ quá trình
- Người dùng (lập trình viên) không được phép tự cài đặt hay tự mua, nên chu kỳ bán hàng dài và phức tạp
- Tiêu chí nhận thức về giá trị/rủi ro tập trung vào bảo mật và đầu ra cuối cùng hơn là UI/UX hoặc DX
Góc nhìn về ảnh hưởng thực sự và giá trị
- Người nắm ngân sách không phải lúc nào cũng là người có quyền lực thực chất
- Điều quan trọng là 'ai có đòn bẩy' và 'động lực của ai tác động mạnh nhất đến việc thúc đẩy quy trình'
- Cần nhìn thực tế để xác định ai là chủ thể thực sự có thể trao đổi giá trị tương xứng với mức giá
Ví dụ cụ thể về luồng đưa sản phẩm vào sử dụng
- Người dùng/lập trình viên đăng ký tài khoản sản phẩm
- Dùng thử miễn phí trong môi trường cục bộ
- Trực tiếp trải nghiệm giá trị chức năng thực tế (ví dụ: so sánh trước/sau Pull Request, làm nổi bật vấn đề)
- Nhận ra giá trị → kỳ vọng cải thiện hiệu suất công việc/tự động hóa
- Người dùng thuyết phục ban lãnh đạo về sự cần thiết
- Ban lãnh đạo kiểm thử nội bộ và xem xét ngân sách rồi phê duyệt hoặc từ chối
- Ban lãnh đạo phê duyệt mua cuối cùng
- Hoàn tất mua sản phẩm, tiếp tục lan rộng trong tổ chức
Câu hỏi về động lực của cả hai phía
- Xác định động lực cốt lõi khiến lập trình viên đề xuất công cụ (sự thuận tiện trong công việc, làm nổi bật năng lực cá nhân, đạt mục tiêu công ty, v.v.)
- Xác định động lực mua của ban lãnh đạo (tăng hiệu quả phát triển, đạt mục tiêu công ty nhanh hơn, v.v.)
- Nếu những động lực cốt lõi này tồn tại, có thể đề xuất chiến lược sau
Chiến lược ứng phó thực tế
- Cung cấp công cụ thuyết phục như báo cáo so sánh chính xác trước/sau để người dùng có thể thuyết phục ban lãnh đạo
- Trong quá trình này, điều quan trọng không phải là lời khuyên trừu tượng mà là kết quả dựa trên dữ liệu định lượng
- Những con số thực tế như "đã tiết kiệm được bao nhiêu thời gian so với cách làm trước đây" là chìa khóa để thuyết phục
- Tìm hiểu cuộc trò chuyện mua hàng thực tế diễn ra như thế nào thông qua phỏng vấn khách hàng (lập trình viên), từ đó giải quyết trước các điểm cản trở trong quá trình thuyết phục
- Nói cách khác, thay vì thuyết phục trực tiếp người có quyền mua, cần cung cấp mọi hỗ trợ về môi trường và tài liệu cụ thể để người dùng có thể thành công trong vai trò bán hàng nội bộ
- Trong quy trình này, thành công của người dùng gắn liền trực tiếp với thành công của nhà cung cấp (cấu trúc win-win cho người dùng - nhà cung cấp - lãnh đạo - công ty)
Kết luận và tóm tắt
- Chiến lược tốt nhất là hỗ trợ để người dùng thực hiện thành công vai trò bán hàng nội bộ của sản phẩm
- Cần tập trung vào việc cung cấp căn cứ định lượng và tài liệu giá trị cụ thể cần thiết để thuyết phục ban lãnh đạo
- Trước tiên phải phân tích kỹ cấu trúc ra quyết định theo quy mô tổ chức và các điều kiện ràng buộc
- Cuối cùng, cần nhấn mạnh rằng nếu người dùng thành công thì cả nhà cung cấp lẫn công ty đều cùng thành công
1 bình luận
Ý kiến trên Hacker News
Tôi rất ngán cảnh chỉ muốn tải một thứ gì đó mà lại bị yêu cầu cung cấp thông tin liên hệ, rồi ngay sau đó nhân viên sales liên tục gọi điện và gửi email, dù đã lịch sự từ chối vẫn phớt lờ và lặp đi lặp lại việc xin họp; tôi không có quyền mua, nhưng tôi hoàn toàn có thể lan truyền sự khó chịu đó trong nhóm, khiến hình ảnh sản phẩm xấu đi, và khi kỹ sư hỏi tôi có đề xuất gì không thì tất nhiên tôi sẽ kể những chuyện này, các trường hợp như vậy là Veeam, AWS, Keyence
Với tư cách là IT Manager, tôi gặp chuyện này gần như hằng tuần; khi không nhận được phản hồi từ tôi, họ vòng qua bằng cách gửi email ngẫu nhiên cho đồng nghiệp hoặc người khác trong công ty, và làm vậy thì rất nhanh sẽ khiến toàn bộ domain của họ bị chặn; ngoài ra tôi cũng mong họ đừng bắt xem demo chỉ để lấy một báo giá, vì nếu tôi đã tìm hiểu sản phẩm và cần thì có lẽ tôi cũng đã dùng thử rồi, nên việc đưa báo giá trước thay vì ép xem bài thuyết trình sales hay demo mới là hợp lý
Auth0 và Okta cũng gặp vấn đề tương tự; tôi thực sự có quyền mua và cả ngân sách, nhưng vì bị liên hệ quá mức nên đâm ra ghét luôn
Tôi rất thích khái niệm "sức mạnh của sự bất mãn"; kể cả có cho miễn phí đi nữa, nếu đội sales hay marketing quá nhiệt tình thì vẫn có thể khiến hình ảnh công ty xấu đi; phải liên hệ theo cách khách hàng muốn, chứ nếu chỉ làm theo cách họ muốn thì sẽ phản tác dụng; nhưng đây lại là bài toán khó về thiết kế incentive
Tôi từng trải qua những trường hợp cực đoan khi một số đội marketing SaaS gửi email mỗi 5~15 phút; đôi khi có thể chỉ là hành động bộc phát của một nhân viên, nhưng cũng có vẻ có những trường hợp cấp trên hoặc CEO trực tiếp cấu hình công cụ email marketing ở mức tối đa
Cũng phải thêm Microsoft vào danh sách này; để đăng ký thì phải tạo một "tài khoản chuyên nghiệp", mà để làm vậy thì lại không cho dùng tài khoản gmail, tạo ra rào cản gia nhập rất cao; có những lúc tôi muốn dùng trial 30 ngày để đánh giá sản phẩm mà còn không thể truy cập được chỉ vì vấn đề tài khoản; trial còn khó như vậy thì quy trình triển khai thực tế chắc tôi còn không dám tưởng tượng, nên chẳng có hứng dùng AI-based CRM, ERP, Dataverse, v.v.
Hiện tượng này bắt nguồn từ vấn đề Principal-Agent: ban lãnh đạo công ty nắm ngân sách, nhưng người thực sự dùng sản phẩm/công cụ lại là lập trình viên và nhân viên hiện trường; từ góc nhìn founder, người ta thường được khuyên phải biến người dùng thành đồng minh để họ thuyết phục lãnh đạo, và cốt lõi là vì không thể nói chuyện trực tiếp với người thực sự cầm thẻ tín dụng, nên phải hỗ trợ tối đa để người dùng có thể thuyết phục lãnh đạo, tức là khiến user/developer thực tế đóng vai trò sales; tuy nhiên cách tiếp cận này có thể áp dụng cho mô hình freemium chẳng hạn, nhưng trong các ngành như hệ thống bệnh viện và EHR (hồ sơ sức khỏe điện tử), nơi quyết định mua gần như hoàn toàn do quản trị viên đơn phương đưa ra, thì người dùng thực tế thậm chí còn không có cơ hội trải nghiệm sản phẩm, nên tôi tò mò không biết có cách nào vượt qua điều đó không
Ngoài thực tế hiện trường thì tình huống ngược lại cũng thường xảy ra; những salesman bóng bẩy nhắm vào người có quyền ngân sách, đồng thời chặn giao tiếp với người dùng thực tế và ký hợp đồng trước; đến lúc người dùng bày tỏ bất mãn và chỉ ra vấn đề thì tiền đã được trả rồi
Để thực hành lời khuyên kiểu "hãy cho người dùng cơ hội tốt nhất để thuyết phục lãnh đạo, và chỉ cần giúp họ có thể cho lãnh đạo biết về lựa chọn này cũng đã khiến họ nổi bật hơn", chúng tôi cũng từng làm riêng một "CEO Page" https://www.rsync.net/products/ceopage.html
Nói thêm về cách làm enterprise sales, ngay cả chính người ra quyết định đôi khi cũng không nắm rõ đúng power dynamic trong doanh nghiệp; những điều cần xem thêm là người này thuộc cost center hay thuộc bộ phận tạo doanh thu, họ đang thúc đẩy áp dụng công nghệ mới hay đang xử lý một sản phẩm đã được tiêu chuẩn hóa, và ai sẽ xem sản phẩm này là rủi ro hoặc mối đe dọa với quyền lực của họ; những thông tin này phải được phản ánh trong chiến lược xác định bán cho ai, tránh ai, và khi nào nên tiếp cận nhỏ lẻ hay quy mô lớn
Cách Slack và Postman hay dùng là kiểu tiếp cận: "96% đội của bạn đã dùng sản phẩm của chúng tôi rồi. Giờ mua chẳng phải là hợp lý sao?"
Nhưng rồi bạn sẽ nghe câu vặn lại: "Mọi người đã dùng cả rồi thì còn cần mua làm gì?"; đây là câu hỏi cho thấy mức độ lệch pha giữa buyer và user, đặc biệt lớn trong môi trường doanh nghiệp vừa và nhỏ
Đó cũng là lý do phần mềm được cung cấp miễn phí cho sinh viên
Trong các nhóm nhỏ bên trong tập đoàn lớn, chuyện này cũng xảy ra rất thường xuyên; nếu có đội bảo mật thì họ có thể xem việc sử dụng phân tán qua nhiều Slack workspace là vấn đề, nên lập luận kiểu "thay vì 400 người dùng 12 workspace khác nhau, hãy quản lý bằng một tài khoản chính thức duy nhất" sẽ phát huy tác dụng
Một ưu điểm ẩn của commercial open source hay các mô hình tương tự là khi mức độ chấp nhận của người dùng cá nhân tăng lên thì mức độ chấp nhận ở cấp công ty cũng tăng theo
Công ty tôi từng khởi nghiệp trước đây cũng từng đối mặt với vấn đề này; chúng tôi phải bán hàng cho đội developer, những người không có quyền quyết định mua thực sự, và với các công ty nhỏ hoặc những trường hợp ngoại lệ nơi người có quyền hiện diện thì chốt hợp đồng khá dễ, nhưng đa số là chu kỳ sales dài, phải thuyết phục cấp ra quyết định cao hơn về chuyện cost saving; cuối cùng quá trình này vừa lâu vừa có tỷ lệ thành công thấp, trở thành một trong những nguyên nhân chính khiến công ty thất bại; tôi rất vui vì kiểu câu chuyện này được bàn công khai nhiều hơn, vì nhiều doanh nghiệp nhỏ gặp phải nhưng lại có ít lời khuyên chính thống một cách đáng ngạc nhiên
Mô hình này hoạt động tốt khi người dùng có thể trực tiếp dùng sản phẩm và cùng thuộc một tổ chức; nhưng nếu người dùng không liên quan trực tiếp đến người ra quyết định, hoặc khó chứng minh tính hợp lý của việc mua (ví dụ như pop keyless entry cho ô tô), thì nên tiếp cận thế nào? Người lái xe thấy lợi ích rất lớn, nhưng từ góc nhìn của CTO Ford thì ngay cả lời mời họp cũng có thể bị xem là không cần thiết; trong tình huống như vậy, sau khi phát triển sản phẩm xong thì nên đưa ra thị trường thế nào, tôi muốn xin lời khuyên
Trong trường hợp như vậy, chiến lược bottom-up khá hấp dẫn; thay vì nhắm vào trụ sở Ford, việc bắt đầu bằng các đại lý xe cũ, gara sửa xe hoặc cửa hàng phụ kiện có thể hiệu quả hơn; lấy ví dụ thiết bị khởi động từ xa, người dùng cần nhưng hãng xe lại ít quan tâm, nên ban đầu thị trường được hình thành theo kiểu cross-sell ở các audio shop, rồi sau đó nhà sản xuất mới đưa vào như một tùy chọn; tôi cũng có trải nghiệm kiểu này với thiết bị chống trộm, và việc bắt đầu nhỏ để tạo dựng tệp khách hàng rồi dần tiếp cận các doanh nghiệp lớn tỏ ra hiệu quả
Một cách khác là nhấn mạnh rằng đối thủ cạnh tranh đã triển khai pop rồi để kích thích FOMO (nỗi sợ bị bỏ lỡ)
Trong enterprise thì không phải cứ bán cho CTO là xong; nếu là doanh nghiệp đóng vai trò thật sự cốt lõi như AWS hay Azure thì chỉ cần thuyết phục CTO và các kỹ sư chủ chốt là có thể thay đổi toàn bộ tổ chức, nhưng phần lớn phần mềm lại thường do line manager, director hoặc trưởng bộ phận quyết định; thậm chí mỗi phòng ban còn dùng phần mềm khác nhau, nên phải phân khúc target thật chi tiết
B2B2C marketplace đặc biệt thú vị; trong mô hình không thu phí từ user "B2B" mà chỉ lấy phí theo từng giao dịch, bạn sẽ tận dụng chính những user đó như một lực lượng sales phân tán; phải giúp từng user thu hút khách hàng B2C thông qua instance riêng của họ; từ góc nhìn đội ngũ khởi nghiệp, điều này đôi khi làm cảm giác có quá nhiều thứ phải xây và khá hỗn loạn, nhưng bù lại rào cản gia nhập ban đầu thấp, và mỗi khi một account truyền tải tốt giá trị đến khách hàng cuối thì doanh thu tự nhiên tăng mạnh
Đây cũng là câu chuyện công ty chúng tôi rất đồng cảm; chúng tôi xây dựng một API business intelligence liên quan đến entity resolution, mà vì kéo theo cả engineering, product và data science nên sự tách biệt giữa buyer và user trở nên phức tạp; các kỹ sư hiểu theo trực giác sự khó khăn của việc matching dữ liệu công ty phức tạp, nhưng các lãnh đạo thì chỉ nhìn nhận là dự án đang bị chậm; vì vậy gần đây cách tiếp cận kiểu "đội của bạn đang đổ hàng tháng trời vào việc matching dữ liệu" lại thuyết phục hơn; có một công ty đã cố tự xây suốt 10 năm mà đến giờ vẫn chưa chạy đúng; tất nhiên chúng tôi cũng cảm nhận rõ rằng cách tiếp cận sẽ khác nhau tùy công ty và bối cảnh
Một mô hình khác có thể là kiểu TikTok, chỉ đứng giữa và lấy phần trăm trên từng giao dịch