ポストセールマネジメント
Renewal戦略フレームワーク:体系的なRenewalエンジンの構築
企業が何年もRenewalプロセスを場当たり的に行っているのを見てきました。四半期末が来てどの契約が成立するのか誰も分からなくなるまでは、うまくいきます。その後は混乱です。
パターンは常に同じです。Salesは新規ロゴを祝い、実装チームは顧客を稼働させようと懸命に働き、Renewalは後回しにされます。CFOが顧客維持の予測を求めて、誰も体系的に追跡していないことに気づくまでは。
フレームワークが必要です。チェックリストではなく、「契約したばかり」の顧客を予測可能な成功で「再度Renewal」に導く実際のシステムです。
Renewal戦略を実際に機能させるもの
活動のタイムラインは戦略ではありません。アカウントをセグメント化し、チームを構成し、テクノロジーを使用し、結果を測定する方法を考え抜く必要があります。一つでも欠けると、実行する代わりに火消しに追われます。
重要なのは以下です。
セグメンテーション戦略は、どのアカウントが最高のサービスを受け、どれがほぼ自動化できるかを決定します。これを間違えると、小さなアカウントに高価なリソースを浪費しながら、大口顧客へのサービスが不十分になります。
タイムラインとプロセスは、いつ何が起こり、誰が何をするかを定義します。早すぎると顧客は押し付けがましいと感じます。遅すぎると、顧客はすでに代替品を評価し始めています。
チームのオーナーシップは、誰が実際にRenewal収益を所有し、どのように測定されるかを明確にします。ここでの曖昧さは、誰も責任を取らないために契約を失います。
テクノロジーとデータにより、すべてが壊れることなく50アカウントを超えてスケールできます。手動追跡は機能しなくなるまで機能します。
測定と最適化は、同じ間違いを繰り返す代わりに、実際に成功と失敗から学ぶことを意味します。
これら5つの要素が連携して機能すれば、Renewalは予測可能になります。一つでも欠けると、Churnに常に驚かされることになります。
セグメンテーション:すべてのRenewalを同じように扱うのをやめる
CSMチームが5,000ドルのRenewalに20時間を費やし、20万ドルのアカウントを自動運転にしているのを見てきました。どちらの顧客も満足していませんでした。
すべての人に高度なタッチを提供する余裕はありませんし、一部のアカウントはそれを必要としていません。コツは、実際に重要なことに労力を一致させることです。
契約額でセグメント化
15万ドルのEnterprise案件は、8,000ドルのSMBアカウントとはまったく異なるアプローチが必要です。
EnterpriseのRenewal(ARR 10万ドル以上)は120日以上前から開始します。複数のステークホルダーと調整し、おそらく経営陣を巻き込み、確実にカスタム提案を作成します。チーム時間を15〜25時間予算化します。これらのRenewalには多くの場合、調達、法的レビュー、複数の承認レイヤーが含まれます。急ぐことはできません。
Mid-marketのRenewal(ARR 1万〜10万ドル)は60〜90日のサイクルで実行されます。構造化されたタッチポイントとステークホルダーの調整は依然として必要ですが、意思決定はより速いです。チーム時間は5〜10時間を見込みます。ほとんどのMid-market企業は、適切な情報を提供すれば、単一の予算サイクルでRenewal決定を下すことができます。
SMBのRenewal(ARR 1万ドル未満)は、選択的な人間の介入を伴い、ほぼ自動化されているべきです。30〜60日あり、チーム予算は最大3時間です。それ以上費やしている場合、プロセスが壊れています。
これらは厳格なルールではありません。大きな拡大可能性を持つ95,000ドルのアカウントは、Enterpriseの扱いを受けるかもしれません。何年も自動運転で動いている11万ドルのアカウントは、Mid-marketで実行されるかもしれません。判断を使用してください。
ヘルススコアがすべてを変える
健全なアカウントを瀕死のアカウントと同じように扱わないでください。
強力なヘルススコアを持つGreenアカウントは、合理化されたプロセスが必要です。価値を確認し、成長機会を探り、邪魔にならないようにします。小規模なGreenアカウントの場合、これはほぼ完全に自動化できます。満足している顧客をRenewalの手取り足取りよりも、拡大機会を見つけることに時間を費やした方が良いです。
混合シグナルを持つYellowアカウントは、プロアクティブな価値強化が必要です。懸念が反論になる前に対処します。それほど関与していないステークホルダーとの関係を強化します。使用における摩擦点を取り除きます。最も重要なのは、早期にコミットメントを確認することです。30日前まで待って、彼らが競合他社を評価していることを発見しないでください。
リスクのあるRedアカウントは、全面的な介入が必要です。経営陣のエスカレーション、問題解決スプリント、場合によっては製品またはエンジニアリングリソースを投入します。時には譲歩を提供する必要があるかもしれません。そして時には、失う可能性を知りながらSave Playbookを実行する必要があります。
チームが間違えているのは、「重要な顧客だから」と健全なアカウントをリスクのあるアカウントのように扱うことです。それが行うのは、存在しなかった不安を作り出すことだけです。10万ドルのアカウントが95のヘルススコアと強いエンゲージメントを持っている場合、Renewalを過剰にエンジニアリングしないでください。
機会タイプがモーションを決定
すべてのRenewalが現状維持を目的としているわけではありません。
同じ条件でのFlat Renewalは簡単であるべきです。焦点は価値の確認と迅速な対応です。最小限の交渉、効率的なプロセス。一年中仕事をしていれば、これらは最も簡単な勝利です。
成長機会が見えるExpansion Renewalは、異なる会話が必要です。拡大をリードし、RenewalプラスGrowthをより大きな契約にバンドルします。これは通常、Salesの関与とより複雑さを意味します。しかし、収益を維持するだけでなく成長させているので、価値があります。
At-risk Renewalは、Save戦略の展開が必要です。問題に直接対処し、おそらく条件の削減や譲歩を提供します。ある時点で難しい決断を下す必要があります。戦うか手放すか。すべてのアカウントがどんな犠牲を払ってでも救う価値があるわけではありません。
予定より前のEarly Renewalは、コミットメントを確保することであり、多くの場合、複数年の条件を伴います。通常、予測可能性と引き換えに何らかのインセンティブや割引を提供しています。獲得できれば素晴らしいです。将来のChurnリスクを減らすからです。
これらを混同すると、チームと顧客の両方を混乱させます。Expansion RenewalをFlat Renewalのように実行すると、お金を残すことになります。At-risk RenewalをExpansionのように扱うと、全員の時間を無駄にします。
タッチモデルを現実に合わせる
各Renewalに実際にどれだけの人間の介入が必要ですか?
自動Renewalと支払いファイルを持つ小規模契約の場合、人間のタッチなしでAuto-renewalが機能します。顧客は通知を受け取りますが、積極的にオプトアウトする必要があります。これは契約がそれをサポートし、顧客関係が堅実な場合にのみ機能します。
Assisted Renewalは、自動リマインダーと軽い人間のチェックインを組み合わせます。CSMがヘルスをレビューし、すべてが良好であることを確認し、おそらく1回の簡単な電話をします。標準条件、最小限の議論。個人的な注意が価値を追加するが、重いプロセスは必要ない小規模で健全なアカウントに最適です。
Negotiated Renewalは、カスタム条件、価格討論、複数の会議、ステークホルダーの調整を伴う完全なSalesプロセスです。大規模または複雑なアカウントの標準。これらには時間と専門知識がかかるので、それを正当化するアカウントにこのモーションを適用していることを確認してください。
EnterpriseのRenewalを自動化しようとして、顧客が無視されていると感じる理由を疑問に思うチームを見てきました。また、200のSMB Renewalを手動で管理し、CSMを燃え尽きさせるチームも見てきました。アカウントを最初から適切なモーションで開始してください。
セグメントに一致するプロセスの構築
アカウントをセグメント化したら、各セグメントに適切なプロセスが必要です。実際に機能するものは以下の通りです。
Enterpriseプロセス:時間をかける
EnterpriseのRenewalには最低120日以上が必要です。過剰に聞こえることは分かっています。そうではありません。
120日前に、CSMと管理チームで完全なアカウントレビューを行います。ヘルスを評価し、リスクを評価し、拡大機会を分析します。人々が役割を変更するためステークホルダーマップを更新します。戦略について社内の調整を図ります。これは計画時間であり、まだ顧客に面した段階ではありません。
90日前に、Executive Business Reviewをスケジュールします。価値文書とROI分析を編纂します。完全なアカウントチームで社内でRenewalを開始します。全員がこれが来ることと、彼らが何の役割を果たすかを知る必要があります。
60日前に、ステークホルダーに正式なRenewal通知を送信します。価値レビュー会議を実施します。彼らの将来の状態とニーズについて議論を開始します。意味がある場合は拡大機会を提示します。初期条件と価格を共有し、後で驚きがないようにします。
45日前に、正式な提案を開発します。双方の法務と調達を関与させます。経営陣の調整会議を設定します。拡大をバンドルする場合、これらの条件を最終決定するタイミングです。
30日前に、提案を正式に提示します。必要に応じて交渉を開始します。すべての懸念と反論に対処します。Enterpriseには承認の層があるため、承認プロセスを開始します。
14日前に、最終条件を確認します。契約を生成して送信します。署名ワークフローを開始します。非標準的な何かがある場合、支払い条件を手配します。
署名後、チームと祝い、感謝します。次の年の計画を開始します。Renewalプロセスは実際に決して止まらないからです。
このタイムラインは全員に余裕を与えます。Enterpriseの決定には、競合する優先事項を持つ複数の人々が関与します。これを60日に圧縮しようとすると、不必要なストレスが生まれ、多くの場合、契約が次の四半期に遅れます。
Mid-marketプロセス:より速く動く
Mid-market企業は、より少ない人々が関与しているため、より速く決定を下します。
90日前(大規模なMid-marketアカウントの場合はオプション)、社内アカウントヘルスレビュー、リスク評価、拡大分析を行います。
60日前に、主要連絡先にRenewal通知を送信します。ビジネスレビューまたは価値サマリーを提供します。Renewal会話を開始します。
45日前に、提案を開発します。価格と条件を確認します。ステークホルダーの調整を図ります。
30日前に、提案を提出します。質問と反論に対処します。必要に応じて交渉します。
14日前に、合意を最終決定し、署名を取得します。支払いを処理します。
Mid-marketアカウントには構造が必要ですが、Enterpriseが必要とする精巧なタイムラインは必要ありません。基礎がしっかりしていれば、提案から署名まで2週間で移動できます。
SMBプロセス:可能な限りすべてを自動化
SMBのRenewalはほぼ自動運転で実行されるべきです。
60日前に、自動Renewalリマインダーを送信します。CSMまたはTech-touchで簡単なヘルスチェックを行います。
30日前に、Renewal提案を自動生成します。明確な条件と、可能であれば1クリックRenewalオプションを含むメールを送信します。
14日前に、フォローアップリマインダーを送信します。必要に応じて簡単なチェックイン電話をします。
7日前に、最終リマインダーを送信します。応答がない場合のみエスカレートします。
SMB Renewalでの人間の時間は、実際の問題または拡大機会のために確保されるべきです。SMB Renewalごとに3時間を費やしている場合、間違っています。
Renewalを所有する(そして決定方法)
「誰がRenewalを所有するか」という質問は、すべき以上の内部対立を引き起こします。機能するモデルがいくつかあります。重要なのは、1つを選んで明確にすることです。
Renewalスペシャリスト:専門化が意味を成すとき
一部の企業は、CSMとは別の専用Renewal役割を作成します。スペシャリストは60日以上前からすべてのRenewalを所有します。CSMは関係を維持し、スペシャリストがRenewalプロセスを実行します。
これは規模で機能します。四半期ごとに100以上のRenewalを管理している場合、スペシャリストはRenewalプロセス自体の深い専門知識を開発できます。交渉スキル、提案開発、反論処理。彼らは本当に得意になります。
上昇:一貫性、専門化、CSMは信頼できるアドバイザーの役割を維持。
下降:顧客はハンドオフを経験し、調整が複雑になり、十分な量がある場合にのみ機能します。
これが500以上の顧客を持つ企業で美しく機能するのを見てきました。また、50人の顧客を持つ企業では悲惨に失敗するのも見てきました。スペシャリストには十分な仕事がなく、ハンドオフが刺々しく感じられたからです。
CSMオーナーシップ:デフォルトモデル
ほとんどの企業は、CSMがRenewalを所有することから始めます。それは関係を管理することの自然な延長です。
CSMはOnboardingからRenewalまですべてを処理します。顧客のハンドオフなし、よりシンプルな構造、関係の継続性。CSM報酬にはRenewal達成が含まれるため、インセンティブが一致します。
課題は、CSMには交渉スキルと商業的マインドセットが必要なことです。一部のCSMは「Sales」の側面に不快感を持っています。他の人は、商業的成果よりも採用と使用を優先します。
このモデルは、CSMにRenewalスキルのトレーニングに投資し、適切なサポートを提供する場合にうまく機能します。商業的なことを嫌うCSMを雇い、6桁のRenewalを成立させることを期待すると壊れます。
Salesパートナーシップ:商業的オーナーシップ
一部の企業では、SalesがRenewal収益を所有し、CSが関係を構築します。
CSは一年中価値を証明します。Renewal時期になると、SalesがConversationと交渉を所有します。CSは関与し続けますが、サポート役割です。
これは、取引が多いビジネスや、Renewalに大きな交渉が含まれる業界で一般的です。Salesは価格の専門知識と交渉スキルをもたらします。CSは信頼できるアドバイザーのポジションを維持します。
下降:顧客はハンドオフを経験し、緊密な調整が必要で、取引的に感じられる可能性があります。
価格交渉が期待され、顧客がRenewal時にSales会話を持つことを奇妙に感じない業界では、これが機能するのを見てきました。また、関係構築の1年後に顧客が「売り込まれている」と感じると、裏目に出るのも見てきました。
ハイブリッド:異なるアカウントに異なるアプローチ
ほとんどの企業は最終的にハイブリッドモデルに落ち着きます。
たとえば:CSMは5万ドル未満のRenewalを所有します。Salesは5万ドル以上のRenewalを所有します。Renewalスペシャリストは1万ドル未満の大量の小規模アカウントを処理します。規模に関係なく戦略的アカウントには経営陣が関与します。
重要なのは明確なルールです。Salesはいつ関与しますか?誰が顧客コミュニケーションをリードしますか?Renewal収益はどのようにクレジットされますか?意見の相違がある場合はどうなりますか?
顧客とチームメンバーは常に誰が何を所有しているかを知っているべきです。曖昧さは契約を殺し、内部摩擦を生み出します。
実際にスケールを可能にするテクノロジー
手動のRenewal追跡は、50〜100アカウント前後で機能しなくなります。その後、システムが必要です。
重要なすべてを追跡
CRMまたはCSプラットフォームは、すべての顧客のRenewal日付、各Renewalの現在のステータス、Renewal価値(現在と目標の両方)、ヘルスベースのリスク評価、すべてのRenewal活動、予測可能性を追跡する必要があります。
これは忙しい仕事ではありません。このデータはダッシュボードにフィードし、ワークフローをトリガーし、正確な予測を可能にします。それがなければ、盲目的に飛行しています。
リマインダーを自動化
Renewalタイムラインに基づいてトリガーキャンペーンを構築します。
90日で、割り当てられたCSMに社内でアラートしますが、まだ顧客に連絡しません。60日で、Renewal準備タスクを割り当て、フレンドリーな事前通知メールを送信します。30日で、社内で提案生成をトリガーし、価値サマリーを含む正式なRenewal通知を送信します。14日で、契約が後期段階でない場合は社内でエスカレートし、明確なアクションが必要な状態でフォローアップします。7日で、クローズされていない場合は管理者を関与させ、緊急性を持って最終リマインダーを送信します。
自動化により、何も漏れないことを保証します。しかし、人間のタッチを補強し、置き換えるべきではありません。最悪のRenewalプロセスは、100%手動(スケールしない)または100%自動(ロボット的に感じる)のいずれかです。
ヘルスモニタリングを統合
Renewalシステムは自動的にヘルススコアを引き出すべきです。製品使用トレンド、サポートチケットパターン、エンゲージメントメトリクス、NPSまたはCSATデータ、関係品質指標。
ヘルスが閾値を下回ると、Renewalステータスは自動的に「At-risk」としてフラグを立て、適切なワークフローをトリガーする必要があります。チームは、Renewalリスクを更新するためにヘルススコアを手動でチェックすべきではありません。システムがそれを行うべきです。
提案をより速く生成
標準的なRenewalの場合、提案作成を自動化します。使用と価値メトリクスのアカウントデータを引き出し、実際の数値で価値サマリーを生成し、価格オプション(Flat、複数年、Expansion)を作成し、プロフェッショナルにフォーマットし、迅速なカスタマイズを可能にします。
CSMは、15,000ドルのSMB Renewalの提案を10分で生成できるべきです。20万ドルのEnterprise契約の場合、テンプレートは構造を提供しますが、大幅なカスタマイズを期待します。いずれにせよ、毎回ゼロから始めるわけではありません。
契約管理統合
法務および契約システムと接続して、テンプレートからRenewal契約を自動生成し、必要な承認のためにルーティングし、電子署名を可能にし、署名ステータスを追跡し、実行済み契約を保存します。
目標:「同意しました」から「署名済み契約があります」を数時間または数日で、数週間ではなく。口頭合意と実行済み契約の間のギャップで契約が死ぬのを見てきました。管理上の摩擦でRenewalを殺させないでください。
役割別ダッシュボードを構築
異なる役割には異なるビューが必要です。
CSMには、次の90日間の今後のRenewal、Renewalパイプラインとステータス、At-riskアカウント、期限のRenewal活動が表示される必要があります。
マネージャーには、チームのRenewal予測、リスク分布、活動完了率、停滞または遅延したRenewal、勝敗分析が必要です。
経営陣には、全体的なRenewal率のトレンド、収益維持予測、セグメント別のAt-risk収益、主要な勝利と損失、目標に対するパフォーマンスが必要です。
可視性は説明責任を駆動します。全員が同じ数字を見ることができる場合、隠れる場所も言い訳もありません。
複数年契約:収益をロックイン(慎重に)
複数年のRenewalは収益をロックし、Churnリスクを減らします。しかし、すべての人に押し付けることはできません。
適切な候補者を選ぶ
複数年の良い候補者は、強力なヘルスと関係、安定したビジネスモデル、予算の予測可能性、価格割引への関心、またはロックインしたい戦略的重要性を持っています。
悪い候補者は、まだ価値を証明していない新規顧客、早期に交渉が必要になる可能性のあるAt-riskアカウント、条件をすぐに超えて成長する急成長アカウント、または変化率の高い業界です。
企業がすべてのRenewalで複数年契約を推進するのを見てきました。3年間コミットした顧客が2年目に製品を超えて成長し、閉じ込められたと感じるまでは素晴らしく聞こえました。彼らは4年目にRenewalしませんでした。
複数年契約は相互のコミットメントについてです。準備ができていない顧客や、条件が確実に変更される必要がある状況で押し付けないでください。
機能するインセンティブ構造
複数年のコミットメントに何を提供しますか?
一般的なアプローチ:2年間で10〜20%割引、3年間で15〜25%。または期間中の値上げなしで価格を固定します。またはより良いサポート層やより多くのCSMタッチなどの強化されたサービス。または新機能への早期アクセスなどの機能アクセス。または柔軟な支払い条件。
インセンティブは、予測可能性と削減されたChurnリスクから得られる価値を反映すべきです。複数年に30%割引し、その後、全額価格での年間Renewalを望むことに気づいた企業を見てきました。最初に計算してください。
複数年の価格アプローチ
固定価格で年ごとに同じ価格はシンプルで販売しやすいです。リスクは拡大収益をテーブルに残すことです。安定した予測可能なアカウントに最適です。
5〜10%の年間増加を伴うエスカレーション価格は、一部の成長を捉えますが、説明がより複雑です。成長するアカウントに最適です。
より低いベースプラス使用量超過を伴う拡大に優しい条件により、アカウントは価格に成長できます。最も柔軟です。明確な成長可能性を持つアカウントに最適です。
何を最適化しているかを考えてください。最大の予測可能性?最大の収益?最大の柔軟性?3つすべてを最適化することはできません。
柔軟性を組み込む
硬直しすぎる複数年契約は、将来問題を引き起こします。
座席数の年次トゥルーアップ、期間中に製品を追加する能力、買収や主要なビジネス変更などの特定の条件のためのオフランプ、主要な製品変更が発生した場合の再交渉トリガーを組み込みます。
目標は手錠なしのコミットメントです。条件が罠のように感じる場合、賢い顧客はそれらに署名しません。
RenewalでExpansionをバンドル
Renewal時期は、Expansionについて議論する自然な瞬間です。顧客はすでに製品と予算のコミットメントについて考えています。
タイミングが重要
Expansionを Renewalとバンドルするか、別々にしますか?
アカウントが健全で明確な拡大機会がある場合はバンドルします。全体を1つの交渉として実行し、バンドル価格を提供します。下降は、Renewal がExpansionの複雑さによって遅れる可能性があることです。
Renewalがリスクにあり、最初に確保する必要がある場合は分離します。またはExpansionに異なるステークホルダーが必要で、Renewalを複雑にしたくない場合。またはタイミングが悪く、Expansion予算がまだ準備ができていない場合。
最も頻繁には、明白な拡大機会を持つ健全なアカウントがバンドルされます。At-riskアカウントは分離します(Renewalを確保し、後でExpansionを追求)。探索的Expansionを持つアカウントは並行トラックを実行し、いずれかが独立してクローズできるようにします。
パッケージングオプション
顧客は選択肢が好きです。Good、Better、Bestを提供します。
Good:Flat Renewal、現在の条件、変更なし。
Better:Renewalプラス彼らの成長に対応する適度なExpansion。
Best:Renewalプラス完全なExpansionプラス複数年のコミットメント。
多くの顧客は「Good」で来る計画でも「Better」を選びます。中間のオプションは多くの場合、賢い選択のように見えます。
価値ベースのバンドリングも可能です。「あなたのチームは今年30%成長しています。その成長を25%の支出増加でサポートするRenewalプラスExpansionがあります。」
これはExpansionを、あなたの収益目標のためのUpsellではなく、彼らのニーズへの戦略的対応としてフレーム化します。
別々に保つ時期
Renewalがリスクにある場合(最初に確保)、Expansionに異なるステークホルダーが必要な場合(Renewalを複雑にしない)、タイミングが悪い場合(Expansion予算が準備されていない)、またはExpansionが探索的な場合(顧客がまだ確信していない)はバンドルしないでください。
Renewalをクローズし、次の四半期にExpansionを追求する方が、バンドルしようとしてRenewalを遅らせたり失ったりするよりも良いです。この間違いが企業に6桁を費やさせるのを見てきました。
マルチスレッドコミュニケーション
Renewalには複数の人々が関与します。コミュニケーション戦略はすべての人に到達する必要があります。
ステークホルダーをマップ
Renewalに誰が関与する必要がありますか?
ユーザーは日常の使いやすさを気にします。チャンピオンは成功したツールをスポンサーすることで社内で良く見られることを気にします。経済的購入者はROIと予算への影響を気にします。意思決定者は戦略的整合性を気にします。技術的購入者は統合、セキュリティ、リスクを気にします。法務と調達は契約条件とコンプライアンスを気にします。
各人は完全に異なることを気にします。Renewalコミュニケーションはすべての視点に対処する必要があります。
シングルスレッドにしない
CSMが1人のチャンピオンとしか話さず、そのチャンピオンが会社を離れ、突然社内で誰もあなたの製品を購入した理由を知らないため、Renewalが死ぬのを何回見たか数えきれません。
並行コミュニケーションを実行します。CSMはチャンピオンとユーザーと話します。あなたの経営陣は彼らの経営陣と話します。技術チームは技術的購入者と話します。Salesまたは CSリーダーは経済的購入者と話します。
これにより、1つの関係が弱いか、1人が去っても、メッセージが確実に伝わります。チャンピオンが辞めたときに複数のスレッドがあったため、Renewalを救った企業を見てきました。
タイムラインを共有
顧客は何を期待するかを知ることを評価します。
「私たちにとってRenewalが通常どのように機能するかを説明します。60日前に一緒に価値をレビューします。45日前に正式な提案を受け取ります。30日前に承認プロセスを通過できるように合意したいと思います。Renewal日に、契約に署名する必要があります。」
これは期待を設定し、勢いを維持しやすくします。顧客は何が来るか、いつかを知っているので、それに応じて計画できます。
価値を継続的なドラムビートにする
価値について議論するためにRenewalまで待たないでください。それを継続的にします。
Quarterly Business Reviewは価値を強調します。月次メールは勝利と成果を共有します。サポートのやり取りは影響を参照します。製品更新は顧客のメリットに結びつけられます。
Renewal時期が来ると、価値はすでに豊富に明確です。あなたは思い出させており、初めて説得しているのではありません。
すべてのRenewalから学ぶ
Renewal戦略は、学んだことに基づいて進化すべきです。
勝敗を分析
クローズされたすべてのRenewal、勝利または敗北について、何が起こったかを捉えます。
勝利の場合:何がこれを成功させましたか?顧客は何を価値として引用しましたか?何がより良くなる可能性がありましたか?見逃したExpansion機会はありますか?
損失の場合:Churnの真の理由は何でしたか?顧客に言われたときではなく、実際にこのアカウントをいつ失いましたか?救えましたか?どうやって?これはどのパターンに適合しますか?
複数のRenewalにわたるテーマを探し、個々のケースだけでなく。競合他社への1つの損失はデータです。同じ競合他社への5つの損失はパターンです。
プロセスを四半期ごとに洗練
毎四半期、Renewalプロセスをレビューします。タイムラインで何が機能していますか?Renewalが一貫して停滞する場所はどこですか?どのような自動化が役立ちますか?どこでより多くまたは少ない人間のタッチが必要ですか?リスク評価はどれくらい正確ですか?
腹の感覚ではなく、データに基づいて段階的な改善を行います。1つの悪い四半期に基づいてRenewalプロセスを完全に再設計するチームを見てきました。それをしないでください。持続的なパターンを探してください。
チームスキルに投資
Renewalは練習とともに向上するスキルです。
優れたRenewal会話の録音を共有します。一般的な反論をロールプレイします。交渉の基礎をトレーニングします。価値の明確化を教えます。提案開発を練習します。
チームがRenewalに上達するほど、率は上昇します。これは静的な知識ではありません。練習されたスキルです。
Playbookを構築
効果的なメールテンプレート、実証済みのトークトラック、反論処理戦略、成功した提案フォーマット、Expansion バンドリングアプローチをキャプチャするRenewal Playbookを作成します。
チームメンバーがお互いの成功から学ぶことを簡単にします。最高のCSMは、秘密を抱え込むのではなく、チームの残りの部分を教えるべきです。
これを実行に移す
戦略は実行なしでは何も意味しません。
月1、現在のRenewalアプローチを監査します。今どのようにセグメント化していますか?セグメント別のプロセスは何ですか?誰が何を所有していますか?自動化対手動は何ですか?
月2、理想的なフレームワークを設計します。セグメントと基準を定義します。セグメントにプロセスをマップします。オーナーシップモデルを明確にします。自動化の機会を特定します。
月3、1つのセグメントでパイロットします。Enterpriseではなく、Mid-marketまたはSMBから始めます。ワークフローを構築してテストします。新しいプロセスについてチームをトレーニングします。ベースラインに対する結果を測定します。
月4〜6、すべてのセグメントに拡大します。体系的にロールアウトします。パイロットの学習に基づいて洗練します。サポート資料を構築します。完全なチームをトレーニングします。
継続的、継続的に最適化します。月次パフォーマンスレビュー。四半期プロセス更新。年次戦略リフレッシュ。
Renewal戦略フレームワークは一晩で構築されません。しかし、すべての改善は時間とともに複利します。どこかから始めて、それをより良くし続けてください。
関連リソース

Tara Minh
Operation Enthusiast
On this page
- Renewal戦略を実際に機能させるもの
- セグメンテーション:すべてのRenewalを同じように扱うのをやめる
- 契約額でセグメント化
- ヘルススコアがすべてを変える
- 機会タイプがモーションを決定
- タッチモデルを現実に合わせる
- セグメントに一致するプロセスの構築
- Enterpriseプロセス:時間をかける
- Mid-marketプロセス:より速く動く
- SMBプロセス:可能な限りすべてを自動化
- Renewalを所有する(そして決定方法)
- Renewalスペシャリスト:専門化が意味を成すとき
- CSMオーナーシップ:デフォルトモデル
- Salesパートナーシップ:商業的オーナーシップ
- ハイブリッド:異なるアカウントに異なるアプローチ
- 実際にスケールを可能にするテクノロジー
- 重要なすべてを追跡
- リマインダーを自動化
- ヘルスモニタリングを統合
- 提案をより速く生成
- 契約管理統合
- 役割別ダッシュボードを構築
- 複数年契約:収益をロックイン(慎重に)
- 適切な候補者を選ぶ
- 機能するインセンティブ構造
- 複数年の価格アプローチ
- 柔軟性を組み込む
- RenewalでExpansionをバンドル
- タイミングが重要
- パッケージングオプション
- 別々に保つ時期
- マルチスレッドコミュニケーション
- ステークホルダーをマップ
- シングルスレッドにしない
- タイムラインを共有
- 価値を継続的なドラムビートにする
- すべてのRenewalから学ぶ
- 勝敗を分析
- プロセスを四半期ごとに洗練
- チームスキルに投資
- Playbookを構築
- これを実行に移す
- 関連リソース