Planhat vs Totango

Planhat と Totango はどちらもエンタープライズ向けの Customer Success プラットフォーム層に位置し、どちらもカスタム見積もりで価格設定され、どちらも Gainsight の構築が重すぎると感じたときに候補に挙げるツールです。違いはアーキテクチャにあります。Planhat は柔軟なオブジェクト指向のデータモデルを渡し、スキーマ、health のロジック、自動化を自分で設計することを前提とします。Totango は事前構築済みのプログラム（SuccessBLOCs と SuccessPlays）を提供し、アカウントのセグメントに対してオンにします。ルーティングの問いは、自社の顧客構造が標準的な CS スキーマに収まるか（その場合は Totango のほうが速い）、収まらないか（その場合は Planhat のモデリング能力こそが購入する全理由になる）です。第2の軸は AI です。Planhat は自社の MCP server を備えた AI-native ですが、Totango はそうではありません。

Planhat が勝つ点

• データモデルこそが製品である。 Planhat では独自のオブジェクト（Companies、Contacts、Opportunities に加え、Issues、Projects、Assets といったカスタムモデル）をモデリングし、それらを1対多および多対多で関連付けられます。アカウントがマルチエンティティ、製品が使用量ベース、デリバリーがプロジェクトベースである場合、Totango の固定された CS スキーマに無理に押し込むのではなく、ネイティブにモデリングできます。これが Planhat を選ぶ唯一の理由であり、当てはまる場合には決定的です。
• 自社の MCP とエージェント型 AI。 Planhat はネイティブの MCP server（Apideck のラッパーではない）を備え、Claude や他の LLM をオブジェクト単位の権限管理付きで Planhat のライブデータに接続し、自動化の中で Anthropic、OpenAI、Azure OpenAI、Gemini に対して AI ステップを実行します。Totango は AI-native ではなく MCP server もありません。組み込みの AI 支援はカテゴリの後発です。ライブの顧客データへのエージェント型アクセスが motion の中核であるなら、これは便利な追加機能ではなく、譲れない一線です。
• CS、CRM、サービスを単一のデータレイヤーで。 Planhat の3つのモジュールファミリー（CRM、CSP、PSA）は、プリセールス、ポストセールス、プロフェッショナルサービスのデリバリーを同じモデル上で動かします。サービスも請求する SaaS 企業は、3つのベンダーを単一のデータレイヤーに統合できます。Totango は CS プラットフォームであり、PSA の領域は持ちません。
• Revenue と health がモデルを共有する。 更新の forecasting、NRR/GRR、health scoring は同じオブジェクトから読み込むため、RevOps と CS は2つのシステムを突き合わせるのではなく、1つの数字をめぐって議論します。

Totango が勝つ点

• 事前構築済みのプログラムは白紙のキャンバスに勝る。 SuccessBLOCs は、ゼロから設計する workflow ではなく、オンにするだけのテンプレートとして onboarding、アダプション、更新、リスクのプログラムを提供します。標準的な B2B SaaS の CS motion にとって、これは Planhat のスキーマと自動化をゼロから設計するよりも、価値実現までの時間が劇的に速くなります。
• 人員を割り当てるデータモデリングのプロジェクトがない。 Planhat の柔軟性は設定コストです。意見を持ったデフォルトがないため、スキーマ設計は自分の責任になります。Totango は最初から機能する CS 構造を提供します。60-120 日のモデリング構築を回すための専任の社内データ責任者がいないチームは、Totango からより早く、より多くの価値を得られます。
• 複数ソースにまたがる成熟した health scoring。 Totango は製品の使用状況、サポートチケット、NPS/CSAT、CRM データを重み付けされたアカウントの health score に統合し、自動化された plays を駆動します。scoring の領域は十分に踏み固められており、更新管理のレイヤーは Catalyst との合併で成長しました。これは net-revenue-retention の forecasting が拘束力のある KPI である場合に重要です。
• スキーマが標準的なら立ち上げが軽い。 顧客が既製の CS モデルに収まるなら、決して使わないモデリングの柔軟性に対して Planhat に支払い、無駄に構築コストを負担することになります。

価格の実態

どちらも self-serve の価格を公開しておらず、どちらもカスタムの見積もりベースです。Planhat は管理対象アカウント数と tier、加えて使用量ベースのコンポーネント（自動化の実行回数、追加アカウント、トランザクションメール）で価格が決まります。多くの mid-market 導入は Professional tier で年間 $25K-$45K の範囲に収まり、より広いバンドはおよそ $15K-$60K、エンタープライズは $60K 超です。Totango は CSM の seat 数、管理対象の顧客ベースの規模、データ量、機能セットで価格が決まり、実装は別の項目です。SMB のロールアウトは $5K 前後から始まることが多く、エンタープライズの実装は $50K を超えることがあります。ライセンスの数字は同程度ですが、本当のコスト差は構築です。Planhat 側の隠れた項目はデータモデリングのプロジェクトであり、Totango 側の隠れた項目は別途価格設定される実装です。どちらのベース見積もりも下限とみなしてください。特に Planhat では、契約前に自動化の実行回数のボリュームをモデリングしないと、使用量ベースの項目がベースライセンスを上回って膨らみます。

実装の労力

どちらも、health score が信頼できるものになるまでに、専任の社内責任者と 60-120 日の期間を求めます。エンタープライズ層ではどちらも plug-and-play ではありません。違いは、その日数が何を買うかです。Planhat ではデータモデルの設計に費やします。モデリングが不十分な Planhat は、設定済みに見えても関係が間違っているため、硬直したツールよりも悪くなります。Totango では、事前構築済みのプログラムに upstream の入力（製品テレメトリ、サポート、NPS）を配線することに費やします。スキーマはすでに決まっています。Totango の道筋は間違えるアーキテクチャ上の判断が少なく、これは構造が標準的なときは正しいトレードオフであり、標準的でないときは間違ったトレードオフです。どちらでも、最初の health score は 3-5 個の入力に抑え、四半期ごとに整理してください。どちらのプラットフォームの柔軟性も、アクション不能になるほど複雑な score を誘発します。

結論

• Planhat を選ぶのは、顧客構造または商業構造が標準的な CS スキーマに収まらない場合（マルチエンティティのアカウント、使用量ベースの製品、プロジェクトベースのサービス）、あるいは MCP 経由でのライブ顧客データへのエージェント型 AI アクセスが motion の中核である場合、あるいは CS、CRM、サービス（PSA）を単一のデータレイヤーに統合したい場合です。専任のデータ責任者と、設定プロジェクトに取り組む意欲が必要です。
• Totango を選ぶのは、標準的な SaaS 構造を持つ正式な CS 組織（$20M+ ARR）があり、playbook を設計するのではなく事前構築済みの SuccessBLOCs で onboarding/アダプション/更新のプログラムを素早く立ち上げたく、そこに到達するためにデータモデリングの構築に人員を割きたくない場合です。
• どちらも選ばないのは、$10M ARR 未満で CSM が 5 人未満のチームの場合です。その規模ではプラットフォーム料金とロールアウトコストが回収できず、ChurnZero や Vitally がそのバンドで1ドルあたりの価値を多く提供します。

これらの条件なしで選ぶなら、Totango を選んでください。事前構築済みのプログラムがモデリングのプロジェクトなしで価値まで導きますし、ほとんどの CS 組織は自分たちが思うよりも標準的なスキーマを持っています。データ構造が本当に収まらない壁にぶつかったとき、または MCP ベースのエージェント型 AI が不可欠になったときに、Planhat に切り替えてください。