更新プロセスの設計と実践｜目標設定から施策立案までの具体的プロセス

更新の連絡を、更新月に入ってから慌てて顧客に入れていないでしょうか。あるいは、担当者ごとに更新の進め方がばらつき、四半期の解約が読めないという状態かもしれません。契約更新（リニューアル）を担当者の勘に頼っている限り、成果は安定しません。

この記事では、更新を勘に頼らず、目標設定から日々の施策立案・運用まで再現できるプロセスに落とす手順を、実務の粒度で解説します。更新プロセスの設計とは、更新期日から逆算した時間軸に、目標・指標・施策・役割を割り付け、誰がやっても一定の質で更新を回せる状態にすることです。更新月に更新意思を確認する単発の作業ではなく、契約直後から更新までの期間全体を運用の対象にする、という考え方が出発点になります。

更新・アップセル・クロスセルを含む既存収益拡大の体系的な全体像は既存顧客からのLTV最大化で整理しています。本記事は、そのうち更新（リニューアル）プロセスの設計と実践に絞って掘り下げます。

更新プロセスを設計する意義

更新を「更新月に更新意思を確認する単発の作業」と捉えると、解約は直前まで見えず、気づいたときには打つ手がほとんど残っていません。更新プロセスの設計とは、更新の成否が決まる期間全体、つまり契約直後から更新前までを運用の対象にすることです。

この期間に価値を実感してもらい、利用を定着させ、投資対効果を示せていれば、更新月の意思確認は「確認」で済みます。逆にここが空白だと、更新月の交渉ですべてを挽回しようとして失敗します。以下では、更新プロセスの用語の定義と、更新が拡大提案の土台になる理由を整理します。

更新（リニューアル）とリニューアルマネジメントの定義

更新（リニューアル）とは、契約期間の満了時に顧客が契約を継続することです。リニューアルマネジメントとは、その更新を確実にするための計画的な一連の活動を指します。単発の更新連絡や条件交渉だけを指すのではなく、契約直後の価値提供から更新意思の確認までを含む、時間軸を持った運用の総称です。

本記事で「更新プロセス」と呼ぶのは、このリニューアルマネジメントを再現性のある手順に落とし込んだものです。属人的な進め方を、目標・指標・施策・役割で構造化した状態を指します。

更新が拡大提案の土台になる理由

更新（継続）が不安定なまま、アップセルやクロスセルといった拡大提案を押すと、かえって解約を招きます。まだ価値を実感していない顧客に追加費用の話を持ちかければ、「今の契約すら見直すべきか」という検討を誘発するためです。拡大提案は、更新が安定して見込める顧客に対してこそ機能します。

つまり、更新プロセスの安定は既存収益拡大の前提条件です。アップセル・クロスセルの具体的な進め方は、アップセルの進め方とクロスセルの進め方で扱います。本記事では、その土台となる更新プロセスの設計に集中します。

更新プロセスの目標設定

更新プロセスは、目標指標を決めてから設計します。追う指標が曖昧なままだと、施策の優先順位も役割分担も決められません。更新プロセスの中核となる指標は、更新率とグロスリテンション（解約による減少のみを見る継続率）です。

拡大を含むNRR（Net Revenue Retention：既存顧客の売上維持・拡大率）とは性質が異なるため、分けて管理します。さらに、全顧客を一律に扱うのではなく、タッチモデル別に目標と工数配分を変えるのが実務的です。以下で、それぞれの見方と切り分け方を整理します。

更新率とグロスリテンションの見方

更新率は、更新の対象となった契約のうち、実際に更新された割合です。件数ベースで見る場合と、金額ベースで見る場合があります。グロスリテンションは、期首の既存収益に対して、期末に維持できた収益の割合を示す指標で、アップセルなどの増加分は含めず、解約とダウングレードによる減少のみを反映します。つまり、既存顧客からの収益がどれだけ「目減りしなかったか」を見る指標です。

健全性の目安は事業モデルや顧客層によって大きく異なるため、単一の数値で「この水準が正常」と断定はできません。契約単価が高く顧客数が少ない事業と、低単価で顧客数が多い事業では、1件の解約が指標に与える影響も、目指すべき水準も変わります。自社の過去実績とセグメントごとの傾向を基準に目標を置くのが現実的です。

NRRとの切り分け

更新プロセスの目標設定でつまずきやすいのが、更新（維持）とエクスパンション（拡大）を1つの指標に混ぜてしまうことです。NRRはアップセル・クロスセルによる増収を含むため、値が高くても、実は解約が進んでいるのを拡大分で覆い隠しているケースがあります。

そのため、更新プロセスの一次指標はグロスリテンションと更新率に置き、拡大はNRRで別建てにします。こうすると、更新（守り）が崩れているのか、拡大（攻め）が伸びていないのかを切り分けて判断できます。エクスパンション全体の考え方はエクスパンションで扱うため、本記事では「更新の一次指標に拡大分を混ぜない」という切り分けの判断に絞ります。

セグメント別の目標設定

更新目標を全顧客一律で置くと、工数配分がゆがみます。契約規模や解約時のインパクトに応じて、タッチモデル別に目標と関わり方を変えます。ハイタッチは、担当者が個別に密に関与する高単価・重要顧客向けの体制です。ロータッチは、一部を自動化しつつ節目で個別対応する中間層向け、テックタッチはメールやプロダクト内メッセージなど自動化中心で多数の小規模顧客に対応する体制を指します。

ハイタッチ顧客には更新前フォローを手厚く配置し、テックタッチ顧客には利用状況に応じた自動的な働きかけを設計する、といった具合に、同じ更新率目標でもかける工数と手段を変えます。この配分を最初に決めておかないと、少数のハイタッチ顧客に工数を吸われ、多数のテックタッチ顧客の解約を取りこぼします。

更新期日から逆算するスケジュール設計

更新の成否は更新月ではなく、その手前の数か月で決まります。だからこそ、更新期日を起点にして、いつ・何をやるかを逆算し、時間軸に割り付けるのが設計の骨格になります。

契約直後のオンボーディングから活用定着、更新前フォロー、更新意思確認までを、更新月から逆算した各時点に施策として配置します。ここを固めると、更新前の動きが担当者の記憶や勘に依存しなくなります。以下、各期にやることを時間軸に沿って整理します。

契約直後〜オンボーディング期にやること

更新プロセスの起点は、契約直後のオンボーディング（導入初期の立ち上げ支援）です。ここでやることは2つあります。導入目的を顧客と明確に合意することと、初期の価値を早く実感してもらうことです。「何のために導入したのか」が担当者間で曖昧なままだと、更新前に成果を語る基準がなくなります。

この期間で躓くと、その後の挽回は難しくなります。初期定着が遅れた顧客は利用が伸びず、更新前フォローの段階で「使っていないのに更新する理由」を問われることになるためです。オンボーディング期の成否が、更新プロセス全体の難易度を左右します。

活用定着期にやること

オンボーディングを終えたら、利用状況を可視化し、定期的な振り返りを行う活用定着期に入ります。ここでは、実際にどの機能がどれだけ使われているかを把握し、契約直後に合意した導入目的に対する進捗を確認します。

利用が想定どおり伸びているかを定点観測することで、更新前になって初めて問題に気づく事態を避けられます。利用が停滞していれば、この段階で原因を特定し、追加のオンボーディングや使い方の提案で軌道修正します。活用定着期は、後述する解約予兆の検知が最も効くフェーズでもあります。

更新前フォロー期にやること

更新月の手前、多くの事業では数か月前から始めるのが更新前フォロー期です。この期間には、導入で何が改善したかというROI（投資対効果）の確認と顧客への伝達、顧客社内の推進体制の再確認、更新の決裁ラインの把握、VoC（Voice of Customer：顧客の声）の収集、そして更新意思の確認と、やることが重なります。

これらを更新月にまとめて行おうとすると、時間が足りずに更新意思の確認だけで終わります。逆算スケジュールの考え方は、これらを更新月から手前に配置し、決裁者が誰かを把握したうえで、その決裁者に響くROIを揃えた状態で更新月を迎えることにあります。決裁ラインの把握が遅れると、更新直前に「稟議に必要な資料が足りない」と判明し、更新が後ろ倒しになったり失注したりします。

ROIを提示して更新を後押しする

更新前フォローの中核が、ROIの提示です。更新の意思決定者は、多くの場合「継続してどんな価値があるか」を数値で説明できる材料を求めています。ここを感覚的な満足度だけで進めると、コスト見直しの局面で切られやすくなります。

ROI提示は、進捗確認から数値化、提示の順で組み立てます。まず活用定着期に確認した利用状況と成果を集め、次にそれを導入目的に対する改善として数値に変換し、最後に決裁者に伝わる形で提示します。たとえば、対応時間の短縮や案件の可視化による受注率の変化など、顧客が導入時に期待した指標に紐づけて示すと、更新の説得力が増します。抽象的な「ご満足いただけていますか」ではなく、「導入前後でこの指標がこう変わった」という具体で語ることが、更新を後押しします。

解約予兆を検知する仕組み

更新プロセスを回す要は、解約の予兆を更新月より前に検知することです。更新月に「解約します」と言われてからでは、打てる手はほとんど残っていません。予兆検知の中心になるのがヘルススコア（顧客の健全度を利用状況などの複数指標で数値化した指標）です。

利用状況・接触頻度・サポート状況などの変化を継続的に監視し、悪化の兆しを早期に捉えます。ただし、スコアだけに頼るのは危険で、担当者が捉えた定性的なシグナルと組み合わせて運用します。以下で、設計・アクション・勘との併用を整理します。

ヘルススコアの設計と運用

ヘルススコアは、顧客の健全度に影響する複数の指標を組み合わせて数値化します。構成要素として使われるのは、利用頻度、契約した主要機能の定着度、問い合わせの傾向、接触の頻度などです。単一の指標では見誤るため、複数を重み付けして総合的な健全度として表します。

運用では、スコアにしきい値を設けて定期的に確認するフローを作ります。「このスコアを下回ったら要注意」という基準を決め、週次や月次でスコアの変化を確認する運用に乗せてはじめて、予兆検知は機能します。スコアを算出するだけで確認頻度が決まっていなければ、数字は溜まる一方で更新には効きません。

予兆を検知したあとのアクション

ヘルススコアの低下を検知しても、その後のアクションが決まっていなければ意味がありません。スコアが下がったら誰が・いつ・何をするかを、事前に決めておきます。たとえば、しきい値を下回った顧客はCS担当がその週のうちに状況をヒアリングし、原因に応じて再オンボーディングや利用提案を行う、といった対応を標準化します。

ここを場当たり的な対処療法で終わらせると、同じ予兆に対して担当者ごとに反応がばらつき、更新率が安定しません。予兆の検知と対応アクションは、必ずセットで設計します。

勘とデータの両方を使う

ヘルススコアは強力ですが、スコアだけに頼るのも失敗のもとです。数値には表れにくい定性的なシグナルを、担当者が拾う必要があります。決裁者の交代、利用部門の縮小や組織改編、キーパーソンの退職といった変化は、利用状況の悪化として数字に出る前に、更新に直結するリスクになります。

逆に、データを軽視して担当者の感覚だけで進めるのも危険です。「あの顧客は大丈夫」という主観的な安心が、解約予兆の見落としにつながります。ヘルススコアで全体を漏れなく監視しつつ、担当者が把握した定性シグナルをスコアの補正材料として扱う。この両輪で、機械的な検知と現場感覚の両方を活かします。

更新を確実にする施策の立案

予兆を検知したら、次は更新を後押しする施策を計画的に打ちます。単発のフォロー連絡ではなく、更新前の各局面に対応した施策のセットを用意しておくのが、再現性のある更新プロセスの条件です。

価値を再認識してもらう施策、不安や障害を取り除く施策、そして更新意思の確認と交渉。この3つの局面ごとに、あらかじめ打ち手を決めておきます。以下で、それぞれの施策を具体化します。

価値の再認識を促す施策

更新を後押しする第一の施策群は、顧客に価値を再認識してもらうことです。活用定着期に蓄積した利用状況をもとに、成果の振り返りを行います。導入目的に対してどこまで到達したか、どの指標が改善したかを顧客と一緒に確認する場を設けます。

同業種や近い規模の顧客の成功事例を共有することも、価値の再認識に効きます。「他社はこう活用して成果を出している」という具体は、まだ使い切れていない顧客に次の一手を示します。ここで新しい活用方法を提案することはありますが、追加契約を伴う拡大提案そのものは更新の安定を確認してから行い、詳細は兄弟クラスターの各記事に委ねます。

不安・障害を取り除く施策

第二の施策群は、更新の障害になっている不安や躓きを取り除くことです。オンボーディング後に発生した使い方の躓き、機能への不満、顧客社内の体制変更への追随などが対象です。放置された不満は、更新月に「使いこなせなかった」という解約理由に転化します。

顧客社内で推進していたキーパーソンが異動・退職している場合は、後任への引き継ぎ支援や、あらためての価値説明が必要になります。決裁ラインが変わっていれば、新しい決裁者に向けたROIの説明を準備します。障害を1つずつ潰しておくことで、更新意思の確認をスムーズな「確認」にできます。

更新意思の確認と交渉

第三に、更新意思の確認と条件交渉です。ここで重要なのは、更新月の直前ではなく前倒しで意思確認を行うことです。早めに意思を確認すれば、条件面で折り合わない場合の交渉の余地が残ります。更新月ギリギリでは、交渉する時間がなく、そのまま解約に流れます。

更新前のやりとりや資料が担当者のメールや個人のフォルダに散在すると、顧客の検討状況が見えにくくなります。たとえばMazrica DSRのようなデジタルセールスルーム（営業と顧客が同じ空間で情報を共有する共通の作業場）では、更新前のやりとりや資料を1つのポータルに集約し、顧客の検討状況を可視化できます。Mazrica DSRは他社のSFA/CRMや単独でも利用できるため、既存の運用に合わせて導入できます。こうした仕組みで検討状況を見えるようにしておくと、更新前フォローの打ち手を判断しやすくなります。

更新プロセスを回す役割分担とデータ基盤

更新プロセスを担当者の勘に任せると、成果は担当者の力量に比例してばらつきます。これを解消する鍵は、属人化の解消を「顧客データの一元化」と「プロセスの標準化」の両輪で進めることです。

データを集めるだけでも、手順を決めるだけでも回りません。両方がそろってはじめて、誰がやっても一定の質で更新を回せます。さらに、CSと営業の役割分担と情報連携のシグナルを設計することで、更新と拡大の連携が機能します。以下で、役割分担・データ一元化・プロセス標準化を整理します。

CSと営業の役割分担

更新はCSが主導し、拡大提案は営業と連携する、という分担が基本形です。CSは日々の活用支援とヘルススコアの監視を通じて顧客の状態を最もよく把握しているため、更新の主担当に適しています。追加契約を伴う拡大提案は、金額交渉や契約手続きに慣れた営業が関わることで、更新の関係を崩さずに進めやすくなります。

重要なのは、両者の間で情報を渡すシグナルを設計することです。ヘルススコアが良好で拡大の好機が見えたらCSから営業へ、更新にリスクが出たら営業から手を引いてCSがフォローに集中する、といった引き継ぎのトリガーを決めておきます。この連携がないと、CSが守ろうとしている顧客に営業が拡大提案を持ち込んで解約を招く、という事故が起きます。

データの一元化

役割分担を機能させる前提が、データの一元化です。更新期日、利用状況、接触履歴、ヘルススコアといった更新プロセスに必要な情報が、担当者の頭の中や個人の表計算ファイルに散在していると、引き継ぎのたびに情報が抜け落ちます。

これらを1か所に集約し、CSも営業も同じ情報を見られる状態にします。更新期日が一覧で見えれば逆算スケジュールが引けますし、ヘルススコアと接触履歴が紐づいていれば予兆検知から対応までが途切れません。散在した情報を集めることが、更新プロセスの標準化の土台になります。

プロセスの標準化

データを集めるだけでは、活用の仕方が担当者依存のままです。もう一方の軸が、プロセスの標準化です。更新期日からの逆算スケジュール、予兆検知後の対応手順、ROI提示の型を、手順書やプレイブック（想定シナリオごとの標準対応をまとめたもの）として整備します。

標準化されていれば、新しい担当者でも同じ流れで更新を回せますし、うまくいった進め方を組織の資産として横展開できます。属人化の解消というと情報を集める話に偏りがちですが、集めた情報をどう使うかの手順がそろっていなければ、成果のばらつきは消えません。データの一元化とプロセスの標準化は、どちらか一方では不十分です。

更新プロセスでつまずくパターンと回避策

更新プロセスは、取り組めば自然に伸びるものではありません。順序や運用設計の誤りで失敗します。ここでは、上位の解説記事が手薄な論点として、代表的なつまずきと回避策を具体的に扱います。

拡大提案の押し込み、指標を出すだけで運用に乗せない状態、更新前フォローの属人化。これらは実務で頻発します。最後に、自社の更新プロセスを診断するチェックリストを示します。

更新が不安定なまま拡大提案を押す

最もよくある失敗が、更新の安定を確認する前に、アップセルやクロスセルを押すことです。まだ価値を実感していない顧客に追加費用の話を持ちかけると、契約全体の見直しを促し、解約に転じます。目先の拡大目標を追うほど、この罠にはまりやすくなります。

回避策は順序を守ることです。ヘルススコアと更新の見込みが安定している顧客に限って拡大提案を行い、リスクのある顧客には更新の安定を優先します。更新の土台が固まってから拡大に進む、という順序を役割分担のシグナルに組み込んでおくと、個々の判断に頼らずに済みます。

指標を算出して満足し運用に乗せない

ヘルススコアやNRRを算出したこと自体に満足し、そこから先のアクション設計につながっていないパターンです。ダッシュボードに数字は並ぶものの、その数字を見て誰が何をするかが決まっていないため、更新率は変わりません。

回避策は、指標のしきい値と対応アクションを必ずセットにすることです。「スコアがこの値を下回ったら、CS担当が3営業日以内にヒアリングする」というところまで決めて初めて、指標は更新プロセスの一部になります。指標は測るためではなく、動くために出すものです。

更新前フォローが担当者任せで標準化されていない

更新前フォローの進め方が担当者ごとに異なり、人によって更新の質が変わるパターンです。ベテランは早めに決裁ラインを押さえてROIを揃えるのに、経験の浅い担当者は更新月に慌てて連絡する、という差が更新率のばらつきになります。

回避策は、逆算スケジュールとプレイブックで標準化することです。更新の何か月前に何をやるかを共通の手順に落とし、想定シナリオごとの対応をプレイブックにまとめます。担当者の経験差を、仕組みで埋めます。

更新プロセスの点検チェックリスト

自社の更新プロセスがどこまで整っているかを、その場で診断できるチェックリストを示します。以下の項目を確認してください。

• 更新期日データの整備：全顧客の更新期日が1か所に集約され、逆算スケジュールを引ける状態になっているか
• ヘルススコアの運用：ヘルススコアを算出するだけでなく、しきい値と確認頻度が決まっているか
• 更新前フォローの標準化：更新の何か月前に何をやるかが共通の手順になっているか、担当者任せになっていないか
• ROI提示の仕組み：導入目的に対する成果を数値化して顧客に提示する型があるか
• CS・営業の連携シグナル：更新リスクや拡大の好機を、いつ・誰が・誰に渡すかが決まっているか

これらのうち整っていない項目が、次に着手すべき優先領域です。全部を一度に整えようとせず、更新率に最も効く1つから手をつけます。

更新プロセスを支えるツール基盤

更新プロセスの標準化は、更新期日・利用状況・ヘルススコアを一元管理し、可視化できるツール基盤があってはじめて回ります。散在した情報を手作業で集める前提では、逆算スケジュールも予兆検知も維持できません。

中核になるのがSFA/CRMです。まず一般的な役割を整理したうえで、製品を一例として紹介します。以下で、SFA/CRMが更新プロセスで担う役割と、具体的な製品の例を見ます。

SFA/CRMが更新プロセスで担う役割

SFA（Sales Force Automation：営業支援システム）は営業プロセスを前に進める仕組み、CRM（Customer Relationship Management：顧客関係管理）は顧客との良好な関係を長期に築く仕組みです。どちらも単なるシステムであると同時に、営業・顧客対応の考え方でもあります。特にCRMは、顧客を軸に情報と活動を統合するという運用思想を含みます。

実務では、この両者を1つのツールで統合して扱う形が一般的です。更新プロセスの文脈では、顧客情報・案件・活動履歴を一元管理し、更新期日を管理し、活動を標準化する用途で使います。顧客ごとの利用状況や接触履歴が1か所にそろえば、更新期日からの逆算も、ヘルススコアと連動した予兆検知も、同じ基盤の上で回せます。

なお、表計算ソフトでも更新期日の管理自体はできますが、担当者ごとにファイルが分かれると更新が属人化しやすく、情報の一元化と活動の標準化を両立させにくくなります。更新プロセスを組織で回す規模になると、専用のツール基盤が現実的です。

製品の一例

具体的な製品でイメージすると分かりやすくなります。たとえばMazrica SalesのようなSFA/CRMでは、取引先を起点に案件・コンタクト（担当者）・アクション（営業活動の履歴）を一元管理し、蓄積したデータからAIが次のアクションを示唆できます。更新期日や利用状況、接触履歴を同じ基盤に集約すれば、逆算スケジュールを引く土台になります。

案件の進捗やリスクを可視化するAIインサイトや、更新率などの指標を組み合わせて表示するカスタムレポート・ダッシュボード、営業メンバーの強み・弱みを比較するセールスメトリクスといった分析機能は、いずれもGrowth以上のプランで利用できます。こうした機能を使うと、更新プロセスの指標を運用に乗せやすくなります。他のSFA/CRMでも同種の機能が備わっている場合があるため、自社の更新プロセスに必要な機能を軸に比較して選ぶとよいでしょう。

まとめ｜自社の更新プロセスの整備順を決める

更新プロセスの設計とは、更新期日から逆算した時間軸に、目標・指標・施策・役割を割り付け、誰がやっても一定の質で更新を回せる状態にすることです。何から着手するかは、自社の現状で変わります。

更新率がそもそも読めていない組織は、まず更新期日データの一元化と可視化から始めます。解約が更新直前に発覚してしまう組織は、ヘルススコアによる予兆検知の運用から着手します。更新は取れているが担当者依存で質がばらつく組織は、逆算スケジュールとプレイブックの標準化から手をつけます。この3つを一度に整えようとせず、自社のボトルネックに当たる1つを選びます。

最初の一歩は小さくして構いません。直近の更新予定顧客のリストと更新期日を1か所に書き出すところから始めれば、逆算スケジュールを引く土台ができます。そこにヘルススコアや接触履歴を足していけば、更新プロセスは徐々に仕組みに変わっていきます。

更新を安定させたら、アップセル・クロスセルを含む拡大へ広げます。既存収益拡大の全体像は既存顧客からのLTV最大化を参照してください。拡大の各論は、アップセルの進め方・クロスセルの進め方・エクスパンションで扱います。

よくある質問

Q 更新率とグロスリテンション、NRRの違いは何ですか。

A

更新率は、更新対象の契約のうち実際に更新された割合を示します。グロスリテンションは、期首の既存収益に対して期末に維持できた収益の割合で、アップセルなどの増加分を含めず、解約とダウングレードによる減少のみを反映します。NRRは、これに拡大分（アップセル・クロスセル）を加えた、既存顧客からの売上維持・拡大率です。更新プロセスの一次指標はグロスリテンションと更新率に置き、拡大はNRRで別建てにすると、守りと攻めを切り分けて判断できます。

Q 更新プロセスの目標は、更新月の何か月前から動き始めるべきですか。

A

更新月から動き始めるのでは遅く、契約直後から運用対象と考えます。目標設定とオンボーディングは契約直後、活用定着期の振り返りは契約期間の中盤、更新前フォローは更新月の数か月前が目安です。具体的な月数は契約期間や決裁の複雑さによって変わりますが、決裁ラインの把握とROIの準備に必要な時間から逆算して、更新月に「確認」だけで済むよう手前に配置します。

Q ヘルススコアは何の指標で作ればよいですか。

A

利用頻度、契約した主要機能の定着度、問い合わせや接触の傾向など、顧客の健全度に影響する複数の指標を組み合わせます。単一の指標では見誤るため、複数を重み付けして総合的な健全度として表します。加えて、決裁者の交代や利用部門の縮小といった、数値に出にくい定性シグナルも予兆として併用します。どの指標が解約と相関するかは事業によって異なるため、自社の過去の解約事例を振り返って構成要素を見直すのが実務的です。

Q カスタマーサクセスと営業（更新担当）はどう役割分担すべきですか。

A

更新はCSが主導し、追加契約を伴う拡大提案は営業と連携する分担が基本です。CSは日々の活用支援とヘルススコアの監視で顧客の状態を最もよく把握しているため、更新の主担当に向いています。重要なのは、両者の間で情報を渡すシグナルを設計することです。拡大の好機が見えたらCSから営業へ、更新にリスクが出たら営業が手を引いてCSがフォローに集中する、という引き継ぎのトリガーを決めておきます。

Q 更新前にアップセルを提案してもよいですか。

A

更新の安定が見込める顧客に限り、有効です。ヘルススコアが良好で価値を実感している顧客であれば、更新と合わせた拡大提案が自然に進みます。まだ価値を実感していない顧客に拡大提案を押すと、契約全体の見直しを促し解約を招きます。判断の基準はヘルススコアと更新見込みの安定です。具体的な進め方は[アップセルの進め方](/renewal-upsell-crosssell-upsell/)を参照してください。

Q 更新プロセスの改善効果はどのくらいで出ますか。

A

効果が出るまでの期間は、契約期間・顧客数・現状の整備度によって変わるため、一律の数値では示せません。契約期間が1年の事業であれば、更新期日データの整備やヘルススコアの運用を始めても、更新率という結果指標に表れるのは次の更新サイクル以降になります。予兆検知の運用に乗せれば、リスク顧客への早期対応という中間的な変化はより早く現れます。結果指標だけでなく、逆算スケジュールの実行率や予兆検知後の対応率といった過程の指標で、改善の進み具合を追うのが現実的です。