SaaS チームがオンボーディングを、自ら完走する旅に変えるには

起点

このシナリオでは、あるアナリティクス SaaS がサインアップは健全でアクティベーションが弱い状態です。多くの人がアカウントを作り、何も接続せず、二度と戻りません。オンボーディングはタイマーで発火する5通のメールのドリップでした——ユーザーが何かをしたかどうかに関わらず同じ配列——そしてカスタマーサクセスのチームは最大のアカウントしか手厚く見られませんでした。あるアカウントがどのステップで詰まっているかは、すでに解約したあとになるまで誰も言えませんでした。

その旅

チームはアクティベーションフローをストーリーライン——エージェントが新しいアカウントごとにたどるグラフ——として設計します。

1. ようこそ。 初回サインイン時、エージェントは自己紹介し、まさにそのアプリ内で、最初のデータソースの接続を手伝うと申し出ます。
2. データソースを接続。 このステップは、ユーザーがやったと言うから進むのではありません——プロダクトがコールバックを通じて実際のイベントをエージェントに報告し返したときに進みます。そのシグナルが届くまで、エージェントはこのステップに留まり、ユーザーが音沙汰なくなれば軽めの道を差し出します。
3. 最初のレポートを作る。 同じ形。エージェントが導き、プロダクト自身の「レポート作成済み」イベントがアカウントを前進させます。
4. チームメートを招待、それから週次レビューの習慣を作る——それぞれがステップで、それぞれが実際のシグナルで前進し、それぞれが誰かの停滞時に後押しや引き継ぎへ分岐できます。

進捗は人に対して保存されるので、旅はアプリ内アシスタントとメールをまたいで続きます。ステップ2の後に離脱したユーザーは、3日後にトップからやり直すのではなく、ステップ2で拾い上げられます。

何が変わるか

エージェントは会社自身のヘルプドキュメントから答えるので、汎用ではなくこのプロダクトについて語ります。24時間走るので、真夜中のサインアップにも即座に応じます。そして、優れたオンボーディング担当者の判断——次に何をするか、いつ押すか、いつ引くか——を、すべてのアカウントに同時に広げ、本当に停滞したアカウントだけに人間をルーティングします。

ここでの数字は測定値ではなく構造的なものです。一斉配信の配列ではなくユーザーごとに保存された1つの旅、24/7 のカバレッジ、そしてユーザーの自己申告ではなく実際のプロダクトイベントで進めたゼロのステップ。これは特定のデプロイの報告ではなく、その形の一例です。