技術問い合わせは、対応を終えた瞬間にメール箱へ消えていきがちです。
この状態だと、同じ質問が何度も来る／担当者が変わると知見が消える／不具合解析が遅くなる、といった損失が積み上がります。
ナレッジ化のポイントは「立派なFAQを作る」ことではなく、最低限の項目を揃えて“再現できる形”で残すことです。
ナレッジとして使えるかどうかは、再現性で決まります。
製造業の技術問い合わせテンプレ（型式・ロット・図番の取りこぼし防止）の考え方を、問い合わせ全般に展開すると事故が減ります。
「現象」と「原因」を混ぜると判断がブレます。
入力は“現象と条件”に寄せ、原因や対策は社内で追記する欄に分けるのが運用上強いです。
ナレッジが資産になるのは、回答が構造化されているときです。最低限、次の枠があると再利用しやすいです。
恒久対策が設計変更に繋がる場合は、ECOの版管理（トレーサビリティ設計）と繋ぐと、ナレッジが“履歴”として成立します。
分類は細かすぎると運用が破綻し、粗すぎると検索できません。
カテゴリ（固定）とタグ（柔軟）を分け、タグは改善に使える粒度にします。
タグをレポートに活かす考え方は タグを改善施策に活かす が参考になります。
同じ原因に対して、表現だけ違う問い合わせが増えます。
ここを束ねないと、ナレッジが散って検索性が落ちます。
方法は、問い合わせ（子）を原因レコード（親）に紐づけるのが実務的です。
この親レコードに、代表的な現象、再現条件の差分、対象範囲（どの版・どのロット）を集約します。
対象範囲は、品目マスタやBOM（基礎データ）と繋ぐと、影響範囲の判断が速くなります。
問い合わせの一次回答は、経験則だけだと属人化します。
評価・試験結果（あとから探せる形）にリンクできると、根拠が残り、社内外の説明責任が上がります。
試作・評価依頼（案件一覧で見える化）が起点なら、問い合わせ→評価→結果→恒久対策まで一本道にできます。
全問い合わせをナレッジ化すると運用が死にます。
以下の条件を満たすものだけを昇格させる、という基準が必要です。
権限と監査ログ（権限・ログ）を伴うため、最初に閲覧範囲を決めます。インテンスでも、ナレッジは“全公開”ではなく、部門別に運用できる設計に寄せます。
技術問い合わせを資産にするには、最低限の項目で“再現できる形”を作ることが第一です。
対象・版・ロット・現象・再現条件・添付を揃え、回答は一次回答／原因／恒久対策で構造化する。
タグは改善に使える粒度で、重複は束ね、評価結果や設変と紐づけるとナレッジとして回り始めます。