Vui lòng ngừng cố lên lịch gọi điện với tôi
(matduggan.com)- Ngay từ lúc thử nhẹ một sản phẩm SaaS mới, email bán hàng, danh sách gửi thư và các yêu cầu gọi điện lặp đi lặp lại bắt đầu kéo đến, liên tục ngốn thời gian của người dùng
- Quy trình mua hàng lại bị kéo theo bản demo định sẵn và kiểu giới thiệu “everything platform”, thay vì một hai tính năng thực sự cần thiết; nhân viên bán hàng và kỹ sư bán hàng thì kéo dài các cuộc gọi
- Ở bước phê duyệt thanh toán, áp lực lôi kéo người ra quyết định cấp cao hơn vào cuộc gọi tăng lên; phê duyệt nội bộ thường mất ít nhất một tháng, còn ở các công ty Fortune 500 thì dù mọi thứ suôn sẻ cũng mất tối thiểu 3 tháng
- Sau khi mua, nhân viên bán hàng biến mất, để lại cho người dùng thực sự hỗ trợ khách hàng dựa trên LLM, SLA dài, cùng các giới hạn và chế độ lỗi không được ghi trong tài liệu
- Người phụ trách tài khoản tập trung bán thêm tính năng hơn là giải quyết vấn đề, và cuối cùng khi xuất hiện một giải pháp mã nguồn mở thay thế nhanh hơn, miễn phí, mọi chuyện kết thúc bằng việc không gia hạn hợp đồng và chia tay qua email
Những liên hệ bám theo sau bản dùng thử
- Một trong những rào cản lớn nhất khi dùng thử một dịch vụ hay sản phẩm mới là những liên hệ dai dẳng sau đó
- Ban đầu chỉ là một email vô hại kiểu “nếu có câu hỏi thì hãy cho chúng tôi biết”, nhưng chẳng mấy chốc một người phụ trách nào đó như “customer success fun-gineer” sẽ liên hệ để hỏi thăm trải nghiệm dùng thử
- Người dùng thường đăng ký chỉ để kiểm tra một tính năng cụ thể
- Nếu không có tính năng đó thì họ mất hứng thú và quên đi
- Nếu họ không còn đang đánh giá nữa, rất khó hiểu vì sao lại có người liên hệ
- Nếu còn nằm trong danh sách gửi thư, họ sẽ tiếp tục nhận thông báo về bản phát hành và ra mắt mới
- Dù không quan tâm, họ vẫn phải lần nào cũng cân nhắc hủy đăng ký vì có thể tính năng mình muốn đã được thêm vào
- Nếu không có ghi chú phát hành dễ truy cập, email marketing gần như trở thành con đường duy nhất để kiểm tra liệu tính năng đã được thêm hay chưa
Quy trình mua hàng biến thành “ta gọi một cuộc nhé”
- Trường hợp tệ nhất là khi thực sự có thể dùng dịch vụ, vì từ đó người dùng bị buộc vào một chuỗi cuộc gọi đã lên lịch
- Thay vì chỉ nhập số thẻ tín dụng trên website là xong, bạn phải xây dựng quan hệ với những người lạ trên Microsoft Teams
- Một đội ngũ bán hàng SaaS điển hình có hai vai trò
- Nhân viên bán hàng nhập dữ liệu vào CRM và liên tục thúc đẩy cho đến khi chốt được giao dịch
- Những người có chức danh như “sales engineer”, “customer success engineer” là số ít người thực sự đã đọc tài liệu, và giải thích sản phẩm như một “everything platform” mới
- Bản demo bao gồm cả những tính năng người dùng không muốn
- Người dùng chỉ đến để kiểm tra một hai tính năng, nhưng mẫu demo định sẵn thì không linh hoạt
- Nhân viên bán hàng cố làm dịu bầu không khí bằng vài lời khen nhẹ kiểu người dùng có vẻ rành kỹ thuật
- Demo của kỹ sư bán hàng bị hỏng đúng lúc không hay, rồi sau đó là lời giải thích rằng “bình thường nó chạy tốt”
Bảo mật, tuân thủ và phê duyệt kéo dài
- Đến một thời điểm nào đó, nếu hỏi về tuân thủ và bảo mật, bạn sẽ nhận được một tập chứng chỉ vô nghĩa
- Tài liệu chứng nhận được đối xử như thứ cho thấy họ có thể trông như đã thực hiện các hạng mục một cách có vẻ hợp lý, hơn là bằng chứng rằng họ thực sự đã làm
- Sau khi demo và xây dựng quan hệ xong, đội ngũ bán hàng cố đưa người ra quyết định cấp cao hơn của người dùng vào cuộc gọi
- Vì người ra quyết định không muốn nghe các bài pitch bán hàng của nhiều công ty mỗi tuần, việc tổng hợp đề xuất bị đẩy sang cho người dùng
- Nếu người dùng thực sự coi sản phẩm là quan trọng, họ phải tự liên hệ những người cần thiết cho quy trình phê duyệt nội bộ
- Quá trình này mất ít nhất một tháng
- Ở các công ty Fortune 500, dù mọi thứ diễn ra hoàn hảo cũng mất tối thiểu 3 tháng
- Việc đưa vào một sản phẩm vốn để tiết kiệm thời gian lại trở thành một dự án lớn, khiến người dùng tự hỏi liệu đáng ra mình nên tự reverse-engineer công cụ đó hay không
Những giới hạn và hỗ trợ khách hàng còn lại sau khi mua
- Khi phê duyệt xong và tiền đã chuyển, nhân viên bán hàng biến mất, còn người dùng được chuyển sang Customer Service, tức là LLM
- “limitless, cloud-based platform” bộc lộ nhiều giới hạn trong quá trình sử dụng thực tế
- Một ngày thì nó hoạt động bình thường
- Ngày hôm sau, nó vượt qua một ngưỡng vô hình nào đó và toàn bộ luồng sụp đổ
- Tài liệu được sắp xếp để nhấn mạnh ưu điểm, nên rất khó tìm thấy cảnh báo hay giới hạn
- Hỗ trợ khách hàng bằng LLM lặp đi lặp lại cùng các liên kết tài liệu, rồi sau đó bạn mới có thể gửi email cho người thật
- SLA của email hỗ trợ dài kiểu 72 business hours, và điều đó được quy cho việc bạn đã không chọn Super Enterprise Plan™
- Phản hồi kết thúc theo kiểu bạn đã chạm một giới hạn vô hình nên hãy cấu trúc lại workflow
- Càng dùng tiếp, danh sách các chế độ lỗi không được tài liệu hóa càng dài ra
- Ví dụ: “nếu bấm hai nút quá nhanh thì iFrame sẽ báo lỗi”
- Có vẻ stack đang ghi lại lỗi, nhưng không ai liên hệ để giải thích nguyên nhân hay giúp sửa
Người phụ trách tài khoản, bán thêm, mã nguồn mở và chia tay
- Một ngày nọ, một người phụ trách tài khoản(account rep) mới liên hệ và đề nghị gọi điện để trao đổi về cách dùng sản phẩm cũng như hỗ trợ
- Cuộc gọi này giống một bài pitch bán hàng khác hơn là thu thập phản hồi hay giải quyết vấn đề
- Người phụ trách nghe danh sách vấn đề và nói “sẽ xem xét”, nhưng mục đích thực sự lộ ra là thuyết phục mua thêm tính năng
- Các tính năng bổ sung là những thứ như SSO hay quyền truy cập API, gần như không tốn chi phí với bên bán nhưng lại tạo khác biệt lớn với người dùng
- Người dùng phải quyết định sẽ mua thêm sản phẩm để có chức năng cơ bản, hay loại bỏ hẳn và đi theo hướng khác
- Cuối cùng, một lập trình viên mã nguồn mở nào đó tạo ra một công cụ miễn phí làm cùng việc
- Tên có thể buồn cười kiểu CodeSquish, Dojo, GitCharm
- Bạn biết đến nó qua đồng nghiệp, và khi tìm hiểu thì thấy nó làm được mọi việc cần thiết, không tốn phí và nhanh hơn 100 lần
- Dù chỉ một người bảo trì và diễn đàn duy nhất là một máy chủ Discord, nó vẫn tốt hơn rất nhiều so với sản phẩm thương mại
- Vì hợp đồng, cuộc chia tay bị trì hoãn, nhưng cuối cùng bạn báo cho Finance rằng đừng gia hạn
- Khi thấy việc ngừng gia hạn, đội ngũ nhà cung cấp đột nhiên tỏ ra rất quan tâm và cố thuyết phục rằng công cụ mã nguồn mở thực ra kém hơn
- Người dùng nói “chúng tôi sẽ thảo luận nội bộ”, nhưng thực tế không thảo luận gì, và cuối cùng thông báo chia tay qua email rồi chặn tên miền
1 bình luận
Ý kiến trên Hacker News
Nhà đầu tư cũng thường xem những quy trình như vậy là dấu hiệu của sự trưởng thành và là cách làm ở đẳng cấp cao nhất
Cách tiếp cận ngược lại là công khai thông tin minh bạch nhất có thể và không chặn lại, chủ động nói thẳng về điểm yếu, khi khách hàng muốn nói chuyện với người thật thì kết nối ngay với người có thể xử lý vấn đề, không để tư vấn viên AI gọi điện trừ khi khách hàng yêu cầu và phải nói rõ ngay đó là AI, cung cấp các tùy chọn đăng ký email linh hoạt như chỉ nhận theo tháng/quý/năm/ghi chú phát hành, và nếu sản phẩm không phù hợp thì đề xuất những lựa chọn thay thế hữu ích, chẳng hạn sản phẩm khác phù hợp hơn
Định giá dựa trên giá trị khiến nhiều công ty rơi vào tình huống này. Thay vì có giá chuẩn, họ nghiên cứu kỹ khách hàng, ước tính giá trị khách hàng sẽ nhận được từ sản phẩm rồi định giá theo đó; về lý thuyết thì tối đa hóa doanh thu, nhưng chậm và mang tính xâm phạm
Người dùng gói miễn phí có thể không làm nổi cả lập trình rất cơ bản, nhưng ngay khi được phép, họ có thể chiếm hết thời gian hỗ trợ kỹ thuật
Công khai việc dùng AI, cung cấp nhiều tùy chọn newsletter, và nói thẳng nếu không phù hợp là hợp lý và thực tế cũng hoạt động tốt. Nhưng ba điều đầu có thể làm hỏng sản phẩm. Dù vậy cũng có thể là tôi quá hoài nghi hoặc từ trước đến nay đã xử lý sai
Nếu tiền đề là dùng vốn đầu tư để xây unicorn thì đúng là vậy; còn với một công ty một người có nguồn thu phụ khác và muốn tăng trưởng chậm nhưng đều, cách này có thể phù hợp
Cạnh tranh không được quản lý là cuộc đua xuống đáy, nơi những chiến thuật phi đạo đức nhất, xâm phạm nhất, nằm sát ranh giới vi phạm pháp luật và mang tính thao túng nhất sẽ thắng
Không phải sản phẩm tốt nhất thắng mà là marketing tốt nhất thắng; không phải sự thân thiện với khách hàng thắng mà là tỷ lệ chuyển đổi nhờ ép buộc thắng; và giá không dựa trên giá trị của sản phẩm hay dịch vụ mà là số tiền tối đa người ta có thể trả
Dù có gói miễn phí hoặc bản dùng thử và tài liệu khá ổn, họ vẫn đòi demo. Họ thích làm lãng phí thời gian của tôi hơn là để ai đó phía họ tự xem xét
Thực ra họ chẳng có ý định chuyển đổi, chỉ dùng tôi làm đối tượng so sánh giá/tính năng để đàm phán gia hạn hợp đồng với đối thủ enterprise rẻ hơn
Phải điền những bảng câu hỏi bảo mật vô tận khi còn chưa chắc có bán được hay không. Cứ như thể ai mà chẳng thích điền hơn 100 câu hỏi lúc 11 giờ tối thứ Sáu
Quy trình mua sắm mất 3–6 tháng, và thường có một hai reseller phần mềm bên thứ ba chỉ quan tâm đến biên lợi nhuận của họ chen vào. Phải nói với CDW rằng tôi sẽ không giảm giá 15% để các anh kiếm tiền
Ngay cả sau khi ký hợp đồng, tiền cũng 60–90 ngày sau mới vào, trong khi dịch vụ đã phải cung cấp và dòng tiền thì căng thẳng. Nhân viên ngân hàng còn có thể gọi hỏi vì sao biên lợi nhuận và hạn mức thẻ tín dụng đã chạm trần
Vì vậy với doanh nghiệp lớn thì nhất định phải tính giá cao
Nói rõ từ trước mình làm gì và không làm gì thật sự rất hữu ích. Họ vẫn yêu cầu những thứ như biểu mẫu mua sắm, nhưng ít nhất ta có thể từ chối và đặt kỳ vọng
https://help.timetastic.co.uk/hc/en-us/articles/115003288769...
Nếu cần tùy biến một chút, hoặc một startup giai đoạn đầu đang hợp tác với khách hàng pilot để tinh chỉnh và chứng minh product-market fit, thì còn khó hơn. Nếu khách hàng là một công ty thật sự chứ không phải một startup khác trong danh mục đầu tư của nhà đầu tư, và tác động đến nhiều hơn một nhóm rất nhỏ trong công ty đó, thì ngay cả khi đã có được sự chú ý của CEO, bạn vẫn phải chuẩn bị tinh thần họp bất tận trong nhiều tháng với các bên liên quan ở nhiều phòng ban
Ở vị thế một startup giai đoạn đầu linh hoạt, bạn sẽ cảm nhận rất rõ rằng về lý thuyết mình lẽ ra phải có lợi thế đổi mới khổng lồ so với các tập đoàn lớn chậm chạp. Vì trông họ như chẳng làm được gì cả
Nhưng nếu bạn đã mắc sai lầm là cần sự đồng thuận của chính tập đoàn lớn chậm chạp chẳng làm được gì đó, thì giờ hầu hết rào cản di chuyển của họ trở thành rào cản của bạn
Tôi cũng đã thấy một biến thể còn tệ hơn của cùng câu chuyện. Một kỹ sư có đội đang vận hành thành công một giải pháp mã nguồn mở tốt, nghe một kỹ sư khác nói rằng họ đang bị đội bán hàng enterprise của một sản phẩm rác tấn công, nên cố gắng gióng chuông báo động nhưng đã quá muộn
Ở tầng trên của sơ đồ tổ chức, ai đó đã đặt vốn chính trị của mình vào đó và ký rồi; trong vài trường hợp, việc tiêu tiền công ty vào đúng sản phẩm đó còn trở thành chỉ số hiệu suất cá nhân. Thế là mọi lựa chọn thay thế bị chặn, tất cả phải chờ vài tháng để chốt sale, rồi chờ thêm một tháng để IT thiết lập SSO và cơ sở dữ liệu, và bị ép chuyển từ giải pháp đang chạy tốt sang thứ rác rưởi
Cuối cùng hợp đồng không được gia hạn và những người thúc ép vẫn giữ được thể diện, nhưng một nửa số người phải gánh nó đã chuyển sang công ty tốt hơn, một phần tư bị sản phẩm rác cản trở đến mức nhận PIP hoặc sự nghiệp chững lại, và phần tư còn lại phần lớn cũng sẽ bị sa thải vào năm sau
Với bán hàng enterprise thì cứ phải nói KHÔNG. Điều tệ hơn việc phải làm bán hàng enterprise để bán sản phẩm của mình là, với tư cách nhân viên, bị buộc phải dùng một quyết định mua hàng tồi do một đội bán hàng enterprise khác tạo ra
Nhưng khi tìm giải pháp mã nguồn mở thì thường nó tốt hơn và có thể làm mọi thứ mình muốn. Chỉ cần
docker compose uplà đã có thể thử nghiệm đơn giản rồiTuy nhiên đến bước triển khai, compliance chỉ kiểm tra chứng nhận SOC2, rồi chặn rất gắt bằng cách yêu cầu thẩm định sâu về mã vì về lý thuyết bất kỳ ai trên thế giới cũng có thể sửa mã
Người quản lý hỏi làm sao một thứ vừa miễn phí vừa mã nguồn mở lại có thể tốt đến vậy, còn các đội đang quá tải thì thường không thích phải hỗ trợ thêm một phần mềm khó đoán nữa
Vì thế rốt cuộc lựa chọn sẽ là đốt tiền và công sức vào một SaaS tệ hại, các chu kỳ bán hàng vô tận và vô dụng, cùng sự khóa chặt nhà cung cấp kinh khủng và đắt đỏ; hoặc dùng và vận hành mã nguồn mở trong nội bộ, rồi đốt ít tiền và công sức hơn một chút
Thường thì người ta chọn mã nguồn mở. Đặc biệt là khi SaaS không cung cấp quy trình tự onboarding nhanh và dễ, thời gian đánh giá có ý nghĩa, cùng mức giá dự đoán được và minh bạch
Và khi nó được áp dụng rộng rãi, họ sẽ hỗ trợ tác giả; hoặc nếu là phần mềm mã nguồn mở phức tạp hơn, họ sẽ phân bổ ngân sách cho gói hỗ trợ. Họ vẫn làm vậy dù trên thực tế nhiều khả năng là hầu như không cần đến
“[…] Tôi tìm CodeSquish trên Google thì thấy nó làm được mọi thứ tôi cần, chi phí bằng 0, và hiệu năng tốt hơn 100 lần. Dù nó được duy trì bởi một ẩn sĩ thỉnh thoảng mới rời trang trại ở Vermont để đẩy code lên kho git tự host của mình.”
Người maintainer ẩn sĩ nghèo đó vào một chiều thứ Ba nọ phát hiện ra rằng công ty của bạn kiếm 100 triệu đô la mỗi năm nhờ “CodeSquish” mà không đóng góp gì cả. Anh ta vừa cho gà ăn ở trang trại Vermont vừa lặng lẽ hoài nghi các lựa chọn trong đời mình, à không, lựa chọn giấy phép của mình
Phần lớn mã nguồn mở hay SaaS, dù hữu ích với các công ty Fortune 500, cũng gần với tiện ích hơn nên rất khó định giá. Trong bài cũng thấy nhà cung cấp SaaS tô vẽ để trông có vẻ có giá trị hơn với các công ty lớn, gọi điện cho mọi người để nhồi nhét những điều nhảm nhí và dùng định giá dựa trên giá trị
Tôi cũng không thấy nhiều trường hợp công ty vận hành một hệ thống mã nguồn mở rồi bán lại nó. Thường thì họ muốn sở hữu toàn bộ quyền sở hữu trí tuệ, nên như trong bài, họ tự làm lại một thứ dở tệ của riêng mình
Việc Amazon đã làm với Elastic là khả thi vì Elastic đã xây dựng được thương hiệu. Không thể làm vậy với một dự án ngẫu nhiên. Bạn có thể dùng một dự án nào đó để vận hành hạ tầng, nhưng việc quy giá trị cho một thư viện hay dự án cụ thể là cực kỳ khó
Amazon kiếm tiền vì họ là Amazon, chứ không phải vì họ dùng kernel Linux. Dù sao thì đây là một vấn đề khó sắp xếp rành mạch trong đầu
Thứ nhất, nhiều phần trong số này có thể là cần thiết nếu muốn bán B2B và giữ cho một nửa ngành phần mềm vận hành. Công ty bán hàng có thể phải liên hệ nhiều lần, cử kỹ sư bán hàng tham gia, và giúp căn chỉnh tất cả những người ra quyết định. Nếu không thì việc có thể hoàn toàn không tiến triển. Người mua quá bận, còn việc bán cho các công ty lớn thì quá phức tạp, nên một phần trong đó là điều ác cần thiết để các giao dịch B2B tiếp tục vận hành
Thứ hai, tôi ước có thể tưởng tượng rằng các công ty thực sự mua sắm tốt hơn. Các tập đoàn lớn chi hàng triệu đô la cho phần mềm doanh nghiệp phình to, trong khi một startup có thể làm ra thứ tốt hơn 10 lần với chi phí bằng một phần mười. Nếu có thể bán cho họ dễ hơn, mọi người đã có thể dùng công nghệ tốt hơn mà không cần sự điên rồ này
Tôi đồng ý rằng trải nghiệm trong bài gốc bào mòn tâm hồn, nhưng nếu khách hàng cũng tự giúp mình một chút thì họ sẽ giữ được nhiều tiền hơn trong túi và có được công nghệ tốt hơn
Sản phẩm enterprise đơn giản là một hạng mục khác, và điều đó tách biệt với bản thân sản phẩm
“Tôi thấy trên LinkedIn rằng bạn nói tiếng Tây Ban Nha. Tôi nghe nói cách ‘¡Qué chévere!’ mang năng lượng và sự tươi sáng vào cuộc trò chuyện có sức hấp dẫn độc đáo. Gần đây bạn có cơ hội luyện tập không?”
“Chúng tôi phát triển các công cụ tự động hóa tuân thủ adapitates với các quy định thay đổi, giảm chi phí chung trong khi bảo đảm các chương trình đầu tư an toàn và hiệu quả.”
Không ai nhìn thấy mục tiếng Tây Ban Nha “khả năng làm việc hạn chế” của tôi trên LinkedIn rồi nói như câu đầu tiên cả. Và “Adapitates” ở câu thứ hai không phải là một từ thật mà là ảo giác. https://old.reddit.com/r/ChatGPT/comments/1d8gc6x/did_chatgp...
Bản thân việc bán hàng không phải là vấn đề, và phần lớn mọi người chấp nhận một mức độ bán hàng nào đó. Tôi từng nhận một email cold mail không cá nhân hóa từ một công ty sao chép dữ liệu; nó ngắn gọn, đi thẳng vào trọng tâm, và chân thành đối với một email spam, nên thực sự khiến tôi quan tâm đến sản phẩm
Mọi công ty trên Trái Đất đều đang thử nghiệm công nghệ này, và nếu chúng ta không gửi tín hiệu mạnh khi họ làm hỏng, thì chúng ta đang tự trói phiên bản tương lai của mình vào đống rác này
Những khách hàng muốn các tính năng đó thì cần chúng bất kể chi phí bao nhiêu, dù là hỗ trợ hay báo cáo SOC-2, và chính họ đang trợ giá cho những khách hàng không cần. Nếu điều đó giúp dễ hiểu hơn, bạn có thể xem gói cao cấp có SSO và SLA là giá thật của sản phẩm
Ngay từ đầu, trong lĩnh vực công nghệ gần như không có định giá thực sự dựa trên chi phí
Điều này về cơ bản có nghĩa là công ty phải gánh toàn bộ chi phí đã tính đủ cho ít nhất 1 nhân viên bổ sung. Lấy chi phí đầy đủ đó xấp xỉ bằng lương nhân 2, rồi chia cho số khách hàng yêu cầu SLA này, bạn sẽ bắt đầu thấy cần phải thu bao nhiêu
Nếu biết phải 3 ngày sau mới nhận được câu trả lời, người ta sẽ tự tìm kiếm những thứ hiển nhiên, và chỉ liên hệ hỗ trợ khi không thể tìm ra câu trả lời bằng cách khác. Nhưng SLA ngắn hơn, đặc biệt là hỗ trợ qua điện thoại, khiến một số kiểu khách hàng sao chép nguyên xi mọi thông báo lỗi họ gặp rồi dán vào, và kỳ vọng đội hỗ trợ giải quyết, dù lỗi đó có thể thậm chí không đến từ sản phẩm. Tôi đã trực tiếp trải qua chuyện này
Trợ cấp chéo có thể phát sinh do quy định, hoặc khi một công ty cố gắng độc chiếm thị trường
Giá sản phẩm được quyết định bởi mức có thể thu được và chi phí biến đổi hơn là chi phí phát triển. Như đã chỉ ra, điều này dẫn đến phân biệt giá, và nhìn bề ngoài có vẻ như một nhóm đang trợ cấp cho nhóm khác, nhưng thực tế có thể không phải vậy
Tôi muốn thấy một mô hình về chi phí cận biên và ra quyết định lý tưởng. Quyết định xây dựng một tính năng chỉ dành cho khách hàng trả nhiều tiền chỉ có lợi khi những khách hàng đó trả tiền cho tính năng ấy. Khách hàng khác có thể nhận được tính năng đó, nhưng đó không phải là “trợ cấp”. Tuy vậy tôi cũng không biết từ nào hay hơn
Nếu đưa ra cách tiếp cận trực tiếp, không vòng vo, demo ngay lập tức, thời gian đánh giá có ý nghĩa, onboarding dễ dàng, v.v., bạn sẽ mất những khách hàng vốn mong đợi trò chơi bán hàng thông thường
Nguồn: tôi đang dùng cách tiếp cận trực tiếp
Vậy thì tại sao lại gọi điện với kỹ sư bán hàng? Email thì chỉ cần xóa là xong
Nếu người phụ trách kỹ thuật đang chặn người ra quyết định cuối cùng như tình huống được mô tả, thì chuyện đó giống một canh bạc hơn và thường thất bại
Những sản phẩm mà tôi muốn nhập thông tin thẻ tín dụng rồi bắt đầu ngay chỉ là các phần mềm phổ dụng như AWS EC2 hoặc dịch vụ đăng ký tên miền
Đôi khi ranh giới trong mô hình giá/bán hàng bị lẫn lộn, chẳng hạn khi định giá sản phẩm enterprise như phần mềm phổ dụng. Thường đó là dấu hiệu công ty còn non nớt
Phần mềm có giá hai đến ba chữ số thì không nên có đội ngũ bán hàng. Phần mềm có giá từ năm đến sáu chữ số trở lên thì nhất thiết cần con người trong quy trình bán hàng và onboarding, vì một phần lớn số tiền tôi trả là cho hỗ trợ
Vấn đề là điều chúng ta muốn biết thường không phải “có đáp ứng được trường hợp sử dụng này không”, mà là “đáp ứng trường hợp sử dụng này tốt đến mức nào”. Điều đó rất khó đánh giá nếu không tự tay dùng phần mềm
Tôi không thường xuyên nhận sales pitch, nhưng vì những lý do khác, tôi cũng có thái độ tương tự. Tôi muốn ghi lại mọi thứ bằng văn bản, phòng trường hợp họ ban đầu nói có để đặt được một chân vào cửa, rồi lại nói không ở các điều kiện chi tiết