顧客教育動画：本当に使われるライブラリの作り方

01

顧客教育動画とは何か

顧客教育ビデオは、製品をすでに使用、評価、サポートしており、特定の作業を実行する必要がある人向けに作成されています。権限の構成、レポートの解釈、データの移行、設定の選択、または一般的なエラーからの回復方法について説明する場合があります。仕上がり状態が観察できるはずです。 「プラットフォームを知る」というのは範囲が広すぎます。 「適切な役割を持つチームメイトを招待し、その招待を確認する」ことで、ライター、編集者、査読者に守るべき具体的なものが与えられます。

これは、社内の役割に向けてスタッフを準備させる従業員オンボーディングや、カテゴリーの理解を構築する広範なブランド説明とは異なります。製品デモと重複する場合もありますが、本来の仕事は異なります。通常、デモにより購入の不確実性が軽減されます。顧客教育は、導入後または導入中の顧客の成功に役立ちます。 1 つのビデオが販売、オンボーディング、すべての機能の文書化、エッジケースのトラブルシューティングを試みる場合、視聴者は直接の答えを得る代わりに、ビデオ内を検索する必要があります。

02

形式を選ぶ前に顧客の質問を整理する

カスタマー ジャーニーの証拠から始めます。サポートでの会話、導入メモ、製品検索用語、通話記録、オンボーディング チェックリスト、カスタマー サクセスからの繰り返しの質問などです。ナビゲーションの順序ではなく、顧客の仕事ごとに質問をグループ化します。請求管理者と日常のオペレーターは同じページに触れるかもしれませんが、異なる説明が必要です。マップには、対象者、トリガー、開始状態、望ましい結果、間違って実行された場合のリスク、および回答を承認できるソース所有者を記載する必要があります。

次に、ジョブを解決する最小の形式を選択します。変更されたコントロールを指摘するには、30 秒の注釈付きクリップで十分な場合があります。 2 分間の画面チュートリアルで、直線的なセットアップを示すことができます。顧客がインターフェイスに触れる前にメンタル モデルが必要な場合は、ナレーション付きの図の方が適しています。長いウェビナーはディスカッションには役立ちますが、繰り返し行われるタスクに対する唯一の答えになるべきではありません。焦点を絞ったチャプターまたはコンパニオンビデオを抽出して、顧客が 1 つの設定のイベント録画を調べなくて済むようにします。

編集を始める前に、質問マップを優先順位付きバックログへ変えます。priority score には頻度、顧客リスク、業務上の重要度、回答の安定性、誤回答の損失を使います。万能な計算式ではなく判断材料です。頻出する低リスクの操作は短いクリップでよくても、件数の少ない権限や請求の質問は誤りの影響が大きいため上位になります。各点数の根拠、日付、承認者を残し、リリースや新しい問い合わせ傾向に合わせて見直します。これで制作順は直近の依頼ではなく説明可能な判断に基づきます。

03

台本の前に正本資料を作る

すべてのビデオは、承認されたソース素材を参照する必要があります。現在のヘルプ記事または手順、製品のスクリーンショット、正確なインターフェイス ラベル、ポリシーの文言、モデル名、必要に応じて価格、指名されたレビュー担当者を含むコンパクトな信頼できる情報源パックを構築します。そのままにしておく必要があるテキストにマークを付けます。ステートメントがソース パックでサポートされていない場合は、ステートメントを削除するか、承認のために送り返してください。これにより、洗練された編集によって、時代遅れのラベル、発明された機能、または魅力的だがサポートされていないショートカットが静かに導入されることが防止されます。

3 つのレイヤーで精度を確認します。アセットの忠実度では、提供されたスクリーンショット、製品画像、ロゴ、または映像が、再描画された代替物ではなく、意図されたソースのままであるかどうかが問われます。情報の忠実度では、承認された文言、数値、設定、条件が正確に保たれているかどうかが問われます。通信では、画面上のビジュアルがその時点で議論されている製品、機能、またはステップと一致するかどうかを尋ねます。これらのチェックは完璧な出力を約束するものではありません。修正できるほど早い段階でエラーを可視化します。

04

行動を中心に書き、発言を画面へ対応させる

実際のスクリプトは、結果に名前を付けることから始まり、前提条件を確認し、有効な最短パスを示し、証明状態で一時停止し、次のアクションを説明します。ナレーションは、目に見えるラベルをすべて読むのではなく、意味を追加する必要があります。必要な選択範囲を隠すようなカットは避けてください。スクリプトに「管理者ロールを選択してください」と表示されている場合、フレームには一般的なダッシュボードではなく、そのロールが表示されるはずです。このクレームと画面のマッピングは、作家、主題の査読者、および編集者の間での制作契約です。

製品が頻繁に変更される場合は、モジュールを独立させてください。耐久性のあるコンセプトを 1 つのビデオに入れ、不安定なインターフェイスのステップを別のビデオに入れるか、ストーリー全体を書き直さずに置き換えられるシーンを使用します。機能の紹介は、別のセットアップ チュートリアルにリンクできます。トラブルシューティング ブランチは、正常なパスを再生する代わりに、エラー状態から開始できます。 TapVid では、承認されたコピーとアセットを出力前にレビューでき、変更された行や画像を適切なシーンで処理しながら、保存されたバージョンを利用できます。納品前に実際の出力を確認してください。

公開されている業界例として、Ahrefs の公式チュートリアル「How to use Ahrefs to Improve SEO」を見てください。視聴者の問いから製品への入力、目に見える結果、次の行動へ進む教え方を確認できます。これは Ahrefs の外部事例であり、TapVid の出力でも成果の証明でもありません。顧客成果を推測せず、説明構造だけを分析してください。

収録前に Education brief を作ります。顧客の役割、質問の契機、開始状態、確認可能な完了状態、前提条件、承認済み資料、保護する文言、各主張の画面や素材、分岐、レビュー担当、掲載場所、更新条件を記録します。結果、前提、操作、証拠状態、復旧方法、次の一歩の6ビートにします。招待動画ならクリック前の必要権限、送信後の状態、メールが届かない場合の確認まで示します。対象外も明記し、もっともらしい未承認手順の追加を防ぎ、後任が元の判断を追跡できるようにします。

05

質問が生まれる場所に答えを置く

強力な動画も、顧客が見つけられなければ役に立ちません。ヘルプ記事、オンボーディング チェックリスト、製品内ガイダンス、電子メール、または質問がすでに表示されているサポートの返信に回答を入力します。 「ワークスペースを制御する」ではなく、「ワークスペースの所有者を変更する」など、オブジェクトとタスクを含む文字通りのタイトルを使用します。短いテキストの概要、前提条件、関連リンク、最終レビュー日を追加して、顧客が再生を押す前に答えが当てはまるかどうか判断できるようにします。

音声のみに依存せずにビデオを使用できるようにします。 W3C は、キャプションは音声と必要な非音声オーディオの同期されたテキストを提供し、自動キャプションは精度のレビューが必要であると説明しています： W3C キャプション ガイダンス。 YouTube のチャプター ガイダンス で説明されているように、長いビデオの場合、チャプターで個別のセクションを作成し、特定の部分を再視聴しやすくすることができます。章によりナビゲーションが向上します。無関係なジョブが混在しているビデオは修復されません。

06

最初の変更前に更新フローを決める

すべての顧客教育ビデオを保守された製品資産として扱います。所有者、ソースドキュメント、影響を受ける製品領域、ロケールバリアント、配布場所、更新トリガーを記録します。トリガーには、コントロールの名前変更、ポリシーの変更、新しい計画の境界、ワークフローの変更、スクリーンショットの置き換え、サポートの混乱の繰り返しなどが含まれる場合があります。四半期ごとのレビュー日では遅いドリフトを捉えることができますが、リリースによって顧客の経路がすぐに変わる場合は、イベントベースのトリガーの方が高速です。

変更が到着したら、編集する前に分類します。言葉遣いのみの修正は、1 つのシーンとそのキャプションに影響を与える可能性があります。ワークフローが変更されると、新しいブランチまたはビデオの置き換えが必要になる場合があります。新しいビジュアル スタイルだけが正確な指示を無効にする理由になることはほとんどありません。置き換えのレビューに合格するまで、以前の承認されたバージョンを保存し、その後、すべての埋め込みとヘルプセンターのリファレンスを更新します。 Final.mp4 というファイルをサイレントに上書きしないでください。レビュー担当者が追跡できるバージョン識別子、承認日、および変更メモを使用します。

更新ルールと同じ精度で retirement rule を決めます。顧客タスクが消えた、正規手順が移動した、互換性のない分岐になった、または承認済み代替版が全掲載先に反映された場合は公開導線から外します。ただし履歴は消さず、旧ファイル、承認日、参照資料、代替URL、理由を保持方針に従って台帳に残します。すぐ直せない既知の誤りには暫定警告を出し、ヘルプ、オンボーディングメール、定型返信、製品内リンク、翻訳、パートナーポータルを確認します。これで古い動画の再利用を防げます。

07

成果を作らずに有用性を測る

お客様の業務に合わせた施策を選択してください。発見指標には、検索の終了、結果がゼロの検索、および関連するヘルプ ページからのクリックが含まれます。使用方法には、開始、有意義な進行、章のジャンプ、難しいステップの再視聴、リンクされた手順へのアクセスなどが含まれます。結果の測定には、より強力な設計が必要です。つまり、ユーザビリティ テストでのタスクの完了、構成イベントの成功、同じ問題に対する繰り返しの問い合わせの削減、または答えが問題を解決したかどうかを尋ねる短い質問です。期間を比較する前に、ウィンドウと分母を定義します。

顧客への教育により、顧客の定着率、完了率、サポートの逸脱率が自動的に向上すると主張しないでください。これらの結果は、視聴者、製品デザイン、流通、測定、その他多くの変化によって決まります。ベースラインを使用し、焦点を絞った回答を 1 つリリースし、交絡因子に注意しながら関連する動作を比較します。定性的な証拠も重要です。サポート エージェントが「顧客はまだステップ 3 で失敗しています」ということはパフォーマンス統計ではありませんが、画面、前提条件、またはブランチの修正が必要であることを示す特定のシグナルです。

discovery, use, and outcome を分けて報告します。Discovery は表示、検索語、ゼロ件検索、クリックから正しい顧客が回答を見つけたかを見ます。Use は再生、意味のある進行、章移動、見直し、必須手順付近の離脱を見ます。Outcome は定義した作業の完了や同じ問題の再発を所定期間で確認します。公開前に分母、観測期間、除外条件を決め、リリース、施策、サポート体制、計測不備も記録します。高い再生率は完了を証明せず、問い合わせ減少だけでは因果を証明できません。測定は維持、改訂、再配布、廃止の判断に使います。

08

確認リストとFAQ

公開する前に、対象顧客に該当する人に、指示された前提条件から始めて、コーチングなしでビデオに従うように依頼してください。正確なラベル、ポインターの可視性、タイミング、キャプション、音声、リンク、終了状態を確認します。提供されたすべてのアセットをその出力フレームと比較し、すべての保護されたフレーズを承認されたソースと比較します。顧客が目にするページで埋め込みをテストします。ビデオでカバーされていないプラン、役割、製品バージョン、言語、ブランチなどの制限を記録します。

TapVid は、チームが製品アセットと準備済みのスクリプトを承認し、本番環境を通じて常に表示および確認できるようにする必要がある場合に適しています。これらの入力を説明またはチュートリアルに変え、スクリプトとシーンの関係を検査可能に保ち、コピーまたは画像が変更されたときに関連するシーンを再実行するのに役立ちます。ソース所有者、主題の承認、アクセシビリティのレビュー、または顧客によるテストの必要性がなくなるわけではありません。成果物は、それらの人々が実際のビデオを確認した後でのみ準備が整います。