新しく契約したお客様が、最初のログインで手が止まってしまう。ヘルプ記事は用意しているのに読まれず、定着する前に「使い方を教えてほしい」という問い合わせが集中する。BtoB SaaSのカスタマーサクセスでは、よくある状況だと思います。
オンボーディングの改善というと大がかりな仕組みの話になりがちですが、現場でまず効くのは「最初の1回の操作を、読ませずに見せる」ことです。この記事では、インタラクティブデモ（触れるデモ）を使って使い始めの案内をつくる手順と、どこまでを守備範囲にすべきかの線引きを整理します。ツールを使わない場合にも応用できる考え方から書きます。
使い始めでつまずくのは、機能の難しさより順番の問題
初回ログイン直後の離脱は、機能が難しいから起きているとは限りません。多くは「何から手を付ければいいのか分からない」という順番の問題です。管理者の初期設定、データの取り込み、メンバーの招待と、価値を感じる前にやることだけが積み上がると、忙しい担当者ほど後回しにします。
文章のマニュアルが読まれにくいのも、内容が悪いからではありません。読み手は「文章を読む→自社の画面に戻る→さっきの説明はどこだったか探す」という往復を強いられます。この往復が三度も続くと、多くの人は自己流で触り始め、うまくいかないまま止まります。
つまり改善すべきは説明の量ではなく、最初の成功体験までの距離です。自社のオンボーディングを見直すときは、次の観点で棚卸ししてみてください。
- 価値を実感できる操作にたどり着くまでに、準備タスクが多すぎないか
- 説明が文章だけで、実際の画面とひも付いていないのではないか
- 案内が長く、どれが必須でどれが後回しでよいのか分からなくなっていないか
- 先方の担当者が交代したときに、同じ説明を毎回人力でやり直していないか
前提の線引き：アプリ内ガイド（DAP）とは別の道具です
先に誤解を潰しておきます。Sawatteは、自社アプリの中にツールチップやチェックリストを重ねて表示する、いわゆるDAP（アプリ内ガイド）ではありません。実際の画面を記録して、その体験を製品の外側に置くための道具です。
ですから「全ユーザーのログイン画面に常時ガイドを出したい」「操作の進み具合に応じてヒントを出し分けたい」といった要件は、この記事の範囲外になります。一方で、案内メール・ヘルプ記事・キックオフ資料といった外側の接点であれば、触れるデモはそのまま置けます。実務では、この外側だけでも「見れば分かる」種類の問い合わせを吸収しやすくなります。
インタラクティブデモそのものの位置づけや、資料・動画・トライアルとの住み分けは「インタラクティブデモとは？」の記事で整理しています。
置き場所は3つに絞る
使い始めの案内は、置き場所を増やすほど運用が破綻します。更新のたびに全部を直せなくなるからです。まずは次の3か所に絞ると、作る側も回しやすくなります。
- 契約直後のキックオフ案内メール：本文は短くし、「まずこの3ステップだけ」と書いて共有リンクを1本だけ置く
- ヘルプ記事の冒頭：長い手順書の一番上に触れるデモへのリンクを置き、細部は本文で補う（記事の中に埋め込む場合はプロプランのiframe埋め込みを使います）
- 先方の社内展開用の資料：導入企業の担当者が自社メンバーへ配ることを前提に、リンクを渡しておく
デモ化するのは、中核フロー1本だけ
最初から網羅しようとすると、作る側が疲れて更新が止まります。デモ化するのは「これができたら使い始めは成功だ」と言い切れる操作を1つだけ選びます。勤怠なら打刻、経費精算なら申請を1件出すところまで、分析ツールならレポートを1枚出すところまで、といった具合です。
ステップ数の目安は7〜10です。初期設定やデータ取り込みといった準備作業は、価値を感じる操作の後ろに回すか、別のデモに分けます。「触って嬉しい→そのために必要な準備」の順に並べたほうが、読み手の意欲が続きます。
説明文は1ステップにつき1つのことだけを書きます。画面に出ているボタンの文言をそのまま引用すると、閲覧者が自分の画面と照合しやすくなり、迷いが減ります。共有リンクは閲覧者のログインが不要で、普通のWebページとして開きます。相手企業の事情で新しいツールを入れられない場合でも、ブラウザさえあれば見られるのは実務上ありがたい点です。
答えきれない疑問は、デモの中で受け止める
案内を配ると、必ず「うちの場合はどうなるのか」という質問が返ってきます。プロプランの「質問できるデモ」を使うと、閲覧者がデモを見ながらその場でAIに質問できます。あらかじめ製品マニュアルを12,000文字まで登録でき、質問は月500問までです。
登録する文章は全文である必要はありません。よくある質問、主要機能の説明、仕様と制限、料金まわりを抜粋したほうが、回答の精度は安定します。詳しい設計は「質問できるデモ」の記事にまとめています。ここで拾えなかった質問だけを人が受ける形にすれば、問い合わせ対応の総量は下げやすくなります。
作った後に腐らせない
オンボーディング資料が形骸化する最大の理由は、UIが変わったときに直す人がいないことです。触れるデモも同じで、作るコストより維持コストのほうが効いてきます。四半期に一度、中核フローのデモを開いて実際の画面と見比べる、くらいの運用ルールは決めておいたほうが安全です。
Sawatteでは、プロプランに限り撮り直しても編集内容を引き継げます。更新の手間をどう減らすかという運用の考え方は「腐らないデモの仕組み」の記事で詳しく扱っています。フリープランでもデモは2つまで作れるので、まずは中核フロー1本を作って社内で回覧してみるのが現実的な始め方です。
まとめ
使い始めの改善は、案内の量を増やすことではなく、最初の1回を確実に成功させることです。中核フローを1本だけ触れるデモにして、案内メール・ヘルプ記事・展開資料の3か所に置く。ここまでなら小さく始められますし、最短5分で最初のデモを公開できます。
そのうえで、質問はデモの中で吸収し、UIが変わったら直す担当を決めておく。この3点を回せるかどうかが、オンボーディング施策が続くかどうかの分かれ目になります。