Sales から CS へのハンドオフは、オンボーディングの問題の大半が生まれる場所です。AE はクローズして次の deal に移り、CSM は closed-won ステージと契約金額が入っているものの、顧客がなぜ購入したのか、何を約束されたのかについてはほとんど何も書かれていない HubSpot レコードを引き継ぎます。CSM は最初のキックオフ call を、オンボーディングを進める代わりに deal を再発見することに費やします。この SOP は 3 つのもので解決します。deal が closed-won とマークされる前に AE が埋める固定のハンドオフ項目セット、ハンドオフを記憶ではなく deal ステージに結び付けるタイミングルール、そして毎回同じように走るキックオフシーケンスです。これは意図的に退屈です。AE が良い Slack メッセージを書くのを覚えていることに依存するハンドオフは、AE が PTO の週に失敗するハンドオフです。
artifact バンドルは apps/web/public/artifacts/sales-to-cs-handoff-sop/ にあります。handoff-sop.md(手順そのもの、Notion または HubSpot のナレッジベースに貼り付ける準備ができています)、handoff-fields.csv(HubSpot 管理者がプロビジョニングするための、型と必須/任意フラグ付きの項目マニフェスト)、slack-handoff-template.md(AE が投稿する正規のチャネルメッセージ)を含みます。ロールアウト前に 3 つすべてを自社の項目名とチャネルの慣習に合わせて調整してください。
いつ使うか
この SOP は、明確に分かれた Sales チームと CS チーム——クローズまで deal を所有する AE と、その後に顧客を所有する CSM——があり、両者間のハンドオフが非公式または文書化されていないときに使います。典型的な症状は、CSM がすべてのキックオフ call を、AE がすでに答えを知っていたことを顧客に尋ねることから始めることです。エグゼクティブスポンサーは誰か、90 日後の成功はどう見えるか、なぜ既存ベンダーではなく自社を選んだのか。これらの質問の一つ一つが関係に対する小さな税であり、顧客がそれを払います。
HubSpot を CRM、Slack を社内コミュニケーション層として運用している、100 から 2,000 顧客の範囲のチームに最も適合します。約 100 顧客未満では、AE と CSM は同じ人物であるか、文書化された SOP がオーバーヘッドになるほど近くに座っていることが多いです。約 2,000 を超えると、HubSpot の deal プロパティと Slack 投稿ではなく CTA 経由でハンドオフを駆動する CS プラットフォーム(Gainsight、Catalyst、Vitally、ChurnZero)がおそらく必要です——その規模では手動の投稿こそがスキップされるものです。この SOP は、プロセスが重要だがツーリング予算がまだ専用の CSP を正当化しないバンドにおける正しいツールです。
いつ使わないか
クローズ時のデータ品質に対して AE が責任を負っていない場合は採用しないでください。SOP は項目と同程度にしか良くなく、項目は「closed-won にはハンドオフブロックの完成が必要」が——HubSpot の必須項目ルール、deal ステージのゲート、または完了するまでコミッションを差し戻すマネージャーによって——強制されて初めて埋まります。その強制がなければ、半分しか埋まっていない項目が手に入り、それは何もないより悪いです。CSM がそれを信頼して痛い目に遭うからです。
AE と CSM が実際に話すことの代わりとして使わないでください。項目は構造化された事実を運びますが、テクスチャは運びません——採用について内心不安な champion、deal に反対した procurement の担当者、AE が最後の call で半ば約束した機能。下のシーケンスにある 15 分のウォームハンドオフ call が、そのコンテキストが転送される場所です。それをスキップして項目だけに頼ると、技術的には完成しているが、それでも renewal を沈めるものを見逃すハンドオフが生まれます。
これを renewal や拡大の motion に取り付けないでください。この SOP は新規ロゴのハンドオフ——AE から CSM へ、クローズ時に一度——にスコープされています。renewal と拡大は所有者もシグナルも異なり、それらをこのテンプレートに無理やり通すとノイズが生まれます。
ハンドオフ項目
これらはレコードとともに移動し、後で照会できるよう HubSpot の deal または company プロパティとして存在します。handoff-fields.csv のマニフェストがそれらをプロビジョニングします。必須セット、それぞれ closed-won の前に埋められます。
- エグゼクティブスポンサー(連絡先参照)——この予算が誰のものであり、renewal call を受ける人。日々の champion ではなく、経済的な購買者。
- 日々の champion(連絡先参照)——CSM が毎週一緒に働く相手。スポンサーとは異なることが多いです。
- なぜ購入したか(長文テキスト)——実際のビジネス上のトリガーを 1、2 文で。「legacy ツールの renewal が当社の価格の 3 倍だった」は有用です。「より良い analytics が欲しかった」は有用ではありません。
- 定義された成功 / 指標(長文テキスト)——顧客が勝ちはどう見えると言ったか、理想的には日付付きの数値。これが success plan の北極星になります。
- deal で約束されたもの(長文テキスト)——標準契約に入っていないが AE がコミットしたもの——カスタム統合、特定の go-live 日、roadmap 上の機能。これが最悪のハンドオフ失敗を防ぐ項目です。
- 契約スコープ(構造化)——seats、製品/SKU、ARR、契約開始日と renewal 日。
- 技術環境(長文テキスト)——CRM、data warehouse、SSO プロバイダー、顧客が初日に期待するあらゆる統合。
- 既知のリスク(長文テキスト)——反対した procurement の担当者、競合する社内ツール、懐疑的なエンドユーザーチーム。今表面化させるか、後で痛い思いをして発見するか。
2 つの任意項目は、存在するときに価値を発揮します。call の録画(deal の重要な call の Gong/録画ライブラリへのリンク)と 決定タイムライン(評価がどれだけ走り、他に誰が部屋にいたか)で、これは購入がどれだけの組織的な重みを持つかを CSM に伝えます。
タイミングルール
ハンドオフは AE のカレンダーではなく deal ステージでゲートされます。ルールはこうです。ハンドオフブロックは deal が closed-won に移動できる前に完成していなければならず、ウォームハンドオフ call はクローズから 3 営業日以内に行われなければなりません。リマインダーではなくステージに結び付けることが要点のすべてです——リマインダーは先延ばしにされますが、ステージゲートは pipeline によって強制されます。HubSpot ではこれはステージ上の必須プロパティルールと、ステージ変更時に Slack に投稿する workflow です。
キックオフシーケンス
- AE が closed-won をマークする前にハンドオフブロックを完成させます。 そうでなければ HubSpot のステージゲートが移動を拒否します。
- HubSpot の workflow が
#cs-handoffsに投稿します(closed-won へのステージ変更時)。slack-handoff-template.mdのテンプレートを使用します。company、ARR、スポンサー、champion、購入理由、指標、約束されたもの、deal レコードへのリンク。投稿は割り当てられた CSM を @-メンションします。 - CSM が 1 営業日以内にスレッド内で確認します——リアクションは確認ではありません。CSM は deal で約束されたものの項目を具体的に読んだことを確認しなければなりません。
- AE と CSM が 3 営業日以内に 15 分のウォームハンドオフ call を行います。 アジェンダ。既知のリスクを通し、約束された項目を確認し、項目が保持できない関係のテクスチャを転送します。これは HubSpot のミーティングとしてレコードに記録されます。
- CSM が顧客との外部キックオフをスケジュールします。 すでに deal を読んだ状態で。顧客はなぜ購入したかを再説明することは決してありません。
成功はどう見えるか
3 つの数値を追跡します。第一に、ハンドオフの完成度——すべての必須項目が埋まった closed-won deal の割合。ステージゲートはこれを 2 週間以内にほぼ 100% に押し上げるはずです。もしそれより低いままなら、ゲートは実際には強制されておらず、名誉制度で運用していることになります。第二に、キックオフまでの時間——closed-won から外部キックオフ call までの日数。中央値で 7 営業日未満を目指します。それより長いラグは、オンボーディングが始まる前に顧客の購入モメンタムが減衰していることを意味します。第三に、再発見率——CSM に毎月アンケートします。「直近 5 件のキックオフで、AE が記録しておくべきだったことを顧客に尋ねなければならなかったのは何回ですか?」ゼロを目指します。キックオフあたり 1 を超えるものは、項目は存在するが信頼されていないことを意味し、これは通常ゲートを通すために埋め草で埋める AE に行き着きます。
代替案との比較
フリーテキストの Slack ハンドオフとの比較。 ほとんどのチームの status quo は、AE が思い出したときにチャネルに非構造化メッセージを投稿することです。書くのは速いですが、他のすべてで劣ります。照会できず、強制されず、品質は AE の気分で揺れ、チャネルのスクロールに消えます。構造化項目版は AE に deal あたりおそらく 3 分余分にかかり、ハンドオフを監査可能にします。ボリュームが非常に低く(月 ~5 ハンドオフ未満)、構造がセットアップに見合わない場合にのみフリーテキストを選んでください。
CS プラットフォームの CTA(Gainsight、Catalyst、Vitally、ChurnZero)との比較。 CSP は closed-won 時に自動でハンドオフ CTA を発火させ、ルーティングし、完成度をネイティブに追跡できます——HubSpot プラス Slack より厳密に優れた仕組みです。トレードオフはコストとセットアップです。CSP は年間 5 桁、導入に数週間かかります。すでに所有しているなら、それでハンドオフを駆動し、この SOP の項目リストとシーケンスを中身として使ってください。所有していないなら、この SOP は HubSpot プロパティ 8 個と workflow 1 つをプロビジョニングするコストで価値の 80% を提供します。
何もしないこととの比較。 AE と CSM が同じ人物であるか、机を共有している場合にのみ成立します。2 つの役割が分かれた瞬間、文書化されていないハンドオフは予防可能な早期 churn の最大の単一原因になります——AE が約束した統合が roadmap に一度も載らなかったために月 4 で churn する顧客です。
注意点
- ゲートを通すために埋め草で埋められた項目。 closed-won が項目の完成度でゲートされた瞬間、AE はそれを通すために「n/a」や「メモ参照」と入力するインセンティブを持ちます。ガード。ウォームハンドオフ call を必須にし、deal で約束されたものや成功指標の項目が空またはゴミなら CSM にスレッド内でハンドオフを拒否させます——CSM が受け入れるまで、AE は deal がきれいに引き継がれたとはカウントされません。
- 空白のまま残された deal で約束されたものの項目。 これは最もコストの高い見落としです。AE が行って忘れた口頭のコミットメントで、顧客は覚えていて期待しています。ガード。空のときでも「契約を超えて約束したものはない」という明示的な入力を強制してこの項目を必須にし、空白が見落としではなく意図的な宣言になるようにします。
- Slack 投稿は発火するが誰も確認を所有しない。 どの CSM も割り当てられていないチャネルに投稿されたハンドオフは、虚空へのハンドオフです。ガード。HubSpot の workflow は deal-owner から CSM へのマッピングで特定の割り当て CSM を @-メンションし、SOP は 1 営業日以内のスレッド内確認を要求し、CS リードがそれを追跡します。
- CRM スキーマが変わるにつれて SOP がドリフトする。 名前が変わった HubSpot プロパティや新しい deal ステージは、Slack に投稿する workflow を静かに壊します。ガード。
handoff-fields.csvの項目マニフェストを四半期に一度、稼働中の HubSpot プロパティと照合し、Slack テンプレートの項目リストを deal プロパティ名と同期させてください。