ソフトウェア製品をお持ちですか?無料で追加できます。担当者が確認し、1日以内に公開します。製品をお持ちですか?無料で追加できます。

製品を追加する
製品を追加する

ドキュメントとナレッジベース

必要なときにちゃんと見つかるドキュメント。

ドキュメントとナレッジベース

このカテゴリにはまだ製品がありません

今のところ何も掲載されていません。この棚に合う製品をお持ちでしたら、追加してください。担当者が目を通します。

製品を追加する

このカテゴリの対象

ほかの人が見つけられるように、物事を書き留める場所です。顧客向けのヘルプセンター、社内ハンドブック、開発者向けドキュメント、そしてそのどれにも役立つ検索機能が含まれます。

重要な区別は、読者です。顧客向けのドキュメントには、公開アドレス、レビューのプロセス、すでに行き詰まっている人のために書かれた言葉が必要です。社員向けのドキュメントは、もっと雑でも構わず、代わりに権限が必要です。

個人や小さなチームの知識は、ノートとWikiに入ります。答えのない質問が届くチケットのキューは、カスタマーサポートです。

構造が、何かが見つかるかどうかを決める

ドキュメントのプロジェクトは、どれも整理された状態で始まり、山積みで終わります。ツールは、それを遅らせるか、早めるかのどちらかです。

階層の仕組みを見てください。カテゴリ、サブページ、相互リンク、そして1つのページを、複製せずに2か所に置けるか。次に、300ページになったときに何が起きるかを見ます。30ページ用に設計されたナビゲーションは、そこで崩れるからです。

検索は、正直なテストです。社内用語ではなく、顧客が使う言葉でクエリを試してください。タイトルしか照合しない製品は、このテストに落ち、読者は代わりにサポートのキューにたどり着きます。

タグや関連記事の提案は、維持されていれば役に立ちます。それを手作業で長く維持する人はいないので、内容から関連付けを生成する製品を選んでください。

書くこと、レビュー、ページを正しく保つこと

ドキュメントは、静かに腐ります。3月には正しかったページが、9月にはサポートチケットになり、そのページに間違って見えるところは何もありません。

役に立つ製品には、担当者、レビュー日、読者に見える最終確認日が備わっています。書く人が3人以上になったら、下書きの状態とレビューのワークフローが重要になり、ページが変更前に何と書いてあったかを誰かが尋ねる最初のときに、バージョン履歴が重要になります。

再利用も確認する価値があります。制限、価格、対応バージョンの一覧は、一度だけ書いて、登場するすべての場所に含めるべきです。11ページに貼り付けて、来四半期には食い違っている、という状態は避けてください。

公開と検索の問題

公開のヘルプセンターはウェブサイトであり、そのように振る舞うべきです。

  • 再編成しても生き残るきれいなURL。生き残れない場合はリダイレクトで。
  • 最初の1行から生成されるのではなく、記事ごとに編集できるタイトルと説明文。
  • テキストが表示される前に、重いアプリケーションが読み込まれることのない高速なページ。
  • 誰も覚えていないスケジュールではなく、公開時に更新されるサイトマップ。
  • 提供企業ではなく自社サイトの評価を高める独自ドメイン。

最後の点は、社内で主張する価値があります。ドキュメントは、ソフトウェア企業が持つ最も成果の出るコンテンツであることが多く、提供企業のサブドメインに置くと、そのトラフィックを手放すことになります。

測定と、唯一重要な指標

ページビューから分かることは、ほとんどありません。分かるのは、2つの数字です。

1つ目は、役に立つ結果が返らなかった検索で、これは次に作るものの書き出されたリストです。2つ目は、記事を開いた読者が、その後もサポートに連絡したかどうかで、これにはヘルプセンターをチケットシステムに結び付ける必要があります。

意見ではなく、そのリストから書き直してください。最も頻繁に失敗する5本の記事は、誰も訪れない50本よりも注目に値します。

これらの製品の料金

執筆者の席数が基本で、全員が無料で読める場合も、登録した社内の読者ごとに課金される場合もあります。公開ヘルプセンターは通常、執筆者数と記事数で、社内Wikiはユーザー数で課金します。

3つの境目に注意してください。独自ドメイン、バージョン管理、シングルサインオンは、それぞれエントリープランの一つ上の階層にあることが多いです。分析機能の深さが4つ目です。ヘルプセンターをサポート製品と組み合わせる提供企業は、含めるのではなくアドオンとして値付けすることが多く、これも料金ページが隠していることにまとめた習慣の1つです。

決める前に、すべてを書き出して、出力を読んでください。Markdownやきれいなマークアップなら、離れられます。独自形式なら、アーカイブは人質です。

ゼロからヘルプセンターを始める

最初のバージョンは、恥ずかしいほど小さくて構いません。

サポートのキューに最も多く届く質問を20件選び、きちんと答えてください。それで問い合わせの大半をカバーでき、1週間で終わります。一方、完全な構造を先に計画すると、四半期かかり、その間は何にも答えません。

どの記事も、すでに行き詰まっている人のために書き、答えを先に、説明をあとに置きます。スクリーンショットは古くなりやすいので、本当に役立つ場所に使い、差し替えることを前提にしてください。

そのうえで、構造が自然に現れるのを待ちます。30本の記事が揃えば、カテゴリは明らかになります。5本目の段階で押し付けても、どのみち再編成することになります。

何も結果が出なかった検索語は、執筆の待ち行列として公開してください。このカテゴリの中で、尽きることがなく、外れることもない、唯一のコンテンツ計画です。

よくある質問

ナレッジベースとWikiは何が違いますか?

ナレッジベースは、答えを必要とする読者のために書かれ、その人のために構造と検索が設計されています。Wikiは、寄稿者のために書かれ、自然に育ちます。どちらもいつの間にか相手に近づくので、メンテナンスのルールが重要になります。

ドキュメントは、メモと同じツールに置くべきですか?

読者が重なる場合だけです。社内のメモは、乱れていても許されます。顧客向けのドキュメントには、バージョン管理、レビュー、公開URLが必要で、両者を混ぜると、たいてい後者が劣化します。

ドキュメントが古くなるのを防ぐには、どうすればいいですか?

すべてのページに担当者とレビュー日を設け、最終確認日を読者に見せてください。何も結果が出なかった検索の分析がもう半分で、次に書くべきものが分かります。

公開ナレッジベースは、サポートの件数を減らしますか?

記事が、人々が実際に送ってくる質問に答えていれば、測定可能な形で減らします。推測に頼らず、自己解決の数字をヘルプデスクに結び付け、最も頻繁に失敗する5本の記事を書き直してください。

製品のリリースごとに、ドキュメントのバージョンを分けられますか?

開発者向けのプラットフォームでは可能で、顧客が古いバージョンを使っているときに重要です。一般的なナレッジベース製品は、履歴付きで公開中のバージョンを1つだけ提供するのが普通で、自動更新されるソフトウェアならそれで十分です。