- 新しいSaaS製品を軽く試そうとした瞬間から、営業メール、メーリングリスト、繰り返される通話依頼が続き、ユーザーの時間がじわじわ奪われていく
- 購入フローは、本当に必要な1つ2つの機能よりも、決まりきったデモや「everything platform」式の説明に引きずられ、営業担当者とセールスエンジニアが通話を増やしていく
- 支払い承認の段階では、上位の意思決定者を通話に引き込もうとする圧力が強まり、社内承認には通常最低1か月、Fortune 500ではすべてがうまく進んでも最低3か月かかる
- 購入後は営業担当者が姿を消し、LLMベースのカスタマーサポート、長いSLA、文書化されていない制約や障害モードだけが実際のユーザーに残される
- アカウント担当者は問題解決より追加機能の販売に集中し、結局はより速くて無料のオープンソース代替が現れると、契約更新停止とメールでの別れで終わる
体験版のあとに付きまとう連絡
- 新しいサービスや製品を試すとき、最大の障壁の1つは、その後に続く継続的な連絡である
- 最初は「質問があれば知らせてほしい」という無害なメールで始まるが、すぐに「customer success fun-gineer」のような担当者が、体験版の利用感を確認したいと連絡してくる
- ユーザーはたいてい、特定の機能を1つ確認するために登録する
- その機能がなければ興味を失って忘れてしまう
- まだ評価中というのでなければ、なぜ連絡が来るのか理解しにくい
- メーリングリストに残っていると、新しいリリースやローンチ通知を受け取り続けることになる
- 興味がなくても、欲しかった機能が追加された可能性があるため、毎回配信停止するか迷う
- 参照しやすいリリースノートがなければ、マーケティングメールが機能追加の有無を確認する唯一の経路のようになってしまう
「一度お話ししましょう」に変わる購入フロー
- 最悪なのは、実際にサービスを使える段階になったときで、ここから一連の通話の予定に縛られる
- Webサイトにクレジットカード番号を入力すれば終わるのではなく、Microsoft Teamsで見知らぬ人たちと関係を作らなければならない
- 典型的なSaaS営業チームには2つの役割が登場する
- 営業担当者はCRMにデータを入力しながら、成約までひたすら押し続ける
- 「sales engineer」「customer success engineer」といった肩書きの担当者は、実際にドキュメントを読んだ数少ない人であり、製品を新しい「everything platform」であるかのように説明する
- デモには、ユーザーが望んでいない機能まで含まれる
- ユーザーは1つか2つの機能だけを確認しに来たのに、決め打ちのデモテンプレートには柔軟性がない
- 営業担当者は、ユーザーが技術に明るいといった軽い褒め言葉で空気を和らげようとする
- セールスエンジニアのデモは肝心でない瞬間に壊れ、そのあとに「普段はちゃんと動く」という弁明が続く
セキュリティ・コンプライアンスと長引く承認
- ある時点でコンプライアンスとセキュリティについて尋ねると、意味のない認証書類の束が送られてくる
- 認証文書は、実際に項目を実施した証拠というより、もっともらしく実施したように見せられることを示す程度のものとして扱われる
- デモと関係づくりが終わると、営業チームはユーザーの上位意思決定者を通話に参加させようとする
- 意思決定者は複数社の営業ピッチを毎週聞きたいわけではないため、提案内容を整理する仕事はユーザーに回ってくる
- ユーザーがその製品を本当に重要だと考えるなら、社内承認に必要な人たちへ自分で連絡しなければならない
- この過程には最低1か月かかる
- Fortune 500企業では、すべてが完璧に進んでも最低3か月かかる
- 時間を節約するはずだった製品導入が大きなプロジェクトになり、ユーザーはむしろ自分でそのツールをリバースエンジニアリングしたほうがよかったのではと考えるようになる
購入後に残る制約とカスタマーサポート
- 承認が終わってお金が動くと、営業担当者は消え、ユーザーはCustomer Service、つまりLLMに引き渡される
- 「limitless, cloud-based platform」は、実際に使い始めるとさまざまな制約を露呈する
- ある日は正常に動く
- 次の日には見えないしきい値を超えて、ワークフロー全体が崩壊する
- ドキュメントは長所を強調するよう整理されているため、警告や制約を見つけにくい
- LLMカスタマーサポートは同じドキュメントリンクを繰り返し提示し、その後になってようやく実際の人間にメールを送れる
- サポートメールのSLAは72 business hoursのように長く、それはSuper Enterprise Plan™を選ばなかったからだという扱いになる
- 返答は、見えない上限に達したのでワークフローを組み直せ、というような内容で終わる
- 使い続けるほど、文書化されていない障害モードの一覧が増えていく
- 例: 「2つのボタンをあまりに早く押すとiFrameがエラーを出す」
- スタックがエラーを記録しているように見えても、誰も連絡して原因を説明したり修正方法を助けたりはしない
アカウント担当、追加販売、オープンソース、そして別れ
- ある日、新しいアカウント担当者(account rep) から連絡が来て、製品の使い方や支援について話したいので通話しようと求められる
- この通話は、フィードバック収集や問題解決よりも、また別の営業ピッチに近い
- 担当者は問題の一覧を聞いて「確認します」と言うが、実際の目的は追加機能の購入を説得することだとわかる
- 追加機能は、SSOやAPIアクセスのように、ベンダー側にはほとんどコストがかからないのに、ユーザーには大きな違いをもたらす項目である
- ユーザーは、製品をさらに買い足して基本機能を得るか、いっそ削除して別の道へ進むかを決めなければならない
- 結局、どこかのオープンソース開発者が同じことをする無料ツールを作る
- 名前はCodeSquish、Dojo、GitCharmのように滑稽かもしれない
- 同僚経由で知り、調べてみると必要なことをすべてこなせて費用もかからず、100倍速い
- たった1人で保守され、フォーラムがDiscordサーバーしかなくても、商用製品よりはるかにましである
- 契約のせいで別れは先延ばしになるが、最終的にはFinanceに更新しないよう伝える
- 更新停止の気配が見えると、ベンダー側のチームは突然大きな関心を示し、オープンソースツールは実際には劣っていると説得しようとする
- ユーザーは「社内で検討します」と言うが、実際には何も検討せず、最後はメールで別れを告げてドメインをブロックする
1件のコメント
Hacker News のコメント
投資家もそうしたプロセスを成熟度のシグナルであり、最高水準のやり方だと見ることが多い
逆のアプローチは、情報をできるだけ透明に公開して遮らないこと、弱点を先に率直に伝えること、顧客が人と話したいときにはすぐ問題を処理できる人につなぐこと、顧客が求めない限りAI相談員から電話をかけず、AIであることを即座に明かすこと、月次/四半期/年次/リリースノートのみのような柔軟なメール購読オプションを用意すること、製品が合わないなら、より適した別製品など有用な代替案を提案すること
価値ベースの価格設定のせいで、多くの企業がこうした状況に陥る。標準価格を置く代わりに、顧客を詳しく調べて製品から得られる価値を推定し、それに応じて価格を決めるので、理論上は売上を最大化できるが、遅く侵襲的になる
無料プランのユーザーがごく基本的なプログラミングもできないのに、許した瞬間に技術サポートの時間をすべて奪ってしまうこともある
AI利用の開示、複数のニュースレターオプションの提供、合わないなら正直に伝えることは妥当で、実際にもよく機能した。だが前の3つは製品を壊しかねない。ただ、私が冷笑的すぎるか、これまで扱い方を間違えてきただけかもしれない
投資家の資金でユニコーンを作る前提ならそうで、別の副収入がある1人会社のゆっくりだが着実な成長には、このやり方が合うかもしれない
規制のない競争は底辺への競争なので、最も非倫理的で侵襲的で、違法すれすれで、操作的な戦術が勝つことになる
最高の製品ではなく最高のマーケティングが勝ち、顧客への親切さではなく強圧によるコンバージョン率が勝ち、製品やサービスの価値ではなく人々が支払える最大額が価格になる
無料プランやトライアル、まともなドキュメントがあるのにデモを求めてくる。自分たち側の誰かに検討させるより、私の時間を無駄にすることを好む
実際には乗り換える気もないのに、エンタープライズ競合の更新契約を安く取るための価格/機能比較対象として利用する
売れるかどうかも確かでない状態で、終わりのないセキュリティ質問票に答えなければならない。金曜の夜11時に100問以上を埋めるのが好きではないのか、という感じ
調達プロセスに3〜6か月かかり、しばしば自分のマージンだけを気にする第三者のソフトウェアリセラーが1社2社と入り込む。CDWには、あなたたちが儲けられるように価格を15%下げるつもりはない、と言わなければならない
契約が終わった後も入金は60〜90日後なのに、サービスはすでに提供しなければならず、キャッシュフローは苦しい。銀行の担当者から、マージンやクレジットカード限度額がなぜいっぱいなのか電話が来ることもある
だから大企業には必ず高く請求する
何をし、何をしないのかを事前にはっきり伝えるのは本当に役に立つ。今でも調達フォームのようなものを求められるが、少なくとも断って期待値を設定できる
https://help.timetastic.co.uk/hc/en-us/articles/115003288769...
少しカスタマイズが必要だったり、プロダクトマーケットフィットを磨いて証明している初期スタートアップがパイロット顧客と協業する状況なら、さらに大変になる。顧客が投資家ポートフォリオ内の別のスタートアップではなく本物の会社であり、その中のごく小さな1チーム以上に影響し、すでにCEOの耳をつかんでいるとしても、複数部門のステークホルダーたちと終わりのない会議を何か月も続ける覚悟が必要
機敏な初期スタートアップの立場では、理論上、大きく鈍重な大企業に対してものすごいイノベーション上の優位があるはずだと実感する。彼らは何もできないように見えるから
ところが、まさにその何もできない大きく鈍重な大企業の同意を必要とするミスを犯したなら、今度は彼らの移動障壁の大半が自分の障壁になる
同じ話のさらに悪い変種も見たことがある。すでに優れたオープンソースソリューションをチームでうまく運用していたエンジニアが、別のエンジニアにゴミのような製品のエンタープライズ営業攻勢が降ってきたと聞いて警鐘を鳴らそうとしたが、すでに手遅れだった状況
組織図の上の方で政治的資本を賭けて署名しており、場合によっては会社の金をその特定製品に使うことが個人の成果指標になってしまう。だからあらゆる代替案は遮られ、全員が営業のクロージングを何か月も待った後、ITがSSOとデータベースを設定するのにさらに1か月待ち、うまく動いていたソリューションからゴミへ強制移行させられる
結局、契約は更新されず、推し進めた人たちは面目を保つが、それを背負わされた人たちの半分はより良い会社へ転職し、4分の1はゴミ製品に邪魔されてPIPを受けるかキャリアが停滞し、残りの4分の1も大半は翌年に解雇される
エンタープライズ営業にはただNOと言うべき。自分の製品を売るためにエンタープライズ営業をしなければならないことより悪いのは、別のエンタープライズ営業が生み出したひどい購買判断を、従業員として強制的に使わされること
ところがオープンソースソリューションを探すと、たいていはより良く、望むことを全部できる。
docker compose upだけですでに簡単にテストもできるしかしデプロイ段階でコンプライアンスがSOC2認証だけを確認し、世界中の誰でも理論上コードを変えられるという理由で、コードに対する深いデューデリジェンスを求めて強く阻まれる
マネージャーは「無料でオープンソースなのに、どうしてそんなに良いのか」と尋ねるし、過負荷状態のチームは、予測不能なソフトウェアをもう1つサポートすることをたいてい好まない。
そのため結局、ひどいSaaSと終わりのない無駄な営業サイクル、恐ろしく高価なベンダーロックインにお金と神経をすり減らすか、あるいはオープンソースを社内で活用・運用して、お金と神経を少しすり減らすかの選択になる。
たいていはオープンソースを選ぶ。特にSaaSが、素早く簡単なセルフオンボーディング、意味のある評価期間、予測可能で透明な価格を提供していないなら、なおさらだ。
そして広く導入されるようになれば作者を支援するか、より複雑なオープンソースソフトウェアならサポートプラン用の予算を割り当てる。実際にはほとんど必要ない可能性が高くても、そうする。
「[...] GoogleでCodeSquishを探してみたら、必要なことを全部やってくれて、費用は0で、性能は100倍良かった。バーモントの農場からたまに出てきて、自分のセルフホストgitリポジトリにコードをプッシュする隠遁者1人が保守しているにもかかわらずだ。」
その貧しい隠遁メンテナーは、ある火曜の午後、あなたの会社が「CodeSquish」で年1億ドルを稼ぎながら何も貢献していないことを知る。彼はバーモントの農場で鶏に餌をやりながら、静かに自分の人生の選択、いやライセンスの選択を疑い始める。
ほとんどのオープンソースやSaaSは、Fortune 500企業で役に立つとはいえ、どちらかというと利便性に近く、価値を付けにくい。記事でも、SaaSベンダーが大企業により価値があるように見せかけ、人々に電話してたわごとを押し付け、価値ベースの価格設定を使っているのが分かる。
会社がオープンソースシステムを運用しているからといって、それを再販売するケースもあまり見たことがない。たいていは知的財産権全体を所有したいので、記事にあるように自分たちの粗末なものを作り直す。
AmazonがElasticに対してしたことは、Elasticがブランドを築いていたから可能だった。無作為なプロジェクトには同じことはできない。あるプロジェクトをインフラ運用に使うことはできても、特定のライブラリやプロジェクトに価値を帰属させるのは非常に難しい。
Amazonが稼いでいるのはAmazonだからであって、Linuxカーネルを使っているからではない。いずれにせよ、頭の中で整理しにくい問題だ。
まず、この多くはB2B販売を行い、ソフトウェア産業の半分を回していくには必要なのかもしれない。売り手側の会社は何度も連絡し、セールスエンジニアを付け、すべての意思決定者をそろえるプロセスを助ける必要があるかもしれない。そうしないと物事がまったく進まない。買い手は忙しすぎるし、大企業に売るのは複雑すぎるので、その一部はB2B取引を回し続けるための必要悪だ。
次に、企業が実際にはもっと上手に購入すると想像してみてほしい。大企業は、スタートアップが10分の1のコストで10倍良いものを作れるのに、エンタープライズ向けの肥大化したソフトウェアに何百万ドルも使う。彼らにもっと簡単に売れるなら、こうした狂気なしに、誰もがより良いものを使える。
元記事の経験が魂をすり減らすものだという点には同意するが、顧客側も少し自助努力をすれば、財布により多くのお金が残り、より良い技術も手に入る。
エンタープライズ製品は単に別のカテゴリであり、それは製品自体とは別の話だ。
「LinkedInでスペイン語を話すと拝見しました。『¡Qué chévere!』が会話にもたらすエネルギーと明るさには、独特の魅力があると聞きました。最近、練習する機会はありましたか？」
「変化する規制にadapitatesするコンプライアンス自動化ツールを開発し、安全で効率的な投資プログラムを保証しながら間接費を削減します。」
LinkedInの私のスペイン語「限定的な業務利用可」という表示を見て、最初の文のように言う人間はいないだろう。そして2つ目の「Adapitates」は実在する単語ではなく、幻覚だ。https://old.reddit.com/r/ChatGPT/comments/1d8gc6x/did_chatgp...
営業そのものが問題なのではなく、ほとんどの人はある程度の営業を受け入れる。データ複製会社からパーソナライズされていないコールドメールを受け取ったことがあるが、短く要点を押さえていて、スパムメールにしては誠実だったので、実際にその製品に興味を持った。
地球上のあらゆる企業がこの技術を試しており、彼らが失敗したときに私たちが強いシグナルを送らなければ、未来の自分たちをこのゴミに縛り付けることになる。
そうした機能を求める顧客は、費用がいくらであれサポートやSOC-2レポートを必要としており、彼らがそれを必要としない顧客を補助する構造になっている。分かりやすいなら、SSOとSLAが含まれた上位パッケージを製品の本当の価格だと見ればよい。
そもそも技術分野で本当のコストベースの価格設定はほとんどない。
これは実質的に、会社が追加スタッフ最低1人分のフルコストを負担しなければならないという意味だ。そのフルコストはおおよそ給与の2倍と見て、それをこのSLAを要求する顧客数で割れば、いくら請求すべきかが見え始める。
回答が3日後にしか返ってこないと分かっていれば、明らかなことは自分で検索し、ほかの方法で答えが見つからないときだけサポートに連絡する。だが、より短いSLA、特に電話サポートは、どんなタイプの顧客でも遭遇したエラーメッセージをそのままコピー＆ペーストし、そのエラーが製品由来ではない可能性があっても、サポートチームが解決してくれると期待させてしまう。実際に経験した。
内部補助は、規制によって生じることもあれば、会社が市場独占を試みるときに生じることもある
製品価格は開発費よりも、いくら取れるかと変動費によって決まる。指摘のとおり、これは価格差別につながり、見かけ上はある集団が別の集団を補助しているように見えても、実際にはそうではない可能性がある
限界費用と理想的な意思決定のモデルを見てみたい。高額顧客向け専用機能を作ると決めるのは、その顧客たちがその機能の対価を支払う場合にだけ利益になる。ほかの顧客がその機能を得ることはあり得るが、それは「補助」ではない。ただ、もっとよい言葉が何なのかは分からない
くだらない駆け引きのない直接的なアプローチ、即時デモ、意味のある評価期間、簡単なオンボーディングなどを提供すると、普通の営業ごっこを期待している顧客を失うことになる
出典: 私自身が直接的なアプローチをしている
それなら、なぜ営業エンジニアと電話で話すのか。メールなら削除すればいいだけだ
描写されている状況のように、技術担当者が最終意思決定者をブロックしているなら、より賭けに近く、失敗することも多い
クレジットカード情報を入れてすぐ始めたい製品は、AWS EC2やドメイン登録サービスのような汎用ソフトウェアだけだ
価格／営業モデルで線引きが混乱することがあるが、エンタープライズ製品を汎用ソフトウェアのように価格設定する場合がそれに当たる。たいてい会社が未成熟であるサインだ
2〜3桁の価格のソフトウェアに営業チームは不要だ。5〜6桁以上の価格のソフトウェアには、営業とオンボーディングの過程に人が必ず必要だ。私が支払うものの大きな部分はサポートだからだ
問題は、私たちが知りたいのはたいてい「このユースケースを満たせますか」ではなく、「このユースケースをどれくらいうまく満たせますか」だという点だ。ソフトウェアを実際に触らずに評価するのは難しい
営業ピッチを頻繁に受けるわけではないが、別の理由で似たような態度を取っている。まずイエスと言って足がかりを作り、細かい条件ではノーと言ってくる場合に備えて、すべてを文書に残しておきたい