- 目的別のおすすめ構成（結論）
- まずは標準（Service Portal ＋ Knowledge Management）で開始
- 申請とFAQを一体化したいなら（Service Portal ＋ Service Catalog ＋ Knowledge）
- 問い合わせ削減を強めるなら（Virtual Agent ＋ Knowledge ＋ Portal）
- 複数部門・多言語・公開範囲が複雑なら（Knowledge Base分割 ＋ 厳密なアクセス制御）
- 基本アーキテクチャ（標準）
- 体験面
- Service Portal（ポータル）にナレッジ検索・カテゴリ閲覧・関連記事・フィードバックを配置
- データ面
- Knowledge Base（KB）＋ Category（分類）＋ Knowledge Article（記事）
- 運用面
- 承認・レビュー・版管理・期限（有効期限）・廃止をワークフローで回す
- 推奨データ設計
- Knowledge Base（KB）
- 対象ごとに分割（例：ITヘルプ、業務手順、人事、全社FAQ）
- 公開範囲が違うものはKBを分ける（後から揉めやすい）
- Category（分類）
- 3階層以内を目安（深すぎると運用が破綻）
- 「組織」ではなく「利用者の探し方」で切る（例：アカウント、PC、ネットワーク、申請、トラブル）
- Article（記事）
- 記事タイプを絞る（FAQ、手順、既知障害、ポリシー）
- 必須項目（タイトル、要約、対象者、前提、手順、関連リンク、最終更新日）
- タグ（任意）で横串（製品名、拠点、システム名）
- アクセス制御（重要）
- 方式
- ユーザ条件（ロール／グループ／部門）で閲覧制御
- 内部向けと外部向けは原則分離（KBまたは公開設定で分ける）
- ルール
- 「全社員に見せて良い」記事は専用KBに集約
- 機密・限定手順はKB分割＋最小権限
- ポータル（Service Portal）での見せ方パターン
- トップ
- グローバル検索（ナレッジ優先）＋人気記事＋最近更新＋カテゴリ入口
- 一覧
- カテゴリ別リスト＋絞り込み（タグ、対象者、更新日）
- 詳細
- 記事本文＋関連記事＋評価（役に立った/立たない）＋コメント（任意）＋「この内容で解決しない場合の導線」（インシデント/要求）
- 検索改善
- 同義語（略称・製品名揺れ）対応
- 検索結果に「最適な記事タイプ（FAQ/手順）」を優先表示
- 運用プロセス（最低限これだけ）
- 作成
- インシデント解決時に「記事化」する導線（テンプレで即作成）
- レビュー
- 所有者（オーナー）＋定期レビュー（例：90日/180日）
- 公開
- 承認フロー（部門責任者 or ナレッジ管理者）
- 保守
- 期限切れ前通知 → 更新/廃止
- 参照数・低評価記事の改善バックログ
- 役割設計（最小構成）
- ナレッジ管理者
- テンプレ・分類・品質基準・運用指標の管理
- 記事オーナー（部門担当）
- 内容の正確性・更新責任
- レビュアー（任意）
- 技術/業務観点の確認
- 品質向上の仕組み
- フィードバック
- 役に立った/立たない＋理由（選択式）を集計
- KPI
- 記事参照数、自己解決率（閲覧→問い合わせ削減）、低評価率、期限切れ件数
- 標準化
- テンプレ統一（見出し、手順書式、注意事項）
- 拡張構成（必要になったら追加）
- Virtual Agent
- FAQ/手順の対話誘導 → 解決できなければチケット起票
- ケース/インシデント連携
- チケット作成画面で関連記事推薦
- 解決コードと記事紐付け（ナレッジ蓄積を習慣化）
- 多言語
- KB分割または翻訳運用（記事の親子管理）
- よくある落とし穴（避ける）
- カテゴリを細かくしすぎて更新されない
- 公開範囲が曖昧で後から閲覧制御が崩れる
- 記事テンプレがバラバラで検索性が落ちる
- チケット解決と記事化が繋がっていない
- 最小の推奨初期構成（これで始める）
- KB 2〜4個（全社FAQ／IT／業務部門別 など）
- カテゴリ 20〜50程度（3階層以内）
- 記事テンプレ 3種類（FAQ、手順、既知障害）
- ポータル
- 検索＋カテゴリ＋人気/最新＋記事詳細（評価＋問い合わせ導線）
- 運用
- オーナー設定＋承認＋定期レビュー＋期限管理
ServiceNow調べちゃうさんが作成
/ 23 COBI