問い合わせ通話には、顧客が迷う表現、繰り返される質問、説明が伝わらない箇所が含まれています。ただ文字起こしを保存するだけではナレッジになりません。個別の会話から再利用できる知識を抽出し、根拠・責任者・更新日を付ける必要があります。

ナレッジ化の全体像

目的設定 → 対象通話の選定 → 安全な文字起こし → 匿名化
→ 問い合わせ分類 → FAQ・応対例の下書き → 担当部署確認
→ 公開 → 利用状況と再入電率で見直し

最初から全件処理せず、特定の商品や問い合わせ種別で小さく始めます。

1. 何を改善するか決める

目的によって抽出項目が変わります。

目的選ぶ通話見る指標
FAQ改善同じ質問が多い通話問い合わせ件数、自己解決率
応対時間短縮長時間化した通話平均処理時間、保留時間
一次解決率向上再入電があった通話再入電率、転送率
教育良い応対・難しい応対評価項目、研修後の改善
商品改善不具合・要望を含む通話発生件数、影響度

目的が曖昧だと、大量の文字起こしだけが残ります。

2. 対象通話を偏りなく選ぶ

担当者が選んだ「良い事例」だけでは実態を捉えられません。問い合わせ種別、曜日、時間帯、担当者、解決・未解決、再入電あり・なしを分け、一定数を抽出します。

苦情や個人情報を多く含む通話は、閲覧権限と処理方法を別にします。録音の利用目的が分析まで含まれているか、顧客への案内と社内規程を確認します。

3. 文字起こし前に安全を確認する

  • 承認されたサービスか
  • データの保存場所と保持期間
  • モデル学習への利用設定
  • 管理者・分析者のアクセス権
  • 電話番号、住所、決済情報などの除去方法
  • データを書き出し・削除できるか

高リスク情報は必要最小限にし、匿名化後のデータを分析用に分けます。

4. 問い合わせを構造化する

1件ずつ次の項目へ整理します。

  • 顧客の目的
  • 最初の質問
  • 背景・利用状況
  • 原因または該当ルール
  • 案内した手順
  • 解決したか
  • 再入電の有無
  • 顧客が理解しにくかった表現
  • 商品・業務改善の候補

AIで抽出する場合は、会話にない原因を推測させず、「不明」「要確認」を残します。

5. FAQへ変換する

質問は顧客の言葉へ近づける

社内用語ではなく、検索される表現を使います。1つのFAQへ複数の論点を詰め込まず、条件が違う場合は分けます。

回答には適用条件を書く

対象商品、契約プラン、期間、例外、必要な本人確認を明記します。料金や仕様など変わりやすい情報には確認日を付けます。

根拠と責任者を付ける

公開回答には、社内規程、公式仕様、担当部署の承認を紐づけます。通話中の担当者の説明だけを正解として採用しません。

6. 応対改善へつなげる

通話の冒頭で質問を正しく把握できているか、保留前に理由を説明したか、次の行動を明確にしたかを確認します。良い応対例も、表現を丸暗記させるのではなく、意図と判断基準を教材にします。

カスタマーサポートのAI活用では、要約、返信案、VOC整理を含む実務フローを解説しています。

7. 公開後に更新する

  • FAQが閲覧された回数
  • FAQ閲覧後の問い合わせ率
  • 同じ内容の再入電率
  • 平均処理時間
  • オペレーターからの修正提案
  • 商品・規約変更後の未更新件数

公開して終わりではなく、責任者と次回確認日を設定します。古い回答は検索結果に残ると誤案内につながるため、廃止・転送方法も決めます。

導入時のチェックリスト

  • 分析目的と対象範囲を文書化した
  • 録音・分析に関する案内と社内承認を確認した
  • 個人情報・機密情報の処理方法を決めた
  • AI出力を担当部署が確認する
  • FAQに根拠・責任者・更新日を付ける
  • 元音声と分析データの保存期限を分けた
  • 効果指標を導入前から測った

業種や情報の機密度に合う録音・文字起こし手段を整理するには、業種別AIレコーダー商品診断も利用できます。診断結果は候補整理であり、社内要件と最新仕様で確定してください。

まとめ

問い合わせ通話のナレッジ化は、文字起こしではなく、匿名化、分類、根拠確認、公開、更新までを一つの工程として設計します。AIには分類と下書きを任せ、正確性・公開範囲・例外条件は担当者が確認してください。

録音データの保存・削除ルールも運用設計に役立ちます。