オンボーディングの完了要件を決めるとき、品質を一番左右するのは、設定が終わったか、使えるようになったかではない。
顧客が価値を実感しているかどうかである。

オンボーディングは滞りなく完了しているのに、解約が生まれている。そんなときは、まずオンボーディングの完了要件定義を見直してほしい。

■オンボーディングが完了しても、解約が増えるなら意味がない

契約後、カスタマーサクセスがキックオフを実施し、初期設定を一緒に進め、トレーニングも終えた。スケジュールどおりに進み、社内にも「オンボーディング完了」と報告した。

それなのに数か月後、ログイン数がじわじわ落ち、定例で出てくるのは操作の質問ばかりになっている。そして更新の時期に、「あまり使えなかったので」と解約の相談が届く。

このとき、オンボーディングは失敗していたわけではありません。決めたとおりに、滞りなく完了していました。

ずれていたのは、オンボーディングの完了要件の「決め方」です。設定やトレーニングが終わったことは確認していても、顧客が導入初期に価値を実感していなければ、解約に至ることがあります。

なぜなら顧客にとって、そのツールの費用対効果が見えないからです。見えないものにお金を払い続けるのは不安です。だから更新のタイミングで、解約を選ぶ可能性がぐっと上がります。

■オンボーディングの役割を、利用定着から価値実感にアップデートする

顧客ライフサイクルマネジメント2.0では、オンボーディングの役割を「使い方を教えること」ではなく、顧客が「入れてよかった」と価値実感している状態をつくることと定義しています。

従来のオンボーディングでは、手段のほうが完了要件になりがちでした。
・初期設定が終わったので完了
・トレーニングを実施したので完了
・キックオフから3か月経ったので完了

こうした要件が選ばれやすいのは、どれもカスタマーサクセス側でコントロールでき、終わったかどうかが一目でわかり運用しやすいからです。
ただ、この完了要件では、オンボーディングが完了しても、顧客が価値を実感したかどうかは判断できません。価値を実感できるかどうかは、顧客任せになってしまいます。

そこで顧客ライフサイクルマネジメント2.0では、こうした初期設定やトレーニングの完了をQuick-Winと位置づけたうえで、顧客が価値を実感する「ライトサクセス」を、オンボーディングの完了要件として新たに設計することを推奨しています。

■オンボーディング完了要件定義の主語を、自社目線から顧客目線に変える

顧客ライフサイクルマネジメント2.0では、オンボーディング完了要件定義を「自社目線」で決める「タスク完了型」か「顧客目線」で決める「成果創出型」に切り替えることを重要視しています。

例えば、経費精算のサービスを導入したとします。

タスク完了型なら、「初期設定が終わり、社員向けの説明会を開いた」で完了です。
成果創出型なら、「社員が日々の経費申請をサービス上で行い、経理担当者が承認と集計まで回せている」ことを確認して完了です。

後者の状態なら、経理担当者は「申請の差し戻しが減った」「月末の集計が早くなった」と、効果を自分の言葉で説明できます。冒頭で触れた「費用対効果が見えない」という不安は、ここで解消されます。

オンボーディング完了要件定義の主語が変わるだけで、CSがオンボーディングの期間に目指すものはまったく変わります。

■価値の実感は、2つの指標で「見える要件」にする

そしてオンボーディング完了要件定義が満たされているかを、誰が見ても判断できるようにするには、定量化することでチームの基準が揃います。

顧客ライフサイクルマネジメント2.0では、完了要件定義を2つの指標で定義します。

・完了指標：何ができたら完了か
・期日指標：いつまでに達成するか

完了指標は、ライトサクセスの状態、つまり顧客が価値を実感したと判断できる状態を、行動として測るものです。

「プロダクトにログインしている」ではなく、「顧客自身が、日常業務の中で主要な機能を使って一連の作業を回せた」のように、誰が見ても達成したかどうか判断できる形にします。

オンボーディングの完了指標をヘルススコアのように可視化しイメージです。

期日指標は、その状態にいつまでに到達すべきかを決めるものです。

期日があることで、顧客が遅延しているかしていないかを判別することができるようになります。例えばオンボーディング完了までの期間を90日と設定したならば、オンボーディング期間が90日を超えた時点で遅延という扱いになります。

■価値の実感を要件にすると、解約の兆しに先回りできる

オンボーディング完了要件定義を正しく設定し管理していくと様々なメリットが生まれます。

① 解約の兆しに、まだ挽回できるうちに気づける
期日指標に対して遅れている顧客が見えれば、更新の直前ではなく、オンボーディングの段階で手を打てます。冒頭の「滞りなく完了したのに解約」は、多くの場合、この段階で見えていたはずのサインです。

② 顧客が、費用対効果を自分の言葉で説明できるようになる
「初期設定が終わりました」は、顧客にとってあまり意味のない区切りです。一方で「この業務がサービス上で回るようになりました」は、顧客の推進担当者が社内に成果として説明できる区切りです。担当者が社内で評価されることは、更新の判断にも、その後の活用拡大にも追い風になります。

③ アダプションとリニューアルの起点になる
最初に実感した価値を起点に、アダプションでは次の成果を積み上げ、リニューアルではここまでの成果を振り返って次の目標を合意します。最初の価値が曖昧なままだと、その先の支援も、更新の場での会話も、根拠を持ちにくくなりがちです。

■応用編：完了要件から逆算して、手前に中間指標を置く

ここまで読んで、「初期設定やトレーニングの完了は、もう見なくていいのか」と感じる方もいるかもしれません。

そんなことはありません。むしろ、ここからが応用編です。

完了要件としてライトサクセスを定義したら、次はその手前の段階を設計します。初期設定やトレーニングの完了は、まさにこの手前の段階、つまりQuick-Winとして中間指標に置くものです。

ゴールから逆算して中間指標を並べることで、オンボーディングは「完了したか、していないか」の二択から、「いま、どの段階まで来ているか」を追える段階的なプロセスに変わります。

例えば、先ほどの経費精算のサービスなら、こんなふうに段階を分けられます。

① 管理者が初期設定を終え、承認フローがサービス上に組まれている（Quick-Win）

② 社員向けの説明会を経て、全員が1件目の申請をサービス上で出せた

③ 1か月分の経費申請と承認・集計が、サービス上で回っている（ライトサクセス＝オンボーディング完了）

それぞれの段階に期日を置けば、オンボーディングの期間全体を、顧客の習熟度が一段ずつ上がっていく流れとして管理できます。

段階で設計すると、次の2つが変わります。

<1>オンボーディングの進捗がスコアで見れる

完了要件だけでは、期日に届かなかった顧客が「どこで止まったのか」がわかりません。中間指標があれば、「設定は終わったが、社員の1件目の申請が出ていない」のように、止まっている段階がはっきりします。手を打つ場所が決まるので、支援が的確になります。

<2>顧客が価値実感を確実に感じられる

ライトサクセスは、導入直後にいきなり届くものではありません。設定が終わった、初めて使えた、という小さなQuick-Winを一つずつ確かめながら進むことで、顧客の推進担当者も前に進んでいる実感を持てます。その実感が、社内の関係者を巻き込む力にもなります。

完了要件を決めることが基本編だとすれば、そこから逆算して中間指標を置くことは応用編です。

最初から細かく設計する必要はありませんが、まずは完了要件を決め、運用しながら「どこでつまずく顧客が多いか」を見て、その手前に中間指標を足していく。そうやって、オンボーディングの設計そのものの習熟度が上がっていきます。

■まとめ

オンボーディング完了要件定義の重要性はご理解いただけましたでしょうか。

「明日から使えるCS実践トレーニング」のDay2では、オンボーディング完了要件定義の決め方も取り扱っていきます。

オンボーディングの完了要件で一番大事なのは、設定が終わったか、使えるようになったかではなく、顧客が価値を実感しているかどうかです。オンボーディングが滞りなく終わることと、顧客が価値を実感することは、同じではありません。

オンボーディングが正しく完了することで、顧客のLTVが伸びる。そんな健全な状態を目指していきましょう！