Vitally vs Planhat

Vitally と Planhat はどちらも mid-market から enterprise の Customer Success レイヤーに位置し、複雑さの曲線上では ChurnZero の上、Gainsight の下にあります。両者の違いは機能ではありません。どちらも health、更新、CSM のワークフローを追跡します。違いはデータモデルです。Vitally は CSM の日々の作業面を中心に作られています。notion スタイルで素早く設定でき、CSM が自分の担当アカウントを管理するために常駐するワークスペースです。Planhat は自分で設計するオブジェクト指向のデータモデルを中心に作られており、標準的な SaaS スキーマに収まらない顧客構造を表現できます。ルーティングの問いは、ボトルネックが CSM の生産性なのか (Vitally)、それとも既製スキーマでは保持できない顧客の実態をモデリングすることなのか (Planhat) です。

Vitally が勝つところ

• CSM の日々のワークフロー。 Vitally は通常の CS プラットフォームの形を反転させます。多くはダッシュボード偏重でワークフローが薄いのですが、Vitally は CSM が一日中実際に作業する面であり、担当ごとに notion ライクなカスタムレイアウトを持てます。CSM を Salesforce、プロダクト分析ツール、Slack から 1 か所に集めることが目的なら、Vitally のワークフローの操作性はこの層で最も優れています。
• Time to value が速い。 Vitally の設定はレイアウトと health score の作業であり、データモデルの設計ではありません。mid-market のチームならおよそ 4-8 週間で立ち上げられます (health score の設計が最も時間のかかる工程です)。Planhat のオープンなスキーマは、まずオブジェクトと関係を設計する必要があり、現実的な構築は 60-120 日に伸びます。
• プロダクト利用の health が標準装備。 Vitally は Segment、Mixpanel、Amplitude から直接データを引き込むため、カスタムの ETL なしで health score がプロダクト内の行動を反映します。Planhat も同じシグナルをモデル化できますが、取り込みとスコアリングのロジックはスキーマ設計の一部として自分で構築します。
• 標準的な SaaS ではモデリング負荷が低い。 顧客構造が 1 アカウント 1 サブスクリプションという通常の SaaS の形なら、Vitally の意見のあるデフォルトは利点です。間違える余地が少なくなります。Planhat の柔軟性は、必要ないときには重荷になります。

Planhat が勝つところ

• データモデルこそが製品。 Planhat では自分のオブジェクトを定義できます。Companies、Contacts、Opportunities に加え、Issues、Projects、Assets といったカスタムモデルを、一対多および多対多の関係で結べます。マルチエンティティのアカウント、利用量ベースの製品、プロジェクト型サービスは、固定された CS スキーマに押し込まれるのではなく、ネイティブにマッピングされます。Vitally のスキーマはより固定的で、非標準の階層は相性が悪いです。
• 自社製の MCP サーバー。 Planhat はネイティブの MCP サーバー (Apideck のラッパーではありません) を提供し、Claude やその他の LLM をライブの顧客データにオブジェクト単位の権限管理付きで接続します。モデルはコンテキストを読み取り、あなたが制御するガバナンスのもとでタスクを作成したりレコードを更新したりできます。Vitally には API はありますが MCP サーバーはありません (mcp_available: false)。ライブデータへのエージェント的な AI アクセスを統合構築なしに求める CS や RevOps のチームにとって、これは両者の間の実質的なギャップです。
• CRM + CSP + PSA を 1 つのデータレイヤーで。 Planhat は 3 つのモジュールファミリーを提供します。CRM (営業とアカウント管理)、CSP (customer success)、PSA (プロフェッショナルサービスの自動化) です。1 つの組織がプリセール、ポストセール、サービス提供を単一のデータモデル上で運用できます。Vitally は CS プラットフォームであり、CRM を置き換えることもサービス提供を動かすこともしません。
• Revenue と health が 1 つのソースを共有。 更新予測、NRR/GRR の追跡、health scoring が同じデータモデルを読むため、RevOps と CS が 2 つのシステムを突き合わせる必要がなくなります。Vitally も更新と health を追跡しますが、CRM とサービスをまたぐ統合のストーリーは Planhat のものです。

Pricing の実態

両者ともカスタム見積もりで、self-serve の価格は公開していません。価格帯は重なるため、価格が決め手になることはまれです。Vitally は 10-30 CSM の mid-market 導入でおよそ $30K-$70K/年、50 以上の CSM では座席課金に platform fee を加えた構造で $80K-$200K+ まで上がります。Planhat は純粋な座席数ではなく、管理アカウント数と tier に基づきます。mid-market 導入の多くは Professional tier で $25K-$45K/年の範囲に収まり、より広いバンドはおよそ $15K-$60K、enterprise は $60K 超です。Planhat は利用量ベースの項目 (自動化の実行回数、追加アカウント、トランザクションメール) を加算し、これがベースライセンスを上回って膨らむことがあるため、ベース見積もりは下限であって請求額ではありません。Vitally の座席課金モデルは CSM を増やすときに予測しやすい一方、規模が大きくなると上昇が速くなります。同等の mid-market スコープでは両者は同じバンド内にあり、コスト差はそれを根拠にルーティングするほど大きくありません。

実装の労力

Vitally: およそ 4-8 週間で、health score の設計がクリティカルパスです。リスクは設定のドリフトです。notion スタイルの柔軟性は CSM ごとに異なるレイアウトを作ることを意味するため、チーム標準のビューを保守する単一の admin を置くべきです。ただし設計すべきスキーマがないため、構築は範囲が限定されます。

Planhat: 60-120 日と、名前のある社内データオーナーを確保してください。商談を勝ち取るオープンなモデルは、同時に実装コストでもあります。スキーマ、health のロジック、自動化を自分で設計するため、モデリングが不十分な Planhat は固定的なツールより悪くなります。設定済みに見えるのに関係が間違っているからです。モジュールは順番に進めてください。まず CSP を立ち上げて health と更新のデータを実証し、モデルが安定してから CRM や PSA を追加します。MCP サーバーを有効にする場合は、読み取り専用で始め、セキュリティレビューの後にオブジェクト単位で書き込みを有効にしてください。

結論

• Vitally を選ぶ のは、顧客構造が標準的な SaaS の形で、ボトルネックが CSM の生産性であり、最小限の ETL 作業でプロダクト利用の health scoring が欲しく、2 か月未満でプラットフォームを稼働させたい場合です。スプレッドシートを卒業したが顧客データの再モデリングは不要な 10-50 CSM のチームにとって正しい選択です。
• Planhat を選ぶ のは、顧客または商業構造が既製スキーマに収まらない場合 (マルチエンティティ、利用量ベース、プロジェクト型サービス)、CRM、CS、PSA を 1 つのデータレイヤーに統合したい場合、または自社製の MCP サーバー経由でライブの顧客データへのエージェント的な AI アクセスが必要な場合です。それを適切にモデリングできるデータ所有の余力があるチームに報います。
• どちらも選ばない のは、$10M ARR 未満で CSM が 5 人未満、標準スキーマのチームの場合です。その規模では ChurnZero または Salesforce + スプレッドシートの構成のほうが 1 ドルあたりの価値が高くなります。10 以上の CSM と、定義された customer-health の運用ができた時点で再検討してください。

これらの条件なしに選ぶなら、Vitally を選んでください。モデリング負荷の低さと time to value の速さが、mid-market の CS チームにとってリスクの低いデフォルトになります。顧客データが本当に固定スキーマに収まらなくなったとき、または MCP ベースのエージェント的アクセスが不可欠になったときに Planhat へ切り替えてください。どちらも Vitally が構造的に追随できない理由であり、どちらも本当にそうなったときには容易に見分けられます。