このシリーズに含まれる記事
ナレッジベースに含める記事を計画する際に、推測は必要はありません。書くべき記事を判断するのに役立つ既存のリソースがたくさんあります。たとえば、過去のサポートリクエストを見て、カスタマーからの問い合わせが多いものや、トラブルの頻度が高いものを見つけることができます。
この記事では、次のトピックについて説明します。
記事のアイデアを検索する
上にリンクした記事にもあるように、どんな記事を作る必要があるかを決める段階になったら、次のような4つの質問の答えを考えることが非常に役立ちます。
- よく問題になることは何ですか?
- 「どのユーザーもXでよく苦労している。」
- よく尋ねられる質問は何ですか?
- 「Yに関して頻繁に問い合わせがある。」
- 多数のカスタマーに影響を与える既知の問題は何ですか?
- 「貴社のWebサイトは、モバイルデバイスで正しく機能しません。」
- 最も時間のかかる問題は何ですか?
- 「Zのセットアップに30分かかる。」
これらの質問に答えるために、すでにカスタマーをサポートした経験があり、データがある場合には、以下のようなリソースを用意しておく必要があります。
既存のチケットデータ |
既存のチケットは、一般的なサポート問題やカスタマーが陥っている問題について、多くのことを教えてくれます。未解決のチケットと解決済みのチケットを確認してみると、ナレッジベースの記事にできるよくあるサポートの問題を見つかることがあります。 Guide Enterpriseでは、この貴重な情報を自動的に生成させることができます。詳しくは「提案されたサポートトピックをコンテンツキューで確認する方法」を参照してください。 |
Aboutカスタムフィールド |
チケットデータを効率的に分類して分析するには、カスタムチケットフィールドを使用すると便利です。エージェント向けのカスタムチケットフィールドとしてよく使われるのが、「About」フィールドです。 Aboutカスタムフィールド(「「About」フィールド」を参照)を作成すると、受信したサポートリクエストを仕分けうるのに役立ちます。Aboutフィールドでは、エージェントが、提供する製品やサービスのさまざまなカテゴリをドロップダウンリストから選択できるようになっています(たとえば、「支払いに関する問題」、「返品」、「製品の欠陥」など)。ビジネスや組織に関連するものであれば、何でもこのリストに含められます。 これらのデータを収集した後、レポートを作成して分析すると、作成すべきコンテンツを決定することができます。たとえば、返品に関するチケットが多い場合は、カスタマーが必要とする情報を提供するために、そのトピックに関するナレッジベース記事を作成する必要があることを示しています。 詳細については、「チケットデータを分析してカスタマーの問題を調べる」を参照してください。 |
Resolutionカスタムフィールド |
Aboutフィールドと同様に、サポート課題の解決策を取得するカスタムフィールドをチケットに追加することができます。たとえば、「ユーザー教育」や「ドキュメントの修正」などの解決策の値を持つドロップダウンリストを作成することができます。「ユーザー教育」は、サポートエージェントが、おそらくナレッジベースの記事にあるべき指示をユーザーに提供する必要があることを示します。「ドキュメントの修正」は、既存のナレッジベースの記事が間違っており、更新する必要があることを示します。 詳細については、「「Resolution」フィールドの使用」を参照してください。 |
既存の社内資料 |
記事のアイデアを得るために社内資料を参考にします。たとえば、一般的なサポート問題についてサポートチームが既に社内資料を作成していたり、製品仕様書を利用して製品の使用方法に関する記事を作成できるかもしれません。 コンテンツのアイデアを探すための社内資料の使用については、「他の情報源を参照して、カスタマーの問題を調べる」を参照してください。 |
サポートマクロ | サポートチームが一般的なサポート問題に迅速に対応するためにマクロを使用している場合、それらはナレッジベース記事の優れたアイデアの源となります(たとえば、返金要求の方法を説明するマクロなど)。標準の手順で簡単に解決でき、すべてのユーザーに適用されるこの種の問題は、ナレッジベースに文書化する必要があります。 |
よく使用されるタグ |
チケットタグは、チケットを分類したり、共通のサポート問題を見つけたりするのにも役立ちます。Aboutフィールドと同様に、タグを使用してチケットに詳細情報を追加することができ、サポートが必要な特定の領域を掘り下げるのに役立ちます。 チケットタグの一般的な使用法は、問題がカスタマー向け文書の作成の必要があることを示すことです。たとえば、エージェントが文書化を必要とする問題を発見した場合、「doc-needed」タグを追加するのが標準的なやり方です。 |
ワンタッチチケットとツータッチチケット |
ワンタッチチケットやツータッチチケットは、コンテンツのアイデアを探すのに適した場所です。なぜなら、これらのチケットは、解決が容易でセルフサービスに適したサポート問題を示していることが多いからです。たとえば、「パスワードをリセットするにはどうしたらいいですか?」というような内容です。このような問題は、サポートエージェントが対応する必要はなく、カスタマー自身で対処できることなのですが、そのことに気づいていなかったり、やり方がわからなかったりするのです。 このようなサポート問題は、通常、サポートエージェントが1回の応答で対応します(ワンタッチチケット)。Zendesk Supportを使えば、ワンタッチで解決したサポートリクエストを簡単に見つけることができます。 Zendesk Exploreでワンタッチとツータッチのチケットをレポートする方法については、「Exploreレシピ:ワンタッチチケット」を参照してください。 |
Googleアナリティクス |
Googleアナリティクスでは、カスタマーがWebサイトにアクセスした際に使用した検索語句を追跡することができます。ヘルプセンターでは、Googleアナリティクスを有効にすることができ、また有効にする必要があります(「Googleアナリティクスとヘルプセンター - パート1:適切な答えを得るための質問を参照)。 まだヘルプセンターを開設していない場合は、Googleアナリティクスで提供される検索語句のメトリックをチェックして、カスタマーがWebサイトで何を探しているかを確認してください。多くのカスタマーが特定の問題に関する情報を探していることに気づくかもしれません(たとえば、「配送に関する問題」や「ログインできない」など)。また、カスタマーがどのような検索語句で検索を行っているか、つまり、探している情報を見つけるために使用している語句が他にないか調べることもできます。詳しくは「Googleアナリティクスとヘルプセンター - パート2:検索の有効性の測定」を参照してください。 作成すべき記事が見つかるだけでなく、これらの検索絞り込みを記事のラベルとして使用することで、別の検索語が使用された場合にヘルプセンターの検索で記事が返されるようにすることもできます。たとえば、製品の名前を変更した場合、古い名前をラベルとして使用し、ユーザーが必要な記事を見つけやすくすることができます。詳しくは「ヘルプセンター記事でのラベルの使用」を参照してください。 ヘルプセンターを立ち上げた後、Supportのレポートの検索ダッシュボードを使用して、カスタマーが使用している検索用語を確認することができます(「ランキング上位のコンテンツ、検索、エージェントを表示する」を参照)。 |
特定分野の専門家(SME)とコミュニティ |
カスタマーに直接対応している人たちは、ナレッジベースに何を記載すべきかについて、何らかの意見やアドバイスがあるはずです。サポートエージェントや製品開発に携わっている人たちにアイデアを聞いてみましょう。 また、Zendesk Gatherのような活発なユーザーコミュニティや、ユーザーからのフィードバックを受け付けるフォーラムがある場合は、ユーザーにフィードバックを求めることもできますし、コミュニティへの投稿やコメントを通じてユーザー同士ですでに共有している内容を確認することもできます。さらに、ソーシャルメディアのチャネルも調べてみる必要があります。 |
作成が必要な記事のリストを作成する
これらの調査を行っている間に、記事のアイデアやニーズをどこか(Googleドキュメントや社内Wikiなど)にリストアップしておきましょう。また、直接Guideで記事のスタブを作成し、ライターに割り当てて記事を完成させる方法もあります。
このシリーズの次の記事(セルフサービスを提供するには - パート4:ナレッジベース記事の作成)では、執筆を完了させるための計画を作成し、ナレッジベース記事を公開するためのベストプラクティスを紹介します。
執筆作業を分担する
チームでナレッジベースの記事を作成している場合は、まず作業を分担し、特定の人に特定の記事を割り振ることから始めましょう。
扱うべきトピックを発見するために行った調査に基づいて、執筆が必要な記事のリストを作成しているはずです(具体的な記事のタイトルを定義するレベルにまで達していない場合は、対象分野の包括的なリストから始めるのがよいでしょう)。
細部は決まっていなくても、この時点では何を書くべきかがわかっているはずです。そのリストをチームで共有し、チームメンバーに特定の部分を割り当てます。誰がどの部分を担当するかは、誰がその分野の専門知識を持っているかによって決まります。