Heroicナレッジベースの分類を計画するには？30秒で答えが見つかります！

ナレッジベースを構築する際、どこに記事を置けばいいのかわからない？カテゴリーが少なすぎて、コンテンツが積み重なり、検索しても保存できない？カテゴリーが多すぎて、ユーザーが2回クリックしただけで迷子になり、編集者が自分で管理できない？英雄知識ベースその価値は、多くの場合、構造の明確さ、ユーザーを30秒で答えに到達させる能力、3ヶ月後にチームに最新情報を提供し続ける能力にかかっている。以下の計画アプローチは、2つの現実的な目標に焦点を当てている：リピート問い合わせの削減のみならず長期にわたって保守可能なコンテンツにする.

1.知識ベースの「境界」を定義することから始める

知識ベースとは、すべての情報を詰め込むことではない。より現実的なアプローチは、まず何を含めるべきかを定義することである。英雄知識ベース 3種類のコンテンツを担当するのに適している：

高周波問題同じような質問を何度も繰り返す
標準化プロセス固定ステップ、SOPとして記述可能な操作
ルールの説明ポリシー、制限、条件、時効、責任の境界線

ナレッジ・ベースに当てはまらないが、しばしば間違って詰め込まれてしまうコンテンツ：

往復の確認が必要なケースへの対応（注文の例外、住所変更など）
社内スタッフのみに有用な実施内容（社内承認プロセス、フォーム記入ルール）
頻繁に変更されるがメンテナンスされていない臨時アナウンス

境界線が明確であればあるほど、分類を安定させやすくなる。

2.分類システムの基本原則：「製品モジュール」ではなく「ユーザータスク」による分類

多くのナレッジベースで最も一般的な問題は、ユーザーが何を達成しようとしているのかよりも、バックエンドの機能から分類が始まっていることです。分類について考えるより堅実な方法は、「ユーザーは何を解決しようとしているのか」ということです。一般的なユーザーのタスクは、おそらく次のようなことに焦点をあてています：

使い始める(登録、ログイン、基本設定）
ご注文とお支払い(支払方法、不履行の理由、請求書など）
物流・受入(発送、追跡、署名、例外)
アフターセールス＆ルール(返品、保証、保証、時効）。
アカウントとセキュリティ(パスワード、認証、プライバシー）
障害解決(エラー、開けない、互換性、パフォーマンス)

あなたのビジネスがソフトウェアやサービスであれば、もっと多くなるだろう：

統合とセットアップ(API、プラグイン、サードパーティプラットフォーム)
パーミッションとコラボレーション(メンバーシップ、役割、アクセス制御）

このようなタスクベースの分類の利点は、ユーザーがシステムの構造を理解しなくても、そのシステムに直接たどり着くことができることです。

3.推奨されるティア構造：2ティアが主流、3ティアは慎重に使用される

英雄知識ベース階層は深すぎない方がいい。ほとんどのサイトでは、以下のようなコントロールを推奨している：

レベル1：分類（カテゴリー）
第2レベル：サブカテゴリーまたはトピック。
記事：最後の一滴

第3レイヤーが使えないわけではないが、ある条件を満たさなければならない：ユーザーパスを大幅に短縮そうでなければ、迷路を作っていることになる。

メンテナンスしやすいテンプレートは

はじめに
- アカウント設定
- はじめの一歩
ご注文とお支払い
- 支払いの問題
- 請求書
配送
- トラッキング
- 配送の問題
返品とポリシー
- 返却プロセス
- 保証
トラブルシューティング
- ウェブサイトのエラー
- アプリの問題

製品マニュアル」ではなく「ヘルプセンター」のようなものだとわかるだろう。

4.社内用語ではなく、ナビゲーションのようにカテゴリー名を付ける

カテゴリーのタイトルは、ユーザーにとって一目でわかるものでなければなりません。避けるようにしましょう：

社内の略語（SLA、RMA、CRM）
チームだけが理解できるプロジェクト名
抽象的すぎる言葉（「統合サービス」「その他の記述）

より推奨される命名規則：

「ロジスティクス」よりも「シッピング＆デリバリー」の方が明確だ。
"返品・返金 "は "アフターセールス "よりも直感的だ。
「よくあるエラーの修正」は「テクニカル・サポート」よりも方向性がある。

多言語のユーザーをターゲットにしている場合、英語のカテゴリーでは、最も一般的な単語を使用し、読解コストを削減するようにしてください。

5.記事配置のルール：見つからないことを減らすための「エントリーの一貫性

たとえカテゴライズが正しくても、同じ質問が異なる入り口として解釈される可能性があるため、ユーザーは見つけることができないかもしれない。

各記事の「メイン・エントリー」を特定し、クロスリンクで補足することが望ましい：

物流関連の記事の主な入り口は「配送と配達」に置かれている。
支払い失敗の記事への主な入り口は、"注文と支払い "にあります。
トラブルシューティング」が主な入り口だ。

その後、非常に短いプロンプトで記事のジャンプを行う：

"参照：支払い方法"
"関連：ご注文の追跡"

この方が、記事を複数のカテゴリーにコピーするよりも安定し、メンテナンスもしやすい。

6.ホームページ構成の推奨：まず検索、次に6～8項目のカテゴリー

英雄知識ベース検索してから選択する」ロジックを作るのに最高のホームページ：

上部の目立つ検索ボックス
6-8 コア・ソート・カード
その下には、人気記事と最新の更新情報が掲載されている。

その理由は簡単で、ほとんどのユーザーは「カタログを見る」ために来ているのではなく、特定の問題を解決するために来ているからだ。検索経路が短ければ短いほど、問い合わせ件数は少なくなる。

7.メンテナンス・メカニズム：一旦構造が定義されたら、継続的な反復が可能でなければならない。

知識ベース構造は一度に構築されるものではない。より現実的なアプローチは、メンテナンスの周期を設定することである：

月次レビュー：アクセス数は多いが直帰率の高い記事はどれか
週次補充：作業指示書に現れる新たな高頻度問題
各製品のアップデート後：関連文書の同期アップデート

メンテナンスの仕組みがなければ、ナレッジ・ベースは「時代遅れの情報センター」になってしまい、かえって問い合わせの数を増やすことになる。

はんけつをくだす

英雄知識ベースカテゴリー化とは、本質的に一つのことをすることである：ユーザーが最短経路で最も一般的なタスクを完了できるようにすることである。より安定した構造とは、通常「タスクベースの分類＋2階層アプローチ＋検索優先」である。カタログが明確で、ネーミングが直感的で、記事への入り口が一貫しており、メンテナンスが継続的であれば、ナレッジベースは単なる未使用ページのコレクションになるのではなく、繰り返し問い合わせを実際に減らすことができる。

お問い合わせ
チュートリアルが読めない？無料でお答えします！個人サイト、中小企業サイトのための無料ヘルプ！	カスタマーサービス WeChat
① 電話：020-2206-9892
② QQ咨询：1025174874
三 Eメール：info@361sale.com
④ 勤務時間: 月～金、9:30～18:30、祝日休み