問い合わせ分析のAI活用12通を8案件へ整理し、
FAQと業務改善へつなぐ

問い合わせ件数は数えているのに、FAQを増やすべきか、注文や請求の手順を直すべきかが決まらない。

メール、フォーム、電話メモに履歴が分かれ、同じ相談を何度も数えている窓口責任者向けの記事です。

問い合わせ分析のAI活用では、メッセージ数と問い合わせ案件数を分けます。

同じ相談の続きへ対応を結んでから、改善先を分類する順で進めます。

AIは、関連する履歴と用件の候補を出す補助に使います。

同一案件か、何を改善するかは、根拠を見た担当者が判断します。

架空の12メッセージを8案件へ整理した表と、FAQ候補、業務の不備、個別対応へ分ける見本を示します。

実際の問い合わせやAIの動作結果ではなく、分析を始めるための設計例です。

この記事で分かること

• メッセージ数と案件数と用件数を分けます
• FAQで案内できる用件と、業務点検や個別判断が必要なものを分けます
• 同じ相談の続きと未解決を残して、次の担当へ渡します

メッセージ・案件・用件の、
どれを数えるかを決める

最初のメールに追加情報が届いた場合、受信したメッセージは2通でも、継続して対応する相談は1案件かもしれません。

1通に住所変更と領収書の依頼がある場合は、同じ受付の中に2つの用件が残ります。

問い合わせが12通なら、
12件の相談ですか？

受信メッセージとしては12通ですが、相談の案件数とは限りません。

本稿では、同じ対象と目的に関する継続対応を1案件へ結び、案件の中に複数の用件があれば別欄に残します。

例えば「注文がまだ届かない」と「先ほどの注文番号はO-301です」は、対象が照合できれば同じ案件の続きです。

後のメッセージを独立した配送遅延として数えると、実際より配送の相談が多く見えてしまいます。

同じ人から届いたら、
同じ案件にする？

同じ人という理由だけではまとめません。

注文も相談の目的も別なら、違う案件の可能性があります。

反対に、メールとフォームで届いた同じ相談は、チャネルが違っても関係を確かめる対象です。

AIが出した重複候補は、統合の確定ではありません。

分析用の対応表で候補と根拠を残し、実際の問い合わせシステムで履歴を結合する操作は別に判断します。

分析表へ、同一案件の
根拠と改善先を残す

受信した原文を消さず、メッセージIDから案件IDへ対応させます。

分類と集計に使った根拠が残れば、改善会議で「どの相談の話か」へ戻れます。

分析対象の期間と、
解決状態を見る時点をそろえる

本例は11月1〜7日に受けた架空の顧客側メッセージ12件を対象にします。

窓口からの返信は12件に含めず、解決状態は11月7日時点で見るという条件です。

実際の業務でも、受信と送信を同じ件数へ混ぜないようにします。

期間内に始まった案件だけを数えるのか、以前から続く案件も含めるのかで集計が変わります。

本例の8案件はすべて期間内に始まった想定です。

期間をまたぐ実務では、初回受付日と今回届いた日を分けてください。

履歴を集める前に、
閲覧と入力の範囲を絞る

実データには住所や注文内容、苦情などが含まれるため、誰が分析に使えるかを確認します。

AIサービスの契約、保存・処理条件、社内ルールに合う範囲で扱い、初回は架空の履歴で試してください。

分析のために全部署へ原文を広く共有する必要はありません。

改善担当へ渡すときも、その担当に必要な用件と根拠を絞ります。

顧客名を消しただけで、個別の注文を特定できなくなるとは限りません。

架空12メッセージを
8案件へ結ぶ

以下は、入力する顧客側メッセージの短い原文と、担当者が用意した対応の見本です。

同一案件IDは期待する整理結果で、文章だけで本人確認した結果ではありません。

実務では注文や受付の照合記録を使います。

M02/M03、M05/M06、M08/M09、M11/M12を、それぞれ同じ案件へ結ぶと12メッセージが8案件になります。

4組は2メッセージずつ、ほか4案件は1メッセージずつなので、8＋4＝12通です。

8案件の用件と、
11月7日時点の状態を残す

解決3案件、未解決5案件という状態は、今回の架空入力へ設定した途中経過です。

C02やC04を業務点検候補にしても、出荷ミスやシステム障害が確定したわけではありません。

まず記録を調べる先を指定しています。

C05の一方を答えても、
案件全体は解決にしない

配送先変更と領収書は別用件です。

領収書だけ案内できた場合も、配送先変更が残っていれば、その用件の状態を確認中へ残します。

案件数8を維持したまま、用件の対応状況を分ける方法です。

この例では各案件の用件を数えると、C05だけ2つなので合計9用件になります。

12メッセージ、8案件、9用件は違う数え方です。

分析表の見出しに何を数えたかを明記し、都合よく同じ件数へ合わせません。

追加情報を別案件へ
数えた結果を、どう直すか

M02とM03を別々の配送相談へ分類したら、原文の「先ほど連絡した」を見直します。

担当者が照合した注文への対応も、確認します。

似た文だからではなく、継続の根拠があることを理由に、分析表の案件IDをC02へそろえる修正です。

誤った整理例：
M02：配送相談1件。M03：注文番号の問い合わせ1件。

修正する理由：
M03はM02の注文を特定する追加情報であり、別の相談ではない。
本例では担当者が継続の対応を照合済みという条件がある。

修正後の記入見本：
C02／メッセージM02・M03／用件は未着の状況確認1つ
追加情報：注文O-301／状態：確認中
根拠：「先ほど連絡した注文番号」＋担当者の対応確認
次の担当：出荷記録を照合する担当
※実際の本人確認やシステム統合を行った記録ではありません。

逆に対応を確認できない実務の入力なら、C02へ確定せず「同一案件候補・照合待ち」とします。

候補の確認が終わるまで、案件数が暫定であることを報告へ残してください。

重複候補を除いた数だけを確定値にして、元のメッセージを落とさないようにします。

後から別件と分かった場合にも、対応表を直した理由と日付を残せば、過去の集計との差を説明できます。

FAQで案内できる問題と、
業務を点検する問題を分ける

同じ質問が多くても、すべてをFAQ化するとは限りません。

原文と状態から、一般的な案内が見つからないのか、実際の注文やシステムの問題なのかを読みます。

個別に判断すべき申し出かも、確かめます。

3つの改善先を、案件へ対応させる

FAQや案内を整える候補

C01の営業時間、C03の保存場所、C07の手順の場所は、現在の正式な案内で答えが決まるかを窓口が確認します。

FAQへ追記する前に、既存のページに答えがあるが見つからないのか、答え自体がないのかを調べます。

業務や画面を点検する候補

C02の未着やC04のエラーは、案内文を増やすだけでは解消しない可能性があります。

出荷記録やエラーの条件を担当が調べ、根本の手順や表示を直す必要があるかを判断します。

原因は分析表の分類だけでは確定できません。

個別の判断と継続対応が必要なもの

C05の変更、C06の欠け、C08の請求照合は、対象の注文と記録を見て進める用件です。

AIが一般回答を返して解決へ変えるのではなく、担当へ必要情報と未対応を引き継ぎます。

重要度は件数とは別に見ます。

少数の重大な問い合わせは、
後回しにしてよい？

件数が少ないことだけで優先度を下げません。

安全、個人情報、金銭などへの影響がある申し出は、組織の基準に従って担当者が扱います。

本例のC08も、1案件だからFAQの後でよいとは判断しません。

実際に二重請求かどうかは未確定でも、対象の照合を行う必要があります。

重大な申告を短い分類へ丸めて見えなくしないよう、原文と未解決の状態を残してください。

改善先の件数には、
分母と暫定の条件を添える

本例で主な引継ぎ先を1つずつ選ぶと、FAQ候補3、業務点検候補2、個別対応3です。

案件8を分母にすれば37.5％、25％、37.5％になります。

ただし、これは今回の8案件の分類であり、全顧客や全問い合わせの割合ではありません。

C05のように担当部署が複数ある案件も、主な改善先の集計では1案件です。

担当への作業件数を数える場合は別の指標として分けます。

複数ラベルへ切り替えるなら、分類数の合計が案件数を超えることを明示してください。

改善担当と確認日を決め、
件数だけで効果を断定しない

分類を終えたら、どの担当が何を見直し、いつ結果を見るかを決めます。

「FAQを充実させる」という案だけでは、何を直すかも確認する条件も分かりません。

次回の確認日は、各作業の予定と合わせて決めます。

今回の例は分析時点の状態を示すもので、実際の確認期限を相手へ約束したものではありません。

担当不在時の引継ぎ先も、未解決一覧へ残すことが必要です。

問い合わせが減ったら、
FAQの効果といえる？

件数の減少だけでは断定できません。

注文数や利用者数、営業日、収集したチャネル、季節、障害の有無などが違う可能性があります。

比較する期間と対象をそろえ、FAQ変更以外の条件も残します。

電話の記録が取れなくなって集計件数が減った場合、問い合わせ全体が減ったとは言えません。

未取得のチャネルは未取得と明記し、0件へ変えないようにします。

報告文は、観測した
ことと提案を分ける

架空の分析報告例：
対象は11月1〜7日に受けた顧客側メッセージ12通で、8案件・9用件です。
11月7日時点で解決3案件、未解決5案件です。
主な引継ぎ先はFAQ候補3、業務点検候補2、個別対応3です。
C02の未着とC04のエラーの原因は未確定です。
窓口はC01/C03/C07の案内の有無と見つけ方を点検し、
出荷/システム担当は対象記録を確認してください。
この集計だけで問い合わせ減少や改善効果を保証しません。

報告から原文へ戻れるIDを付けると、会議で分類を直したときにも対応できます。

推定した原因だけを共有し、対象の申し出を失う形にはしません。

履歴を毎回集め直す前に、
案件IDの対応を整える

少量なら、担当者が表へ12行を集めて対応を付ける方法で始められます。

メール、フォーム、電話メモから、繰り返し集める負担が残る場合もあります。

履歴と案件ID、担当への引継ぎをつなぐことが、相談の対象です。

AIに用件と重複候補を
整理させる指示文

初回は上の架空履歴を使い、確定した案件対応と候補を別に残します。

実際の受付を削除・結合する操作は行わせず、分析用の表で確かめてください。

問い合わせ履歴から、用件と同一案件の候補を整理してください。
列：メッセージID、案件候補、チャネル、用件、発生箇所、解決状態、原文根拠、追加確認。
同じ人、似た言葉というだけで同一案件にしません。
注文/受付の対応と継続の根拠がある場合だけ、候補として結びます。
一つの文に複数の用件があれば、別の用件として残してください。
回答したことを解決とみなさず、解決状態は入力の記録を保ちます。
原因や返金・変更の可否を推測しません。不明は担当者へ戻します。
元の履歴は削除・結合せず、返信・登録・送信は行いません。

本例ならC05の2用件が残り、追加情報4通が新しい相談へ数えられないかを見ます。

未解決5案件を、勝手に解決へ変えないかも確認します。

期待する表と照合した後も、原文の全行が何らかの案件へ対応するかを確かめます。

システム上の統合操作と、
分析用の関連付けを分ける

Zendesk公式のチケット統合の説明には、統合を元に戻せない注意があります。

引き継がれない項目などの注意も示されています。

製品による操作を行う場合は、その影響と権限を別に確認します。

AIの候補を作るために、先に原本の受付を結合する必要はありません。

まず分析用の対応表を残すと、別件を誤ってまとめた場合も根拠へ戻れます。

利用製品にある機能で足りる範囲も確認してください。

対応方法の選び方は問い合わせ対応のAI活用、深刻な申し出の受付はクレーム対応の受付と引継ぎで扱います。

アンケートの自由回答を分析する場合はアンケート分析の手順へ進めます。

まず1期間の履歴について、メッセージと案件と用件を分けて数えてください。

まるっとAIの問い合わせ対応の支援へは、収集と分類、確認結果の記録まで相談できます。

機密を含まない履歴見本、期待する案件対応、使っている道具、改善担当が相談の材料です。