アカウント数が人員数を上回ったときに CS チームが組む スタック です。顧客が2,000社で CSM が8人いて、アカウントごとに専任 CSM を配置することは決してできないと計算が示すような状況です。デジタル CS (tech-touch または one-to-many とも呼ばれます) は、人間の関係性を計装で置き換えます。製品が顧客を導き、サーベイが摩擦を捉え、health score がリスクを示し、シグナルが threshold を越えたときだけ人が介入します。この スタック は、その motion を小さなチームを埋もれさせずに回すためのツール群です。
各ピースの組み合わせ方
- Totango は Customer Success プラットフォームであり、アカウント health の記録システムです。 製品利用状況、サポートチケット、NPS/CSAT、CRM データを加重型の health score にまとめ、個々のアカウントではなくアカウントセグメントに対して SuccessPlays を発火させます。このセグメント単位の自動化こそが、one-to-many の motion を支える理由です。health score がリスクの threshold を越えると Totango が play を発火させ、ChurnZero が in-app イベントを返すと、それが score の input になります。
- ChurnZero は in-app エンゲージメントと、より軽量な CS の ワークフロー レイヤーです。 ウォークスルー、in-app の NPS プロンプト、自動化された email/通知 journey が同梱されているため、tech-touch プログラムは flow ごとにエンジニアリングのチケットを切らずに製品内で顧客を後押しできます。ChurnZero のイベントは Totango の score に流れ込み、その in-app サーベイは逐語テキストを合成レイヤーに渡します。
- Userpilot は no-code の onboarding と機能定着の flow を担います。 定着は NRR の先行指標であり、Userpilot は CS が ファネル の離脱を見て、それを修正する tooltip や チェックリスト を同じツール内で構築する場所です。あるコホートで定着が停滞すると、in-app の介入がここで発火します。long tail に対して CSM の架電は不要です。
- Sprig は voice-of-customer の計測機器です。 in-product サーベイは特定のイベント (onboarding 後、アクション失敗後、機能の初回利用時) で発火し、その Synthesize Agent が自由記述テキストを裏付けの引用付きでテーマにクラスタリングします。ChurnZero が手早い in-app のパルスを捉えるのに対し、Sprig はより深いイベント駆動のリサーチと、health score がなぜ下がったかを説明する session replay を回します。
- Claude は、8人で2,000社を読むことを可能にする合成と トリアージ のレイヤーです。 NPS の逐語回答をテーマとルーティングに トリアージ し (NPS verbatim triage Skill を参照)、Totango のエクスポートから週次のポートフォリオ health digest を作成し (customer-health digest prompt)、Sprig とサーベイのテキストを voice-of-customer の brief に合成します (voice-of-customer synthesis Skill)。1M トークン の コンテキスト ウィンドウがあるからこそ、四半期分のサーベイ回答を単一の プロンプト に投入できます。
なぜこの組み合わせなのか
one-to-many の motion は2つのもので生き死にします。誰が人間の対応を受けるかを決める信頼できる health score と、ライン以下のアカウントにも導きを与える十分な自動化された touch です。Totango は前者 (セグメント単位の scoring と play) を供給し、ChurnZero と Userpilot は後者を供給します。これは tech-touch のアカウントが決して受けない架電の代わりとなる in-app の導きです。Sprig は score がなぜ動いたかを伝えてループを閉じ、Claude は8人のチームが手作業ではできない読み込みを行います。この組み合わせが単一の スイート に勝つ本質的な理由は、4つの仕事すべてをうまくこなすプラットフォームが1つも存在しないことです。CS プラットフォームは in-product の onboarding と AI 合成が弱く、製品ツールは health の記録システムではありません。
コストの実態
mid-market 規模で、有料の4ツールに年間およそ $60K から $180K、加えて Claude の シート を見込んでください。Totango はカスタム見積もりで、CSM の シート 数と管理対象ベースの規模を基準にします。mid-market の導入は5桁台の中盤に着地し、実装は別の項目です (SMB の rollout は約 $5K から、enterprise は $50K 超)。ChurnZero は10〜30人の CSM チームでおよそ $25K〜$70K です。Userpilot の公開 Starter プランの月 $299 は実態を過小評価しています。MAU の上限が低いため大半は見積もりのみの Growth tier に着地し、ChurnZero も Userpilot も製品の MAU で課金するため、請求はシート 数ではなくユーザー数に応じて拡大します。Sprig は月間トラッキングユーザー課金で、Enterprise は5桁台の低〜中盤に着地するのが一般的です。Claude は シート あたり $20〜30、または API のトークン従量課金です。隠れたコストは Totango の60〜120日の実装と、名前のある社内オーナーです。弱い rollout は誰も信頼しない health score を生みます。
マッチのルール
この スタック は、チームが one-to-one でカバーできない低〜中 touch の long tail を抱え、in-app イベントとサーベイが実際に発火する程度に十分計装された製品を持つ、ARR およそ $20〜150M の B2B SaaS の CS 組織に合います。CSM 対アカウント比が 1:150 を越えて上昇し続けているときが正しい選択です。CSM が5人未満で ARR が約 $10M を下回る場合は誤った選択です。Totango のプラットフォーム費用と実装費用は回収できず、より軽量な expansion stack か、単純な CRM と Claude で事足ります。また、すべてのアカウントに既に専任 CSM がいる純粋な high-touch の enterprise motion にも誤った選択です。そこではセグメント単位の自動化はオーバーヘッドにすぎません。
よくあるバリエーション
- Totango を外し、Gainsight を回す。 CSM が50人を超え、より深い設定可能性と enterprise の統合エコシステムが必要なときは Gainsight に切り替えます。代償はより重い build です。事前構築の SuccessBLOCs の速さなら Totango、設定可能性が拘束条件なら Gainsight を選びます。
- ChurnZero を外し、in-app を Userpilot に頼る。 より小規模な product-led チームは in-app レイヤーを Userpilot だけに集約し、health は Totango (あるいは Vitally) に持たせます。journey の自動化ではなく in-app の onboarding が支配的なニーズのときに切り替えます。
- 更新の深さのために Catalyst を追加する。 Totango のポートフォリオに統合された Catalyst 側は、より発達した renewal-management の面を備えています。net-revenue-retention の forecasting と renewal ops が拘束的な KPI のときに有効化します。
この スタック が置き換えないもの
- どのアカウントが tech-touch で、どれが human-touch かを決めるセグメンテーションモデル。スタック はモデルを実行しますが、書きはしません。
- 製品の計装。ChurnZero のウォークスルー、Userpilot の flow、Sprig のサーベイはすべて、エンジニアリングが所有する SDK とイベント パイプラインに依存します。それがなければ in-app レイヤーは休眠状態です。
- CS プラットフォームがネイティブに持たないサブスクリプションデータの深さを担う更新と請求のシステム。
- 人間によるエスカレーションの経路。デジタル CS は難しいアカウントを人にルーティングしますが、人を排除はしません。