GTM向けAIが成果を出せない理由(そしてその解決法)
(x.com/thecamjwright)- メール作成、AI SDR、インテントツールなど、さまざまなAIを導入したGTMチームの多くは、期待したほどの営業生産性・パイプライン・売上向上を実感できていない
- AIにアカウント攻略を任せると、「AcmeがSDRを採用中で、昨年クローズドロスト案件があったので連絡しよう」といった技術的には正しいが一般的なメッセージしか生成されず、買い手に即削除される結果につながる
- 根本原因は、AIが良い意思決定に必要な2つ、すなわちコンテキスト(context)とロジック(logic) を持てていないことにある
- 多くのGTM向けAIツールは、メールやスクリプト生成のような実行(Execution)レイヤーにしか注力しておらず、本当のレバレッジがあるターゲティングや観点(POV)のような上流(upstream)領域は放置されている
- 先行するチームは、ソースデータと実行ツールの間に自社固有のGTM Context Layerを構築し、どのシグナルが重要か・なぜ今なのか・誰に・何を伝えるべきかを自前の判断で決めることが競争優位の核になっている
導入 — AIがGTM成果を出せない現実
- ほとんどのGTMチームは、メール作成、AI SDR、インテントツール、シグナルベースのアウトバウンド、自動リサーチ、ディールレビューなど、何らかの形ですでにAIを導入している
- 本来AIは、担当者の効率、パイプライン、実際に成立した取引から生まれる売上を測定可能なレベルまで引き上げるべきだが、大多数のチームの結果は依然として不十分である
- AIにアカウント攻略をさせると、次のような結果が出る
- "Acme is hiring SDRs and had a closed-lost opportunity last year. Reach out about renewed pipeline growth."
- 技術的には合っているが完全に一般的で、担当者は依然として手動リサーチをしなければならず、優先順位判断は推測にとどまり、アウトリーチは作為的に感じられる
- 核心的な問題は、意思決定に必要なコンテキストとロジックなしにAIへGTMの意思決定を任せていることにある
GTM's North Stars — AIが実際に改善すべき点
- 第一原則で見れば、GTMチームは3つに集中すべきである
- a) より多くのパイプライン、b) より速いパイプライン進行、c) より多くのクローズドウォン売上
- この記事は a) パイプライン生成(pipeline generation) に焦点を当てる
- 営業組織がコントロール可能な3つの「入力(input)」をさらに掘り下げると(需要・市場認知などは除く)
- Targeting: どのアカウントとどの人物に集中するか
- Hypothesis: どんな課題を提起し、どんな解決を提案するか
- Execution: その仮説をアウトリーチ・コール・プレゼンなどへどれだけうまく変換できるか
- 3領域すべてでAIはレバレッジを生みうるが、実際にどこへ現れているかで問題が始まる
- 多くのGTM向けAIツールは、第3レイヤーであるExecutionに過度に集中しており、メール作成・アカウント要約・コールスクリプト生成・活動自動化には有用だが、本当にレバレッジがある場所ではない
The Reality — 本当の「アルファ」は上流(upstream)にある
- ターゲティングと観点(point of view)の質は、送るメールの質よりはるかに重要である
- ありふれたシグナルでアカウントを選び、弱い仮説を立てれば、「優れた」メールでも何の効果もない
- 逆に、正しいアカウントに鋭い仮説でアプローチすれば、コピーが完璧である必要はなく、関連性(relevant) さえあればよい
- 今日のエージェントは、次を判断する専門家ではないため、GTM向けAIの試みは振るわない
- どのアカウントが重要か / なぜ今そのアカウントが重要か / 誰が最も関連性が高いか / どのペインが最も起こりそうか / どんなメッセージが実際に信頼を生むか
- 相互に関連する2つの根本原因が存在する
- Context: エージェントが正しいGTMコンテキストを持っていない
- Logic: 本来自社の内部的強みであるべきロジックを外部に委託している
Problem One — AIが正しいコンテキストを持っていない
- GTMスタックは断片化されており、優れた営業担当者は、どのシグナルが購買判断を左右するのか、どう捉え・優先順位付けし・関係性を把握するのかを正確に理解している
- 彼らはCRM、コール録音、インテント活動、共通の人脈、求人票、reddit、オンラインフォーラムなど、利用可能なあらゆる情報を掘り下げてターゲティング・仮説・メッセージングを設計する
- エージェントも同様である
- LLMに誰をターゲットにすべきか・何を言うべきかを尋ねるとき、a) パズルの一部しか持っていない、または b) ピース同士がどう組み合わさるかを理解していない(あるいはその両方)なら、効果的でありえない
-
例 — 同じ採用シグナルでも、まったく異なる2つのアカウント
- 2社が最近SDRの求人を出したと仮定する
- 正しいコンテキスト・ロジックを持たないエージェントは、両アカウントで同じ採用シグナルを検知し、両方を優先し、似たようなアウトバウンドを生成する
- 実際には、適合性・インテント・状況、したがって優先順位はまったく異なりうる
- Company A: アウトバウンド拡大のために採用中で、自社が連携できるツールを使っており、自社製品がうまく解決できるペインがあり、最近Webサイトを訪問しており、過去のチャンピオンをちょうど採用した
- Company B: 同じくSDRを採用中だが、自社が置き換えにくい既存ツールをすでに使っており、自社とうまく連携しないワークフローを持ち、コールドコールしたSDRに対して先月3年契約を結んだと話している
- エージェントがすべてのデータへアクセスできず、自社がどこで勝ててどこが弱いのか・既存ツールとの比較・連携システム・最もよく解決するペイン・追う価値のある購買シナリオを理解していなければ、成果は出せない
- シグナルをAIに供給することは簡単な部分であり、難しいのはどのシグナルが重要か・どう順位付けするか・何を前面に出すかについて、AIがビジネスを十分理解していることを保証することである
Problem Two — 借り物のロジックは競争力にならない
- 戦略的欠陥は、本来自社の中核的競争優位であるべきものを外部に委託している点にある
- ターゲティング・仮説生成などの上流インテリジェンス(upstream intelligence) をAI GTMベンダーから購入すること
- それを委託すると、そのモデル・ベンダーを使うすべての人と同じ意思決定ロジックを回すことになる
- 誰もがアクセスできるシグナルや戦略は、定義上優位にはなりえない
- 独自になりうる唯一のものは、そこから何をするか、つまり、どのシグナルが重要か・どう組み合わせるか・自社にとって何を意味するかを決める解釈(interpretation)レイヤーである
- その解釈レイヤーまでベンダーから買ってしまえば、最後に残った優位性までコモディティ化する
- ただし、ワークフローの一部は購入するのが妥当である
- アカウント強化、求人票検索、Webサイトスクレイピング、下書き生成、コール要約、リードルーティング、データ同期、メール送信のような実行レイヤー(execution layer) ツールを自作するのは非効率である
- 一方で委託してはならない上流かつ中核の領域
- どのアカウントを優先するか / どのシグナルが実際に重要か / どのシグナルの組み合わせが本物の購買シナリオを示すか / どのペルソナが関与するか / どのペイン仮説を使うか / どんな証拠を添えるか / 受注・失注・返信・商談設定から何を学ぶか
- 単純なルール
- Buy: 仕事を実行するツール(求人票の特定、連絡先強化、メールコピー生成、メール送信など)
- Own: 意思決定に影響するロジック(求人票から何を探すか、どのシグナルをスクレイピングするか、アカウント優先順位をどう付けるかなど)
The Fix — GTM Context Layerの構築
- AIで成果を出すチームは、ソースデータと実行ツールの間にインテリジェンスレイヤー(intelligence layer) を置き、シグナルを自社にしか作れない観点へ変換している
- これがGTM Context Layerであり、どのシグナルが重要か・どう解釈するか・どんなシナリオを示唆するか・誰が関心を持つか・どんなメッセージが合うかを人とエージェントに知らせる独自システムである
- 強力なGTM Context Layerは3つの部分で構成される
-
Data Foundation(データ基盤)
- CRMデータ、案件履歴、失注理由、製品利用、Webサイト活動、エンリッチメント(enrichment)、求人票、ニュース、テクノグラフィック、コールノート、メールエンゲージメント、パートナーノート、担当者活動などの原材料を一か所に集約する
- 構築方法: Warehouse + ETLパイプライン、CRM同期、エンリッチメントAPI、製品イベント、スクレイピング、正規化テーブル
- 効果: 人とエージェントにアカウントの全体像を提供する
-
GTM Decision Logic(意思決定ロジック)
- ICP、ペルソナ、アカウントスコアリング、シグナル重み付け、ルーティングロジック、購買シナリオ、除外基準(disqualifier)、プレイブックを定義するルールベースのレイヤー
- 構築方法: SQL/dbtモデル、スコアリングテーブル、ルールエンジン、セグメント、ビジネスが所有するロジック
- 効果: ソースデータを自社固有のGTM判断へ変換する本当の競争優位(edge)
-
AI Orchestration Layer(AIオーケストレーションレイヤー)
- 検索(retrieval)、ツール呼び出し、プロンプトルーティング、エージェントスキル、コンテキスト組み立て、出力生成を調整するワークフローレイヤー
- どのコンテキストを持ってくるか・どのソースを確認するか・どのシグナルをランキングするか・どのプレイブックを適用するか・どのスキルを実行するかを決める
- 構築方法: ベクトル検索、SQLクエリ、プロンプトルーティング、システムプロンプト、ツール呼び出し、エージェントスキル、構造化出力、フィードバックループ
- 効果: 戦略を行動へ変換し、より良い優先順位付け・より鋭いメッセージング・GTMロジックに従うエージェントを実現する
-
- うまく実装すれば、エージェントの出力は次のように変わる
- 変更前: "Acme is hiring SDRs and had a closed-lost opportunity last year. Reach out about renewed pipeline growth."
- 変更後: "Acme is hiring SDRs and RevOps, uses a stack we consolidate well, and lost last time due to timing. Prioritize RevOps with a tooling-efficiency angle, Sales with a pipeline-growth angle, and tailor outreach to the pain each team owns."
Where to Start — どこから始めるか
- GTMスタック全体を一晩で作り直す必要はなく、次の3点を点検しながら始めればよい
- Decision Logicの所在を監査する: 誰をターゲットにし、価値をどうポジショニングするかをサードパーティAIアルゴリズムに決めさせていないか確認し、そうならICP定義を社内に取り戻す
- シグナルからシナリオへ転換する: 単一で孤立したイベントでアウトリーチをトリガーせず、データチームに、否定しがたいペインを指し示すイベントの組み合わせを見つけるモデルを作らせる
- オーケストレーションのペイロードを制約する: ツールに何を言うべきか推測させず、見込み客ごとに高度に制約された超文脈的なペイロードを渡す
- 3つすべてを一度にやる必要はなく、1つだけでも実際の意思決定をビジネス内部へ取り戻し、同じ基本ロジックを回している競合より先に進める
Closing — 結論
- GTM向けAIが振るわない理由は単純で、チームが実行は自動化している一方で、その背後にある上流判断(upstream judgment)には投資していないからである
- いまや誰もが同じモデルと同じ既成シグナルを持っている。先行チームを分けるのは、実行の上流で自社が所有するもの、つまり自ら作ったカスタムシグナルと、なぜこのアカウントなのか・なぜ今なのか・誰に・何を言うべきかを理解するコンテキストレイヤーである
- AIは戦略を置き換えるものではなく、その戦略が実際にどれだけ良いかを露わにするだけであり、今日の大半の実装がその証拠である
まだコメントはありません。