BtoB SaaS が解約 / チャーンされないための仕組み作り

今回は BtoB SaaS が受注後クライアントから解約されず、チャーンレート（解約率）を 0% にするためにできる現実的な方法について紹介していきます。

前提

• BtoB すなわち法人向けに提供する SaaS を前提とします。BtoC や BtoB でも小規模なクライアントが多数いる、例えば Figma のような形態は対象外です。

• いわゆる CS / CX 担当者がいて、個々のクライアントからすると直接連絡ができる担当が存在して見える状況を想定します。

• マーケットには複数のコンペが存在している状況を想定します。例えば 2023 年時点での ChatGPT のような、代替可能な製品が存在しない「マーケットに強いやつオラしかいねえ」状態の場合そもそも解約防止といったマインドは必要ないかもしれないので。

• プロダクト（システムそのもの）はある程度の水準であることを想定します。

Step1：状況を常に把握する

当たり前ではありますが、クライアントの状況をなるべく把握しておくことはとても重要です。クライアント社内では誰が何をしてどんなことを考えていて、それがリプレイスに対してどのような影響を与えるかを知ることは後続の対応策のために必要になってきます。

把握しておく事項について、以下のような点が挙げられます。

• プロダクトの利用状況。過去と比較して変動が無いか。

• プロダクトに対する評価、課題点、期待感、要望。

• またそれが担当者毎にどう異なるか。特にキーマンや決裁者の考え。

• クライアント社内のビジネス状況。イベント毎などの繁忙期、取り組みなど。

• クライアント社内の異動情報

• コンペの営業状況

この中で特にクライアント社内の異動情報は重要です。例えば 4 月の異動の時期に新しい担当が赴任し、その方がある程度ガツガツしていて「新しいやり方で成果を上げたい」と考えるような場合、もともと採用されていた SaaS プロダクトなんかはその変更の対象になりやすく注意が必要です。
そのため異動の噂はなるべくこちらも把握しておき、元の担当者から新しい担当者へしっかりと我々（SaaS ベンダー）も引き継いでもらう、できればそのための MTG を設定してもらえると良いです。

ではどうやって状況を把握するかで言うと、以下に挙げるような仕組み化をしておくと良いでしょう。

• 頻繁に連絡をする。新機能のリリースのお知らせ、プレスリリースのお知らせ、事例紹介のメルマガ .. など、なにかにつけて情報提供をすると良いでしょう。

• 定例の場を設ける。例えば月一回の報告会を設けて、前月分の利用状況をレポートしつつ課題が無いかをヒアリングするなど。

Step2：不満や課題を解消する

Step1 が仕組み化できていれば、クライアントからどのような評価を受けているか、不満や課題が無いかを把握することができます。
それらを解消するアプローチはいくつかあり、大きくは「システムの改修を伴うもの」「システムの改修を伴わないもの」に分かれます。
プロダクトの成熟度合いやクライアントの数や当該クライアントの規模にもよりますが、基本的にシステムの改修は社内エンジニア部門を巻き込んだコストのかかるものであるため、よほどでない限り単一のクライアントの課題解決を直接的な目的とした機能改修は難しいのではないかと考えます。

そのためなるべく「システムの改修を伴わないもの」での解決を図ることを念頭に置くと、以下のような打ち手が考えられます。

• 本質的な困り事を深堀り、解決策を提示する。例えば Shopify のような EC サイトを構築する SaaS を仮定して、クライアントが「商品の検索機能をもっとリッチにして」と言ってきたとします。このような場合は具体的に何を求めているかではなく、何に困っているのかを深掘ります。もしかするとそれは「閲覧履歴の商品機能の利用」や「在庫の無い商品を非表示にする機能の利用」などすでにある機能で解決できるかもしれず、一瞬で問題が解決します。

• 運用でのカバーを提案する。例えば売上履歴をグラフ化したい、という要望があったとして、もしプロダクトにデータの CSV 出力機能があればそれを用いて生データを取り出し、Excel や Tableau などでの集計を提案する、といったイメージです。

• 最後は人間力でカバーする。上記では解決できない場合は PdM や エンジニアにかけあい、開発予定 / ロードマップ / プロダクトバックログ への追加の可能性を探ることになると思います。基本的に将来の実装予定は細かくは決まらずクライアントにもあまり開示するものではないので、クライアントからすると「課題が解決されるかわからない」状況になります。そのため、せめて担当の CS / CX がクライアントの声を理解して社内にかけあっているということをクライアントに認識してもらう、といったことは相手も人である以上ある程度の効果が期待できます。

Step3：リプレイスできない状態にする

ここまではある程度のめんどくささはあるものの、クライアントにはリプレイスして他の企業のプロダクトに乗り換えられる状況でどうするかという視点でしたが、そもそもリプレイスができない状態を作れないか? という視点も重要です。

まず契約期間で縛る方法が考えられます。できれば初期導入の際の契約締結時に長めの契約期間を（解約条項付きで）設けられるとよいです。ただクライアントからすると自由度が下がりデメリットが大きいと映ってしまうので、やるとしても大手のクラウドインフラベンダーがよくやるような「N 年契約にしたら M %割引」といった方向性が濃厚かと思います。タイミングとしてはクライアントからの評価が高い状況で「割引の提案がありまして .. 」と切り出すのが効果的です。

また、仕組みやシステムで縛る方法はより強力です。例えばシステムからエクスポートした CSV ファイルをクライアントの基幹システムにインポートするようなワークフローがあるとして、データ形式（CSV カラムの形式）を変換するマクロをクライアントと一緒に作成できると、それは他のシステムに乗り換えると作り直さないといけなくなるため、リプレイスのハードルを上げることに繋がります。
さらにこの例だと、データのエクスポート / インポートを API 連携にしてしまうとそのハードルはぐっと上がります。API 連携の開発はある程度の費用がかかるため、システムの償却の観点などからも他への乗り換えがしにくくなります。API 連携の開発の工数はこちらにも大きくかかるのでどこまでリプレイスができない状況を作りたいか、判断は状況によりますがこちらとしてもズブズブになりたいクライアントであれば、選択肢の一つとしてもっておきたいところです。