スクリーンショット付きのカスタマーサポートガイドの作り方

優れたサポート記事は、多くの場合チケットから始まります。同じ質問が1週間に3回届くなら、スクリーンショットガイドは4件目の問い合わせに、文章での返信より速く答えられます。また、すべてのエージェントが同じ回答を送れます。

この記事では、解決済みのチケットをガイドに変える方法、Mac の Temposhot でスクリーンショットを作成する方法、結果をサポートチームに引き渡す方法を説明します。

解決済みの顧客の問題を1つ選ぶ

すでに解決済みで、修正方法を信頼できるチケットを選びます。原因が不明なままガイドを書くと、その推測が、ガイドを読むすべての顧客に伝わります。

適した候補には、次の3つの特徴があります。

• 問い合わせてくる顧客の多くに、同じ修正方法が当てはまる。
• 修正方法が3ステップを超えるか、見つけにくいコントロールを使う。
• エージェントが現在、自由記述の文章でそれぞれ異なる説明をしている。

ガイドのタイトルには、顧客自身の言葉を使います。「アカウントのメールアドレスを変更する」は、利用者が検索に入力する語と一致します。「アカウントのメール管理」は一致しません。

候補チケットを採点する

各候補について、直近30日間のチケット数を数え、修正手順のステップ数も数えます。件数と手順の長さで優先順位を決めます。月に11件届き、修正手順が4ステップの問題は、まれにしか届かず手順が12ステップの問題より多くの返信を減らします。

請求先メールの修正は件数が多く、手順も明確なため優先されます。2段階認証のリセットも頻繁に届きますが、サポートポリシーで定められた本人確認に依存します。このガイドは、ポリシーの責任者と一緒に作成します。そうすると、ガイドが顧客をポリシーどおりに進め、確認を省略しないようになります。

修正内容を機能の担当者に確認する

チケットの修正は、一時的な回避策の場合があります。撮影の前に、機能の担当者に、その手順が正式にサポートされた方法かどうかを確認します。確認した人の名前と日付を、ガイドのオーナー欄に記載します。リリース後に回避策が動かなくなった場合、報告先の担当者がすぐにわかります。担当者が手順を確認できない場合は、チケットをサポートリーダーのもとで未解決のままにし、ガイドは公開しません。

ガイドの適用範囲を定める

あるプランでは機能するが別のプランでは失敗するガイドは、新しいチケットを生みます。冒頭の1〜2行で範囲を示します。

• 手順が有効なプランまたはアカウントの種類
• プラットフォーム（Web、デスクトップアプリ、モバイルアプリ）
• 必要なロール（アカウントオーナー、管理者など）
• 顧客が事前に用意すべきもの（注文番号など）

プラットフォームごとに手順が異なる場合は、各ページに分岐を入れた1つのガイドではなく、2つのガイドを作成します。

Web とモバイルのガイドを分ける

請求先メールの項目は、Web アプリでは Account の下に、モバイルアプリでは Profile の下にあります。両方の経路を含む1つのガイドでは、読み手が各ページで分岐を探す必要があります。同じタイトルの基部を使い、「請求先メールアドレスを変更する（Web）」と「請求先メールアドレスを変更する（モバイル）」の2つを作成します。

各ガイドの範囲ブロックには、対象のプラットフォームを明記します。エージェントは最初の返信で正しいガイドを送ることができ、顧客は誤った経路に進みません。

範囲の条件を表で示す

文中の範囲の記載は読み飛ばされやすいです。ガイドの冒頭に短い表を置くと、各条件が見えるようになります。以下の例は請求先メールのガイドを対象とします。最後の行は、このガイドの最も多い誤った使い方を除外します。

各行は、エージェントが最初の返信で尋ねるはずの質問に答えます。「対象外」の行が最も重要です。顧客はこの行を読むと最初の手順の前に止まり、エージェントには正しいアカウントの種類が記載された状態でチケットが届きます。

テスト用データで解決手順を再現する

スタッフのアカウントで撮ると、顧客が持たないメニューが写ります。顧客の実アカウントで撮ると、顧客のデータが写ります。同じプランのテストアカウントを使い、「Sample Customer」のような仮の氏名と、例のメールドメインを設定します。

1. Start Action Capture

   Command+3 を押し、Start Action Capture を選択して、ブラウザまたはアプリの Specific Window を選びます。

2. 顧客がスタートする画面から始める

   顧客がサインインした後に見る画面から始めます。スタッフだけが知るディープリンクからは始めません。

3. 修正手順を実行する

   各手順をクリックして進みます。受け付けたクリックごとに、そのクリックの直前のウィンドウが保存されます。

4. 実行を終了する

   フローティングツールバーで Finish capture を選択します。Document がエディタで開き、1ステップにつき1ページになります。

Configure で Parse clicked elements をオンにすると、ページタイトルは、コントロールのラベルを入れた Click "[[element-name]]" から始まります。設定の一覧は Action Capture ガイド を参照してください。

チケットをテスト手順として使う

チケットのスレッドがテスト手順になります。顧客が説明した操作を、うまくいかなかった試みも含めて順番にコピーします。チケットに現れる失敗した試みは、通常、注意書きが必要な手順を示します。注意書きは、その手順の後ではなく前のページに追加し、読み手がクリックの前に確認できるようにします。

テストアカウントを準備する

修正は、チケットが記述するアカウントの状態で機能する必要があります。保留中の請求書に依存する変更は、新規アカウントでは失敗します。撮影の前にその状態を用意します。以下のチェックリストは、よくある不足を扱います。

最初の実行の前に、ズームの値を確認します。110%のズームで撮影したガイドを100%で読むと、コントロールの位置が異なり、読み手はスクリーンショットを画面と照合できません。

エラーの経路を記録する

チケットによっては、エラーから始まるものがあります。顧客にエラーが表示された時点で、テストアカウント上で一度だけ記録します。そのページの説明に、正確なエラーメッセージを記載し、修正は次のページに置きます。同じエラーを見た読み手は、開始前に正しいガイドを選んでいるか確認できます。

修正が短くても、エラーのページはガイドに残します。エージェントはエラーメッセージの文言で検索します。説明にその文言があるページは、スクリーンショットだけのページより見つけやすくなります。

重要なショートカットを記録する

録画そのものは、いくつかのキーで操作します。以下のショートカットは、録画と編集の両方に使います。

撮影の判断点とチェックポイント

ほとんどのサポートの修正には、顧客が選択しなければならない場面があります。ドロップダウンのどの選択肢か、設定のどのタブかです。その場面に独立したページを与え、説明で選択内容を明記します。

画面によっては、ローディング状態や確認バナーのように、クリックなしで表示されるものがあります。これらを保存するには、Shift+Command+2（手動撮影のショートカット）を押すか、Capture now を選択します。これらのチェックポイントがないガイドでは、顧客は最後のクリックが機能したかどうかを確信できません。

ページ上で選択肢を明記する

判断のページには、画面に表示される選択肢の名前と、その選択肢が正しい条件を書きます。以下の表は、よくある言い回しの問題を示します。左の列のルールは、すべての判断ページに適用されます。

待機状態を撮影する

顧客は、スピナーや「Processing」の表示で止まり、もう一度クリックすることがあります。待機状態を独立したページとして撮影し、待ち時間の長さと、その間にしてはいけないことを説明に書きます。例：「Processing は通常1分以内に完了します。このラベルが表示されている間は、Save を再度選択しないでください。」

メールを送信する手順や、バックグラウンドで値を変更する手順にも同じルールを使います。ページの説明に想定される遅延を書き、顧客がいつ待つのをやめてよいかわかるようにします。

長いドロップダウンを扱う

約10項目を超えるドロップダウンは、読みやすいサイズで1枚のスクリーンショットに収まりません。対象の項目が見える状態でリストを開いて撮影し、選択後のフィールドを示すページを追加します。最初のページのタイトルに項目名を、2つ目のページのタイトルに結果を入れます。

読み手にリストのスクロールを任せてはいけません。項目が表示領域の下にある場合は、その項目を含む Framing の切り抜きを使い、説明に「下から4番目の「Annual」までスクロールする」のように記載します。

各手順を顧客の次の操作に合わせて書く

解析されたタイトルを書き直し、顧客が次に行うことを、動詞で始めて示します。

解析されたタイトル	書き直したタイトル
Click "Settings"	Settings を開く
Click "Email"	Email フィールドを選択する
Click here	新しいプランを選ぶ

コントロールにズームするには、Framing（F）と Focus on action を使います。Balanced または Close は、通常、ノートパソコンの読み手に十分な文脈を残します。誤ったクリックで作成されたページは、Pages パネルから削除します。

ラベルではなく結果を書く

解析されたタイトルは、コントロールのラベルをそのままコピーします。「OK」や「Submit」のようなラベルは、結果について何も伝えません。タイトルを、クリックが何をするかを示す形に書き直します。例：「Save を選択して新しいメールアドレスを適用する」。顧客は、クリックの前に何が変わるかがわかります。

各タイトルは、直後のページの画面と照合します。タイトルが次のページに表示されない結果を示している場合、その手順にはチェックポイントが欠けています。

1手順に1つの操作を含める

「アカウントを開き、Email を選択して、アドレスを入力する」という手順は、2つの判断を隠しています。2つ目の操作で失敗した読み手には、指し示すページがありません。手順を3つに分けます。アカウントを開く、Email を選択する、アドレスを入力する。各手順は、1枚のスクリーンショットと、それに一致する1つのタイトルを持ちます。

例外が1つあります。アドレスの入力と Return キーの押下のように、画面が1つの単位として扱う2つの操作は、結果が1ページにまとまる場合に1つの手順にできます。両方の操作をタイトルに書きます。例：「アドレスを入力して Return を押す」。

成功の確認を追加する

ガイドの最後に、作業が成功したときに顧客が見るものを書きます。バナー、更新された値、確認メールなどです。その画面を撮影し、「Account の下に新しいメールアドレスが表示される」のように、結果としてタイトルを付けます。

成功の確認がないと、顧客は手順を繰り返すか、確認のためにチケットを開くことがよくあります。

完成したガイドのページ順

以下のフローは、請求先メールのガイドのページ順を示します。各ボックスが Document の1ページで、矢印は読み手が従う順序を示します。

成功の確認は、エスカレーションページの直前のページです。バナーを見た顧客はそこで止まります。バナーを見なかった顧客は、止まった画面とともにエスカレーションページに到達します。

エスカレーションの条件と証拠を追加する

ガイドでは解決できなくなった時点と、顧客がサポートに連絡すべき条件を明記します。観察できる条件を書きます。エラーメッセージ、見当たらないボタン、変わらない請求額などです。

顧客が送るべき情報を伝えると、エージェントが質問する必要がなくなります。送る情報は、エラーメッセージの文言、時刻、操作が止まった画面のスクリーンショットです。送信する前に、パスワードとカード番号を削除するよう求めます。

エスカレーションのブロックを書く

エスカレーションを受けるエージェントは、質問せずに5つの情報を必要とします。アカウント識別子、プラン、プラットフォーム、正確なエラーメッセージ、タイムゾーン付きの時刻です。これらの情報を、ガイドの末尾にある固定のブロックにまとめます。顧客はそのブロックをメッセージにコピーし、エージェントの最初の返信は問題に直接対応できます。

ガイドの効果を測る

ガイドを公開した後、2週間、同じ問題のチケット数を数えます。以下の例は、自由記述の返信を置き換えた請求先メールのガイドのものです。

エラーのある残りのチケットはエスカレーションページに進み、返信は短くなりました。エラーテキストがなければ、エージェントはそれを尋ねる必要があり、スレッドに返信が1往復増えます。エスカレーションは製品の問題ではなくガイドの欠落を示すため、別に数えます。各エスカレーションは、チケットから1週間以内に確認します。ガイドで答えられたはずの返信は書き直すべきページを示し、ガイドで答えられない返信は新しい範囲の条件を示します。

公開前に非表示処理を行う

非表示の処理は、ガイドがヘルプセンターに届く前の最後の編集です。以下の順序で行うと、エディタの表示ではなく、書き出したサイズで各ページを確認できます。

新しい読み手でガイドをテストする

書き出したガイドを、作成していない人、できれば新しいエージェントに渡し、テストアカウントで支援なしに修正を完了してもらいます。読み手が行う質問は、それぞれ書き直すべきページを示します。

その後で公開します。Temposhot には、ホスト型のページや埋め込み機能がありません。そのため、送付先ごとに書き出します。ヘルプセンターの記事には PNG または WebP のページを、メールの添付には Export PDF を使います。形式の一覧は Documents の書き出しガイド を参照してください。2つの選択肢の違いについては、PDF ガイドとオンラインのナレッジベース を参照してください。

読み手のテストの時間を計る

読み手のテストは、顧客のセッションと同じ方法で記録します。各停止地点の時刻を記録します。1ページで長く止まった場合は、そのタイトルか判断に修正が必要であることを示します。

最初に判断ページを書き直します。この例では、新しいメールアドレスが古いものを即座に置き換えるかどうかが質問でした。その答えを判断ページの説明に入れたところ、次の読み手はそこで止まらなくなりました。

読み手の条件を設定する

ガイドが前提とする、同じブラウザのズーム、ウィンドウサイズ、アカウントの状態を読み手に与えます。小さいウィンドウの読み手は異なるレイアウトを見るため、最初のスクリーンショットと照合できません。その場合、テストは、ガイド側で直せる理由で失敗します。レイアウトがウィンドウサイズに依存する場合は、範囲ブロックにウィンドウサイズを記載します。

ヘルプセンター向けにガイドを整理する

各ガイドは、顧客自身の言葉で名付けたフォルダに保存します。そうすると、フォルダ名が読み手の検索語と一致します。PNG のページは、元になった PDF と同じフォルダに置き、2つをまとめて差し替えやすくします。

PNG のファイル名にステップ番号を使います。そうすると、Finder でフォルダを開いたときに、ページが読み順に並びます。

よくある質問

サポートガイドの手順は何ステップにすべきですか？

修正に必要なだけのステップ数にし、1ステップに1つの操作だけを含めます。ガイドが約10ステップを超える場合は、2つの問題を扱っていないか確認します。

サポートガイドには実際の顧客のスクリーンショットを使うべきですか？

使いません。テストアカウントで修正を再現します。実際の顧客のスクリーンショットには個人情報が含まれ、その顧客だけの設定が写る可能性があります。

サポートガイドを最新の状態に保つにはどうすればよいですか？

各ガイドにオーナーと最終確認日を設定し、リリースでそれらの画面に変更があった場合に再確認します。詳細は スクリーンショットのドキュメントを最新に保つ方法 を参照してください。

ガイドはチケットへの返信を置き換えますか？

置き換えません。ガイドは返信のうち繰り返し発生する部分を置き換えます。エージェントは引き続きアカウントの状態を確認し、返金の判断など、ガイドが扱わない詳細を追加します。

ガイドが製品に合っているかどうか、どうすればわかりますか？

リリースでその画面に変更があった場合はガイドを確認し、判断ページを変更した後は読み手のテストを再実行します。ボタンのラベルやメニューの位置の変更は、ガイドの変更として扱います。

公開後、ガイドは誰が管理しますか？

ガイドのオーナー欄に記載された人が管理します。その人は、読み手からのフィードバックに答え、エスカレーションの原因となったページを書き直し、機能が変わったときにガイドを廃止します。共有のヘルプセンターのフォルダだけでは、オーナーは決まりません。

読み手はどこにフィードバックを送ればよいですか？

ガイドの最後の行に、サポートのチャネルを記載します。スクリーンショットは返信を受け付けられないため、質問がある読み手には、担当者に届く経路が必要です。

ガイドはいつ廃止すべきですか？

そのガイドが説明する機能が変わった場合、または機能が存在する間にチケット件数が3か月連続で0のままの場合に廃止します。ヘルプセンターからガイドを削除し、書き出したファイルは日付付きのアーカイブフォルダに保管します。廃止されたガイドが検索に残ると、読み手は存在しない手順に導かれます。

クリックを明確なステップごとのガイドに変える

Action Capture は、修正を一度記録し、編集と書き出しができる順序付きのガイドを作成します。Temposhot をダウンロード して、最も頻繁に届くチケットをガイドにしてください。