リレーションシップマネージャー、アカウントマネージャー、またはポストセールス CSM が Sales Hub シートに座っているなら、業務にマッチしないソフトウェアにお金を払っている可能性が十分にあります。デフォルトの間違いは、クォータ番号を持つすべてのコマーシャルシートに Sales Hub ライセンスを与え、6 か月後に日常ワークフロー、オープンリクエスト、エスカレーション、SLA タイマー、オーナーシップルーティング、がきれいに住む場所がないことを発見することです。修正はより大きい Sales Hub ではありません。RM ワークフローのための Service Hub と、本物のアップセル Deal のためのチームリードレベルでの単一 Sales シートです。決定は契約の上流に座り、50 RM では年間コスト差は 6 桁を超えます。
なぜ今これが重要なのか
Net Retention は投資家が研いでいるメトリクスで、その背後の運用モデルはようやく新規ロゴモーションが 10 年間受けてきた精査を受けつつあります。Jason Lemkin の、ベンチャー投資家が実際に評価する CS メトリクスについてのフレーミングは率直です：ARR の割合としての CS 支出、CSM ごとのポートフォリオ負荷、グロス対ネットリテンションギャップは、今や一次的なデューデリジェンスの質問です。ポストセールスチームが内部で働くシステムがそれらの数字を生みます。CRM がハンターモーション用に構成されチームが SLA モーションを運用しているなら、メトリクスはダッシュボードからデバッグするのが難しい場所で苦しみます。
デフォルトの間違い：クォータ番号を持つすべての人に Sales シート
私たちが入るほぼすべての中期 HubSpot ロールアウトは同じように始まります。Sales 担当者は Sales Enterprise を得ました、正しい。Marketing は Marketing シートを得ました、正しい。そしてポストセールスチーム、RM、AM、CSM、ときに更新と拡大のハイブリッドロール、も Sales シートを得ました。誰かのプランに番号があり、調達には「コマーシャル」という 1 列しかなかったからです。シートは組織図にフィットします。業務にはフィットしません。
問題は、Sales Hub の UI が新規 Deal のオープン Pipeline を中心に構築されていることです。ユーザーは日々を、自分がエンドツーエンドで所有するステージを横断してレコードを左から右に動かすのに費やすと仮定しています。ほとんどの規制業種 RM はそれをしません。固定ブックを管理し、契約上の SLA に対するインバウンドリクエストに反応し、詰まったアイテムをエスカレーションし、実際に Deal を運用するクローザーにアップセルを表面化します。Sales Hub のプリミティブ、Deal Pipeline、シーケンス、プロスペクティングワークスペース、は日常表面ではありません。Service Hub のプリミティブがそうです。
リレーションシップマネージャーが実際にすること（販売ではない）
ポストセールス機能のために Sales シートを買おうとしているチームに対する診断：典型的な日に、RM は最初に何を開くか？答えが「リクエストキュー」「Inbox」「昨日のオープンアイテム」なら、ワークフローはサービス形です。「Pipeline」なら、Sales 形です。DACH の金融サービスとハイタッチ B2B SaaS を横断して、RM ワークフローは 4 つの仕事に分解されます。
- SLA タイマーを運用する。契約上または暗黙の応答ウィンドウに対するオープンリクエスト。RM は定義されたブックに対する初回応答時間と解決時間を所有します。
- ルーティングとエスカレーション。閾値、複雑さ、または権限を超えるケースは、チームリード、専門家キュー、または規制プロセス所有者に行きます。ルーティングは Deal 駆動ではなくルール駆動です。
- 関係性履歴を保持する。すべての RM タッチポイント、コールノート、Email スレッド、ミーティングアウトカム、は顧客レコードに添付され、次のインタラクションが文脈から始まるようにします。
- アップセルを表面化する。会話が拡大機会を明らかにすると、RM は認定 Lead を Sales シートを持つクローザーに渡します。RM は Deal をエンドツーエンドで運用することはまれです。
それら 4 つの仕事のうち 3 つは Service Hub ネイティブです。1 つは Sales Hub ネイティブで、それは週次時間のもっとも小さなスライスです。
RM ワークフローが実際に必要とする Service Hub プリミティブ
Deal ではなく Ticket
Service Hub の Ticket は、応答ウィンドウ、オーナー、ステータス、クローズを持つオープン業務アイテムのための正しいオブジェクトです。Deal は間違ったオブジェクトです、ベロシティレポートを歪め、Pipeline フォーキャストを汚染し、SLA を隠します。最初のアーキテクチャ上の決定は、日常業務表面を Deal オブジェクトから Ticket に動かすことです。更新モーションは Deal で保つ価値のある例外です。リアクティブ RM 業務はそうではありません。
SLA ポリシー、キュー、ルーティング
Service Hub は SLA ポリシー（Ticket タイプまたは優先度別の応答および解決ウィンドウ）、スキルベースルーティング付き共有 Inbox、キュービューを出荷します。これらは RM が毎日必要とするプリミティブです。Deal レコード上にネイティブ SLA タイマーはありません。Deal 上に SLA トラッキングをボルトオンするチームは、Service Hub が初日に与えるものを再現するためにカスタムプロパティ、計算値、ワークフローを書くことになります。
会話ルーティングと共有 Inbox
ほとんどの規制業種 RM チームは共有 Inbox に対して運用します：顧客が単一のアドレスに書き、ルーティングがどの RM、専門家、エスカレーションキューが拾うかを決めます。そのプリミティブは Service Hub にきれいに住みます。Sales Hub にボルトオンされると、ネイティブトリアージ UI のない壊れやすい割り当てワークフローになります。
ハイブリッドモデル：RM のための Service シート、チームリードレベルでの 1 つの Sales シート
監査の下で保つパターンはハイブリッドです。RM は完全な Ticket、SLA、Inbox アクセス付きの Service Hub Professional または Enterprise シートに座ります。チームリード、またはポッドごとの 1 名の専任アップセルクローザー、は Sales Hub シートを携え、拡大閾値を越える任意の Deal を運用します。RM からクローザーへのハンドオフ自体がワークフローです：「アップセル認定」とフラグされた Ticket が、会話履歴が事前に添付された Deal をチームリードの Pipeline に作成します。RM は Deal を開くことはありません。クローザーは Ticket キューを開くことはありません。両者は同じ顧客レコードに触れます。
してはいけないことはダブルライセンスです。「念のため」にすべての RM に Service シートと Sales シートの両方を与えることは、同じ間違いのもっとも高価な形です、ワークフロー問題を解決せずにシートコストを倍にします。診断は同じままです：ユーザーは最初に何を開くか？
現場で見たパターン
50 RM ブックを持つ DACH の金融サービスチームが、すべての RM を Sales Hub Enterprise に置く HubSpot 構成を引き継ぎました。監査の発見は、前四半期に Deal ステージを動かした RM はいない、ということでした、彼らが触れたすべてのレコードは Deal としてモデル化されたサービスリクエストで、SLA タイマーとキュールーティングを再現しようとするカスタムプロパティ付きでした。再構築は RM ワークフローを適切な SLA ポリシー、共有 Inbox、実際のエスカレーションロジックを反映する Ticket Pipeline を備えた Service Hub Professional に動かしました。3 つの Sales Hub シートはチームリードと専任アップセル層にとどまりました。年間シートコスト差は 6 桁を超え、応答時間レポートはついにカスタム計算ではなくネイティブフィールドに紐づき、新スキーマでの最初の RM オンボーディングは前のコホートが必要とした時間のおよそ 3 分の 1 で完了しました。仕事は変わっていません。システムが戦うのをやめました。
解決策：シート決定のためのプレイブック
ポストセールスチームの更新または調達サイクルの前に。
- シートの前にワークフローを監査してください。2 名の RM と丸 1 日座ります。彼らが何を、どの順序で開くか観察します。キューまたは昨日のオープンアイテムなら、Service Hub を買っています。
- 4 つの仕事をマップしてください。SLA、ルーティング、履歴、アップセル。各々に対する週次 RM 時間の割合を書きます。シートの決定は肩書ではなく割合から落ちてきます。
- 日常表面を Deal オブジェクトから動かしてください。リアクティブ業務は Ticket、Deal は本物の更新と拡大モーションのみ。RM のエスカレーションロジックを反映するように Ticket Pipeline を構築します。
- アップセルハンドオフをワークフローとして定義してください。拡大のためにフラグされた Ticket が、会話履歴が事前に添付された Deal をクローザーの Pipeline に作成します。トリガー、オーナー、SLA をハンドオフ自体にドキュメント化します。
- Sales シートを適正サイズにしてください。チームリードと専任アップセルロールは Sales Hub を得ます。ほとんどの RM はそうではありません。「念のため」のダブルライセンスに抵抗します。
- レポートをネイティブフィールドに対して配線してください。応答および解決時間は、Deal 上のカスタム計算ではなく Service Hub の SLA フィールドに解決すべきです。ネイティブフィールドは更新と管理者ハンドオーバーを生き残ります。
- すべての更新で監査を再実行してください。シート数は漂流します。ロールは形を変えます。シートの決定を 4 つの仕事のマップに対する四半期レビューとして扱ってください。
シートの決定が業務にマッチするなら、更新は予算会話です。マッチしないなら、更新は移行プロジェクトです。
Checkpoint がどう関わるか
Checkpoint で運営するポストセールス CRM 業務の大半は、まさにこの診断から始まります：Service Hub のプリミティブを必要とするワークフローのために Sales Hub シートを買い、ミスマッチに 1 年お金を払ってきたチーム。アンワインドはシートライセンス、オブジェクトアーキテクチャ、レポート、チームトレーニングに触れます。ポストセールスチームが Ticket-as-Deal を運用しているなら、次の更新の前に私たちにご相談ください、監査は最初の四半期で元を取ります。シートの決定の背後の運用モデルについては、RevOps と Customer Success オペレーションのサービスもご参照ください。
出典
- Lemkin, Jason. 「The Top 10 Customer Success Metrics Investors Really Care About in 2025 with Gainsight's CEO Nick Mehta」 SaaStr。saastr.com
- Blake, Dave. 「100 customer success leaders weigh in on the most important metrics to measure」 OpenView、2017 年 7 月 10 日。openviewpartners.com
Carolina Decastri