ナレッジベース（KB）のコンテンツを作成する場合、作成プロセスの管理にはさまざまな方法があります。チームの規模やビジネスの種類、作成しているコンテンツが非公開のものか、一般に公開するものかによって、作成プロセスが変わることがあります。
ここに挙げたベストプラクティスは、Zendeskのユーザーからのフィードバックを基にしたガイダンスを提供し、実用的なナレッジベースの構築に役立つものとなっています。
ナレッジベースのオーナーの明確化
ナレッジベースのオーナーが誰なのかを、必ず明確にしておきます。専任であるか、ほかの業務との兼任であるのかを問わず、チームには1人、ナレッジベースの担当者が必要です。オーナーはチームの窓口であり、オーナーの存在によって、コンテンツの作成と維持が確実に行われます。
ナレッジベースのオーナーは、ナレッジベースの文書化を必要とする問題のリストを定期的に調べ、チェックする必要があります。この作業を行えば、新しいコンテンツをタイムリーに作成でき、既存のコンテンツも最新の状態に維持されます。チームでの確認の方法にもよりますが、ナレッジベースの問題を素早く把握するには、Zendeskのビューを利用するとよいでしょう。調査、チェックの作業の後に、ナレッジベースのオーナーは、必要に応じて、コンテンツに関する優先順位やスケジュールの設定、コンテンツの割り当てを行います。
ナレッジベースのオーナーを決めておくと、サポートのコンテンツの水準を一定に満たし、コンテンツの内容を矛盾のない完全なものにするうえでも、大いに役立ちます。
ナレッジベースを必要とする問題にフラグを付けるプロセスを確立する
サポートエージェントは、カスタマーと密接にやりとりしており、カスタマーの問題を理解しています。ですので、ナレッジベースを必要とする問題を特定することは、サポート対応の一環としての標準作業となります。新たに文書化したり、既存のドキュメントの更新を必要とする問題にエージェントがフラグを付けるプロセスを準備しましょう。
Zendeskのサポートチームでは、特殊なタグを使って、ナレッジベースを必要とする問題を含むチケットにフラグを付けています。別の方法として、チケットにカスタムフィールドを追加し、ナレッジベースの更新について必要性の有り無しをエージェントが選択できるようにしているお客様もいらしゃいます。
コミュニティのヒント（ViewPath!のCheryl）私の最終目標とするのは次のような手順です。（1）ティア1、ティア2のエージェントがトピックの候補をテクニカルライターに示します。（2）テクニカルライターがドキュメントを執筆します。（3）ドキュメントを（想定では）ティア2のエージェントに渡して内容を見直し、適切なトピックが網羅されていることを確認します。
エージェントは常に既存のドキュメントを検索して特定し、同じ問題を扱う複数のバージョンが作成されないようにします。すでにコンテンツが存在する場合には、エージェントがその内容をチェックして更新や修正が必要であるかを判断し、必要な場合は、そのドキュメントにフラグを付けます。しばらくして、このプロセスが標準のサポートプロセスになると、エージェントはコンテンツのニーズを、要求に応じて自然に特定できるようになります。
可能であれば、さらに一歩踏み込んで、コンテンツの作成とメンテナンスをサポートのワークフローに組み込みます。たとえば、カスタマー対応を行ったエージェントには、作業の後に時間を取ってもらうようにします。この時間を使って、作業時の記憶が鮮明なうちにエージェントはすぐにナレッジベースの内容を更新します。あるいは問題の大きなものからひとまず更新作業に着手します。これが不可能な場合でも、必要であることが少なくともチケットには記録されているので、別のプロセスでチームがナレッジベースを更新できる可能性があります。
ナレッジベースのコンテンツの執筆者の決定
ナレッジベースのコンテンツの執筆者を指定しないと、だれもコンテンツを執筆しないといった状況になるおそれもあります。ナレッジベースのコンテンツの作成に一定の優先順位を与え、作成の作業を、特定の担当者やグループの通常業務の一部にする必要があります。
チームによっては、テクニカルライターやサポートチームのメンバーをコンテンツの執筆者に指定しているところもあります。また、技術的な専門家がコンテンツを作成しているチームもあれば、サポートエージェントにコンテンツの作成を頼っているチームもあります。エージェントがコンテンツの作成を担当している場合には、その作業をエージェントの業務フローの一部にします。各エージェントで執筆の作業を持ち回る方法を試してもよいでしょう。
コミュニティのヒント（Todd Zabel!）小規模のサポートチーム（5名）であるため、全員で複数の業務を兼務しています。スタイルガイドと分類法の作成を完了し、専門分野の経験に応じて、チームの特定のメンバーに執筆プロジェクトを割り当てています。そして、毎月、各記事を分担してレビューを行っています。チームの各メンバーは、スプレッドシートに記載されたすべての記事の中からをそれぞれ1/5づつを選択して分担します。この方式により、それぞれの記事は最新かつスタイルガイドに順守したものとなり、記事の間での重複もなくなり、良質のマルチメディアコンテンツを記事に載せることも可能です。また、ソーシャルチャネルとの連携も実現した結果、コンテンツの認知度を最高のレベルにまで高めることができました。
ナレッジベースの執筆者は「ライター」である必要はありません。ただし、ナレッジベースの更新は、必ずいずれかのメンバーの通常業務に含めてください。
質の高いナレッジベースのコンテンツを執筆するための基準の設定
サポートエージェントやテクニカルライターなど、コンテンツの執筆者が誰であるかにかかわらず、記事の内容がわかりやすく正確で矛盾のないことが重要になります。ナレッジベースで簡単に答が見つからないと、ユーザーはイライラしてチケットを送信するかもしれません。
以下では、ユーザーが簡単に検索、使用できるナレッジベースのコンテンツを作成するための一般的なヒントを示します。
-
記事のテンプレートを作成する。テンプレートを活用すると、コンテンツをすばやく簡単に作成することができます。いちから作成するのは手間がかかります。指定した各セクションに情報を入力する形式のテンプレートを作成すれば、執筆者は余計な情報は省き、必要な情報だけを記事にすることができます。テンプレートにより記事の一貫性が保たれ、ユーザーが記事の内容を予想できるようにもなります。
コミュニティのヒント（Kirk!）コアとなる2つのテンプレートがあります。その1つは「PERC」です。これは、課題と質問、回答、FAQの概要を「問題」（Problem）、「環境」（Environment）、「解決策」（Resolution）、「原因」（Cause）から捉えたものです。箇条書きのリスト形式になっており、数字と文字で順を追って指示が書かれています。もう1つのテンプレートは、記事の方向性と記事のチェックに関するものです。各記事ごとに、中心となる問題1つに対して、解決策を簡潔に1つ記述します。
Kirkのお勧めの内容の詳細や、その他のユーザーからのヒントについては、フォーラムの「Do you use a "template" to author your KB docs（ナレッジベースのドキュメントの作成での「テンプレート」の使用）」でコミュニティの議論を参照してください。
-
記事はなるべく簡潔に、コンテンツはセクションごとに分ける。ユーザーが記事全体にすばやく目を通し、必要な情報が記事に記載されているかどうかをすぐに判断できるよう、記事は短くします。1つの記事に情報を大量に盛り込んで、ユーザーをうんざりさせてはなりません。長めの記事については必ず、コンテンツをセクションごとに分割し、各セクションに明解な見出しをつけてください。
Zendeskでは最近、「ユーザー」に関する長文の記事を分割しました。 具体的には、アカウントオーナーの変更方法を見つけ出すのに、カスタマーが苦労しているといった状況がありました。この情報は長文の記事の中に記載されており、検索でこの記事を見つけだしても、記事のどこに必要な情報が埋まっているのかわからない状態でした。この長文の記事を短文のトピックに分割した結果、問題は解決されました。
-
記事のタイトルは内容に即したわかりやすいものにする。ユーザーは何かの目的を達成しようとしているときに、サポート情報の記事を検索する傾向があります。記事のタイトルは、その記事から得られる情報や、その記事で扱う課題をわかりやすく伝えるものにします。あいまいなタイトルや一般的なタイトルでは、必要とする内容を扱った記事であるかどうかをユーザーが判断しづらくなります。
-
箇条書きリストと番号付きリストを使用する。リスト項目や手順の記述は、箇条書きリストと番号付きリストに分割することで、ひとめで概要を捉えたり、内容を理解しやすくなります。内容にふさわしい種類のリストを選びます。箇条書きは、手順を含まないリストに、番号付きは、順番通りに実行する必要のある手順リストに使用します。
-
用語や専門用語を定義する。記事の中でそれぞれの用語を定義するか、製品やビジネスの重要な用語を定義する、用語集などのリソースを示すようにします。
新しい概念については、その概念を説明している記事へのリンクも検討します。その概念の説明を必要としていないユーザーの場合は、長い説明は不要です。一方、説明を必要としているユーザーには、繰り返し利用可能なコンテンツで、詳細な情報を伝えてください。
-
記事をリンクして記事の関連性を示す。関連する記事は必ずリンクします。これによって、ユーザーは、問題の解決に必要なすべての情報を検索できるようになります。また、記事をリンクすれば、自分には答のない質問についても、ユーザーに回答を提供することができます。メモ：Zendeskでは、記事のタイトルを変更したり削除したりする場合に、リンクを更新する必要はありません。このような変更を行っても、記事のIDは維持されるため、リンクが無効になることはありません。
コンテンツの公開前に必要なテクニカルレビュー
企業のナレッジベースは信頼できると、ユーザーは信じています。しかし、もしもエラーや不整合があまりに多く発見されたとしたら、情報に対するユーザーの信頼は失われ、ナレッジベースは利用されなくなってしまいます。それゆえ、公開前にコンテンツを確認しておくことが重要です。
ナレッジベースの記事の執筆者は専門家とスケジュールを調整して、記事の内容が正確かつ完全であるかを確認してもらう必要があります。トピックの内容が複雑な場合には、何度も見直ししたり、複数の専門家による確認が必要になることもあります。
Suite Growth、Suite Professional、およびGuide Professionalでは、KBで新しい記事を公開する準備ができるまで、下書きモードで作業したり、他のユーザーに下書きをレビューしてもらうことができます「ナレッジベースでの下書きの取扱い」を参照してください。
Suite EnterpiseプランとGuide Enterpriseでは、チームパブリッシングを使用して新規のコンテンツや既存のコンテンツを簡単にレビューすることができます。新しい記事を進行中の作業として作成し、レビュー用に送信することも（「新しいコンテンツを作成してレビューステータスに移行する方法」を参照）、既存の記事の更新をステージングしてレビューしてから公開することもできます。詳細については、「レビュー用に既存の記事のコンテンツ更新をステージングする方法」を参照してください。
最終レビューを行う担当者、すなわち公開の責任者についても考慮しておくとよいでしょう。公開の権限をチームの特定のメンバーに限定しておくことで（「ナレッジベースの記事にエージェントの編集権限と公開権限を設定する方法」を参照）、ナレッジベースのすべてのコンテンツの公開前のレビューと承認をそのメンバーに行ってもらうようにできます。Suite Growth、Suite Professional、およびGuide Professionalでは、公開者がすべての下書きのレビューおよび公開を行うことができます。Enterpriseプランでは、公開者はレビューに送信された記事をレビューし、承認して公開することができます。「チームパブリッシングを使用した記事のレビュー、承認、公開」を参照してください。