「closed-won」がゴールではなくなり、time-to-value が board の問う数字になったときに、B2B SaaS チームが組み上げる stack です。最初の価値に到達しない新規ロゴは、どれだけ良い売り方をしても更新でチャーンします。そして顧客をキックオフから「これは効いている」まで運ぶ運用規律は、この stack に宿ります。意図的に 1 つではなく 5 つの tool で構成しています。なぜなら onboarding の仕事は、プロジェクト層、顧客向けプラン層、サポート層、そしてライフサイクルの handoff にきれいに分かれ、他社が自分の取り分に課す価格でこの 4 つすべてを 1 つのプラットフォームがうまくこなすことはないからです。
各ピースのかみ合わせ
- Rocketlane は内部のプロジェクト + PSA 層です。 実装プラン、リソース配分、time tracking を担います。Salesforce/HubSpot の closed-won の deal が、アカウントコンテキストを添えた Rocketlane プロジェクトを生成し、Nitro が SOW と discovery コールから初期プランを起草します。ここで実装チームは「onboarding はアカウントあたりいくらかかるのか」に答えます。これは QBR のたびに CS-ops が争う数字です。
- Arrows は CRM に溶接された顧客向けの action plan です。 実装プロジェクトが立ち上がると、Arrows は顧客側のプラン（フェーズ、タスク、owner、期限）を HubSpot または Salesforce のレコードに直接ひも付けて公開します。顧客が Arrows のステップを完了すると CRM に書き戻されるので、停滞したプランは CSM と RevOps がすでに見ている停滞したチケットとして表面化します。
- Dock は deal room を onboarding まで運ぶ共有 workspace です。 AE がプリセールスで作った mutual action plan が、ポストセールスの onboarding workspace に変わるため、CSM はステークホルダーのコンテキストをやり直さずに引き継ぎます。外部コラボレーターは全員無料で参加でき、onboarding が顧客側の 8〜15 人に及ぶときに Dock を正しい接面にしているのがこの点です。
- Intercom は in-product のガイドとサポート層です。 Fin が、もろい最初の数週間に製品内の「どうやって…」という大量の質問をさばき、放置すれば CSM をプラン実行から引き離すチケットを deflect します。サポートイベントは CRM に同期するので、新規アカウントからの混乱したチケットの急増は、サポートキューのノイズではなく onboarding リスクのシグナルになります。
- Vitally はライフサイクルの handoff と記録システムです。 Rocketlane プロジェクトが go-live でクローズすると、アカウントは health scoring、アダプション監視、そして NRR の継続的なモーションのために Vitally に handoff されます。Vitally は製品利用シグナルを Segment/Mixpanel から直接引くため、最初の health score は、顧客が onboarding された対象を実際に採用したかどうかを反映します。
なぜこの組み合わせか
素朴な代替案は、重量級の CS プラットフォームを 1 つ買い、その中で onboarding を回すことです。これは 2 つの点で失敗します。プラットフォームのプロジェクト層は専用 PSA より弱く、顧客向けの接面は後付けです。顧客は Gainsight にログインしません。この stack は代わりに、ガラスの両側それぞれに正しい tool を置きます。Rocketlane と Vitally は内部、Arrows と Dock は顧客が見るもの、Intercom は製品そのものに宿ります。handoff こそが設計です。deal が Rocketlane プロジェクトになり、プロジェクトが Arrows/Dock のプランを公開し、サポートが Intercom を流れ、go-live が Vitally への handoff を引き起こします。各境界は手作業のコピペではなく、実際の CRM イベントです。
これをうまく回すチームでの結果は、onboarding のサイクルタイムがおよそ 3 分の 1 短縮され、最初の 90 日のチャーンが測定可能なほど下がることです。顧客は常に次のステップを知り、CSM は常にどのアカウントがプランから外れているかを知るからです。
コストの実際
mid-market チーム（CSM/実装担当 6〜15 人）には、すべて込みでおよそ $40K〜$120K/年 を見込んでください。おおまかな形は次のとおりです。実装チーム向けの Rocketlane は $69/ユーザー/月（Premium。リソースと financials が解放される層）。Arrows はアクティブプランのボリュームに応じたカスタム見積もりで、月あたり 4 桁の低〜中程度で見込みます。Dock は内部シートのみ支払うため月およそ $350〜$1,000。Intercom は $39〜$139/シートに Fin の解決あたり約 $0.99 が加わります。Vitally はカスタムで、mid-market のデプロイは $30K〜$70K/年に着地します。隠れたコストは統合とテンプレート規律です。Vitally の health-score 設計に 4〜8 週間、そして Arrows/Dock のテンプレートに常駐の owner を置かないと workspace の乱立が顧客にポータルを無視するよう仕向けます。
マッチのルール
この stack が適するのは、顧客に宿題のある複数週の構造化された実装を回す、従業員 20〜500 人の帯域の B2B SaaS で、onboarding が複数のステークホルダーに及ぶ場合です。およそ 5〜40 人の専任 onboarding/実装機能と、背骨としての CRM（Salesforce または HubSpot）を前提とします。
onboarding が単一の self-serve チェックリストのときは、この stack は誤りです。low-touch なアカウントを持つ 5 人未満の CS チームは 5 つの tool を買うべきではありません。CRM、Intercom、テンプレート化した email シーケンスで十分です。また、成熟した CS プログラムを持つ CSM 50 人超でも誤りで、そこでは Gainsight の深さが、モーションの多くを 1 つの enterprise プラットフォームに統合する正当性を持ちます。
よくあるバリエーション
- HubSpot 専用ショップ。 Dock を外し、顧客向けプランは Arrows だけに頼ります。Arrows は最も深い HubSpot-native の onboarding 結合なので、プリセールスで deal room を回さない単一 CRM のチームは、Dock の別 workspace を必要としないかもしれません。
- deal room が重い sales-led。 Dock を顧客向けの主接面として残し、Arrows を外します。同じ Dock の workspace がすでに deal room から onboarding まで運ぶからです。組織がプリセールスで Dock を回し、連続した接面を望むときに最適です。
- より軽いライフサイクル層。 Notion 風の柔軟さよりプラグアンドプレイの簡潔さをチームが望むときは Vitally を ChurnZero に、CSM の日々の workflow より renewal-forecasting の深さが重要なときは Catalyst に置き換えます。
- enterprise 統合。 CSM 50 人超では、設定可能性のために Vitally を Gainsight に置き換え、コストの交差点を見込みます。
この stack が置き換えないもの
- 定義された onboarding 方法論。stack はプランを実行しますが、あなたの製品にとって「最初の価値」が何かは決めません。枠組みは customer onboarding を参照してください。
- go-live より先のライフサイクル CS モーション。更新、エクスパンション、そして NRR vs GRR の規律は、この stack ではなくポスト onboarding の stack に宿ります。
- 製品アナリティクス。Vitally は Segment/Mixpanel/Amplitude から利用シグナルを引きますが生成はしません。製品チームがまず意味のあるイベントを計装する必要があります。
- 正式な顧客教育エンジン。academy コース、認定、self-serve の学習パスは、この stack が内側ではなく傍らに前提とする別投資です。