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

この記事では、解決済みの問い合わせを、繰り返し使えるビジュアル資料に変える方法を説明します。1つの問題を選び、ガイドを使える条件を定め、安全に解決方法を再現し、重要な手順を撮影します。エスカレーションの条件を加えたら、背景を知らない読者に試してもらいます。

要点: サポートガイドでは、顧客が問題を見分け、検証済みの解決方法を1つ実行し、成功を確認できるようにします。解決しない場合に何を用意すべきかも示します。

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

最初に向くのは、確認済みの解決方法がある、繰り返し発生する問題です。最近の問い合わせから、担当者が毎回同じように回答し、アカウント固有の介入なしに顧客が解決できる質問を探します。

ガイドは1つの結果に絞ります。「macOSで画面収録を許可する」は対象が明確です。「Shotomaticの権限を直す」では、画面収録、アクセシビリティ、ファイルアクセス、OS側の制限など、確認方法の異なる問題が混在する可能性があります。

不確かな回避策を資料にしないでください。スクリーンショットに時間をかけ、標準手順として公開する前に、現在の製品バージョンで解決方法を確認します。

ガイドを使える条件を定義する

冒頭を読めば、自分の問題に合うガイドかを顧客が判断できるようにします。画面に見える症状、該当する製品領域、プラットフォーム、手順が変わるアカウントや権限の状態を明記してください。

簡潔な適用条件を置きます。

このガイドを使う条件：
- 顧客に［具体的な症状］が表示される。
- ［プラットフォームまたは製品領域］を使っている。
- ［必要条件］が満たされている。

別のガイドを使う条件：
- 顧客に［似ているが異なる症状］が表示される。
- 管理者またはサポート担当者の対応が必要である。

この短い区別があれば、正しい手順を別の問題に使ってしまうことを防げます。

テストデータで解決方法を再現する

安全なテストアカウントは、顧客情報を守り、スクリーンショットを再利用しやすくします。顧客の開始状態を、サンプルの名前やファイルで再現し、通知を無効にします。

撮影前に、解決方法を一度実行します。サインイン、特定のWorkspaceを開く、管理者へアクセス権を依頼するなど、顧客が先に済ませる条件を記録してください。

解決方法によってデータや権限が変わる場合は、テスト後に元へ戻す手順も用意します。状態を再現するたびに実際の顧客アカウントを使う資料にしてはいけません。

判断箇所とチェックポイントを撮影する

サポート用スクリーンショットは、顧客が迷いやすい場所で不確かさを減らすために使います。見つけにくい操作、選ぶべき値、分岐条件、重要な警告、最後の確認状態を撮影してください。

顧客の判断や確認に役立たない画面は省きます。すべての遷移を撮ると、解決手順が安全になるわけではなく、かえって読み進めにくくなります。

Action Captureなら、クリックしながらテスト済みの流れを記録できます。後から順序を確認し、偶発的なクリックを除き、各判断または必須操作につき1ページを残します。撮影全体の流れは、Macでクリックからステップ形式の手順書を作る方法をご覧ください。

顧客の次の操作を中心に各ステップを書く

各ステップには、操作、対象のコントロールまたは値、先へ進んでよいと分かる結果を記載します。作業しながら読みやすいように、背景説明より先に指示を書いてください。

例：

システム設定 > プライバシーとセキュリティ > 画面収録とシステムオーディオを開き、Shotomaticを有効にします。macOSからアプリを開き直すよう求められたら、終了して再度開くを選びます。

顧客の画面に同じ言葉が表示されない社内用語は避けます。サポート側で「キャプチャのエンタイトルメント」と呼んでいても、画面に「画面収録」と表示されるなら、そのラベルを使います。

明確な成功確認を加える

成功確認で、手順を完結させます。いま表示されるはずのもの、使えるはずの操作、作成されるはずのファイルを伝えてください。

目で確かめられる内容にします。「問題は解決したはずです」では判断できません。「Shotomaticに戻り、ウインドウのプレビューが表示されることを確認する」なら、具体的に確認できます。

反映に時間がかかる場合は、待ち時間と進行中を示す状態を記載します。システムの応答が遅れることを説明していないために、顧客がガイド全体を繰り返すことがないようにします。

エスカレーション条件と必要情報を加える

標準の方法で直らない場合、エスカレーション情報があれば不要な往復を減らせます。いつ止め、何を集め、どこへ送るかを明記します。

短い引き継ぎチェックリストです。

• 最初に記載どおりにならなかったステップ
• その画面のスクリーンショット
• 正確なエラーメッセージ
• アプリとmacOSのバージョン
• 関係する権限またはアカウントの状態
• 毎回起きるかどうか
• すでに試した手順

証拠を添付する前に、非公開情報を削除またはぼかしてください。エンジニアリング上の不具合なら、顧客に原因を診断させるのではなく、構造化されたバグ報告へ引き継ぎます。

背景を知らない読者に試してもらう

問い合わせを見ていない読者に試してもらうと、元のサポート担当者が記憶で補っていた背景が見つかります。ガイドを渡し、記載した開始条件から進めてもらってください。

読者が適用条件を見分け、外部の説明なしに解決手順を完了し、最終状態を確認でき、失敗時に正しい情報を集められれば、ガイドは公開できます。製品バージョンとガイド担当者を記録し、UI変更後にサポートチームが見直せるようにします。

クリックからサポートの流れを集め、順番どおりのガイドに編集する場合はAction Captureを使います。顧客自身での解決ではなく、エンジニアが再現するための情報が必要なら、Macでバグをステップ形式のスクリーンショットに記録する方法をご覧ください。