2026.11.04 Webシステム

問い合わせ対応の効率化：件数と処理時間を分けて測り、FAQ・チャットボット・管理ツールを選ぶ手順

問い合わせ対応の効率化は、「件数を減らす施策」と「1件あたりの処理時間を縮める施策」を分けて考えると、何から手を付けるべきかがはっきりします。FAQを増やしても処理時間の長い問い合わせが残っていれば工数は下がらず、テンプレートを整えても同じ質問が毎日来るなら件数は変わりません。この記事では、月の工数を件数と処理時間に分解して測る手順、理由コードでの分類、件数を減らすFAQ・フォーム・発生源の修正、処理を速くする窓口の一元化・定型返信・期限管理、チャットボットに任せる範囲を順に説明します。ツールの設定例はZendeskの公式ヘルプで2026年11月時点の仕様を確認しました。最後に、月の件数と担当者数で決める着手の順番を示します。

まとめ：問い合わせ対応の効率化は件数削減と処理時間短縮を分けて施策を選ぶ

問い合わせ対応の効率化で成果が出ない会社は、チャットボットや管理ツールといった手段から選び始めていることが多くあります。どの手段が効くかを決める判断材料は、問い合わせの中身です。手順や仕様を尋ねる質問が多ければ件数を減らす施策が効き、個別の調査が必要な問い合わせが多ければ処理時間を縮める施策が効きます。

進める順番は3段階です。まず直近1か月の問い合わせを理由コードで分類し、件数と平均処理時間を出します。次に、件数の多い理由にはFAQやフォームの改善、または画面や案内文そのものの修正を当てます。最後に、残った問い合わせの処理を窓口の一元化・定型返信・期限管理で速くしてください。

月の問い合わせが100件に満たず担当が1〜2人なら、共有の受信箱と返信テンプレートで十分です。月300件を超えて窓口が3つ以上に分かれているなら、問い合わせ管理システムに履歴と期限を集める段階にあります。チャットボットは、回答が1つに決まる質問が全体の3割を超えてから検討します。

問い合わせ対応の工数を分解する｜件数・処理時間・再問い合わせ率で現状を測る手順

効率化の効果を判断するには、着手前の数字が要ります。見るのは件数、1件あたりの平均処理時間、再問い合わせの割合の3つです。担当者の「忙しい」という感覚だけで施策を決めると、効果があったのかどうかを後で確かめられません。

月間工数は「件数×平均処理時間」で出し、施策の効果を時間で比べる設例

月に400件の問い合わせがあり、平均処理時間が15分の窓口を考えます（設例）。月の対応工数は6,000分、つまり100時間です。この窓口でFAQを整えて件数を2割減らすと80時間になり、定型返信で処理時間を15分から12分に縮めても80時間になります。

2つの施策は、同じ20時間の削減です。どちらを選ぶかは、施策にかかる手間と、どちらの数字に改善の余地が大きいかで決まります。処理時間は、受付から返信送信までの作業時間を担当者が記録するか、問い合わせ管理システムの記録から取ります。最初の1か月は概算で構いませんが、測り方は施策の前後で変えないでください。

直近1か月の問い合わせを理由コードで分類し、上位5種で何割を占めるか確かめる

理由コードとは、問い合わせの用件を「ログイン方法」「請求書の再発行」「配送状況」のように短い分類名で表したものです。直近1か月の問い合わせを読み、1件ずつ理由コードを付けていきます。分類は最初から細かく作らず、15〜20個程度で始め、どれにも当てはまらないものは「その他」に入れます。

分類が終わったら、件数の多い順に並べます。多くの窓口では上位5種で全体の半分以上を占めます。この上位5種が、次の章以降で施策を当てる対象です。「その他」が2割を超える場合は分類が粗すぎるので、「その他」の中身を読み直して新しいコードを足してください。

一次解決率と再問い合わせ率を見ないと、返信が速くなっても件数が戻る失敗

処理時間だけを目標にすると、担当者は短い返信で問い合わせを閉じるようになります。その結果として起きるのが、顧客が同じ件で再び連絡してきて、件数が増えるという失敗です。返信の速さと引き換えに、総工数はかえって増えます。

これを防ぐには、最初の返信で用件が片付いた割合（一次解決率）と、同じ顧客から7日以内に同じ用件で連絡が来た割合（再問い合わせ率）を一緒に追います。処理時間が縮んだのに再問い合わせ率が上がっていれば、その施策は失敗です。7日という期間は自社の取引の周期に合わせて決めて構いません。

問い合わせ件数を減らす施策｜FAQ・フォーム設計・発生源の修正を理由コード別に当てる

件数を減らす施策は、理由コードごとに当てるものが違います。手順や仕様の質問にはFAQ、情報不足でやり取りが往復する問い合わせにはフォームの設計、自社の画面や書類の分かりにくさから生まれる問い合わせには発生源の修正が効きます。

手順や仕様の質問はFAQで受け、検索してもヒットしなかった語を毎月直す

「パスワードの再設定方法」「対応ブラウザ」のように、誰が答えても同じ回答になる質問はFAQに載せます。FAQの1項目には、質問文を顧客が使う言葉で書き、回答の中で手順を番号付きで示してください。社内の正式名称で書くと、顧客が検索しても見つかりません。

FAQを公開した後は、FAQ内の検索で結果が0件だった語を毎月一覧にします。0件の語は、FAQが無いか、言葉がずれているかのどちらかです。上位10語について項目を足すか、既存の項目に言い換えの語を加えます。この作業を続けないFAQは、半年ほどで現状と合わない回答が増え、かえって問い合わせを生みます。

問い合わせフォームの選択式項目で、用件と必要情報を最初の1通でそろえる設計

問い合わせの往復が多い窓口では、最初の連絡に必要な情報が足りていないことが原因になっています。注文番号、利用している機種、エラーの画面などを、担当者が毎回聞き返している状態です。

フォームの先頭に用件の選択肢を置き、選んだ用件に応じて必須項目を切り替えると、1通目で調査に必要な情報がそろいます。用件の選択肢は、前の章で作った理由コードと同じ分類にしておくと、受け付けた時点で分類が済むため、集計の手間も減らせる仕組みです。項目を増やしすぎると入力の途中で離脱されるので、必須項目は用件ごとに3〜4個までに抑えます。入力の負担を下げる具体策はEFOの改善施策と実装・計測の判断基準で扱っています。

同じ理由の問い合わせが続くときは、画面・請求書・案内メールの側を直す

理由コードの上位に「請求金額の内訳が分からない」「申込後の案内メールが届かない」といった項目がある場合、FAQで答え続けるのは対症療法です。請求書に内訳の行を足す、案内メールの件名と送信元を変える、画面のボタンの文言を変えるといった修正で、問い合わせそのものが発生しなくなります。

発生源の修正は、問い合わせ窓口の担当者だけでは進みません。理由コード別の件数を月次で開発・営業・経理の担当者に共有し、件数の多い順に修正の担当を決めます。1つの修正で月数十件が消えることもあり、件数を減らす施策の中では最も効果の大きい部類に入ります。

1件あたりの処理時間を縮める施策｜窓口の一元化・定型返信・優先度別の期限管理

件数を減らしても残る問い合わせは、処理の速さで工数を下げます。処理時間を押し上げているのは、問い合わせを探す時間、過去のやり取りを読み返す時間、返信文を一から書く時間、対応が止まっている案件に気づくまでの時間です。

メール・電話・フォームの窓口を1つの受付箱に集め、担当の割り当てで二重返信を防ぐ

問い合わせがメール、電話のメモ、フォームの通知、個人宛のメールに散らばっていると、担当者はまず問い合わせを探すところから始めることになります。同じ問い合わせに2人が返信したり、誰も返信しなかったりする事故もこの状態で起きます。

最初の一歩は、窓口を1つの受付箱に集め、1件ごとに担当者を割り当てる運用です。Google Workspaceを使っている会社なら、Googleグループの共同トレイで会話を担当者に割り当てられます。Groups Settings APIのリファレンスでは、グループの共同トレイの有効化は enableCollaborativeInbox という設定項目で、割り当てなどの個別の権限は whoCanAssistContent に統合されたという記載です。電話の問い合わせも、受けた担当者が受付箱に記録を残すルールにして、1か所に集めます。

定型返信は返信文とステータス変更をまとめて登録し、手作業の更新を減らす

よくある用件への返信は、文面をテンプレートにして使い回します。このとき文面だけでなく、返信後に行う作業もまとめて登録すると、処理時間がさらに縮みます。

Zendeskのマクロ作成に関する公式ヘルプによると、マクロにはコメントの追加に加えて、チケットフィールドの更新、タグの追加・削除、担当者の変更、件名の設定などのアクションを登録できます。個人用マクロはエージェントも作れますが、全員で使う共有マクロを作れるのは管理者か権限を持つカスタムロールのエージェントです。共有の定型返信は管理者が持ち、文面の更新日と担当者を決めておくと、古い案内が送られ続ける事故を防げます。Zendeskそのものの料金と連携の制約はZendeskの公式料金とAPI制限、自社システム連携の判断基準にまとめています。

初回返信と解決までの目標時間を優先度別に決め、期限を過ぎた案件を一覧で拾う

対応が止まった問い合わせは、顧客から催促が来て初めて気づかれがちです。催促への対応と謝罪で、本来の処理より時間がかかります。目標時間を決めて、過ぎそうな案件を先に拾う運用に切り替えます。

ZendeskのSLAポリシーの定義に関する公式ヘルプでは、目標を設定できる指標として、初回返信時間、次の返信時間、更新間隔、一時停止可能な更新、リクエスタの待機時間、エージェント作業時間、合計の解決時間の7つが挙げられています。目標はチケットのシステム優先度（低・普通・高・緊急）ごとに置き、優先度が空白のチケットには適用されません。計測はカレンダー時間か営業時間かを選べます。

優先度	当てはまる問い合わせの例	初回返信の目標（設例）	解決の目標（設例）
緊急	サービスが使えない・決済ができない	営業時間で1時間	営業時間で4時間
高	請求額の誤り・納品物の不具合	営業時間で4時間	2営業日
普通	操作方法・仕様の確認	1営業日	3営業日
低	要望・資料請求	2営業日	5営業日

表の時間は当社が置いた設例で、自社の体制に合わせて決めます。大切なのは、優先度を受付の時点で必ず付けるルールにすることです。Zendeskの仕様どおり、優先度が空白のままでは期限の管理から漏れます。なお、このSLA機能はZendesk Suiteの場合Growth以上、Supportの場合Professional以上で使えます。

チャットボットとAI自動応答に一次対応を任せる範囲｜向く問い合わせと向かない問い合わせ

チャットボットは件数を減らす施策と処理時間を縮める施策の両方にまたがりますが、何でも任せられるわけではありません。任せる範囲は、理由コードの分類結果から決めます。

回答が1つに決まる質問が全体の3割以上あるならチャットボットの一次受けが合う

チャットボットが確実に答えられるのは、誰が答えても同じ回答になる質問です。理由コードで分類した結果、営業時間、料金表の場所、パスワードの再設定、配送日数のような質問が全体の3割以上を占めるなら、チャットボットに一次受けを任せる価値があります。1割程度にとどまるなら、FAQの整備で足ります。

チャットボットで答えられなかった質問は、記録を残して有人の窓口へ渡します。この記録は、FAQの0件ヒットと同じく、回答を足すべき質問を一覧にするための資料です。社内向けの窓口で一次受けを組む具体例はチャットボットでヘルプデスクを一次受けする設計（振り分け・FAQ整備・有人引き継ぎ）で扱っています。

契約・請求・苦情など個別判断が要る問い合わせは有人へ渡す条件を先に決める

解約の申し出、請求額への異議、苦情は、顧客ごとの契約内容や経緯を確かめないと答えられません。こうした問い合わせをチャットボットで受け止めようとすると、顧客は同じ説明を何度も繰り返すことになり、不満が大きくなってから有人の窓口に届きます。

導入前に、有人へ渡す条件を決めておきます。用件の選択で「解約」「請求」「苦情」を選んだ場合、2回続けて回答が解決につながらなかった場合、顧客が担当者との会話を求めた場合の3つが基本です。有人へ渡すときは、それまでの会話を担当者が読める形で引き継ぎ、顧客に同じ質問をしないようにしてください。

生成AIで返信の下書きを作る運用は、ナレッジの更新日と承認者を決めてから始める

生成AIに過去の回答やFAQを読ませ、担当者向けに返信の下書きを作らせる方法もあります。担当者は下書きを確認して送るだけになるので、文章を書く時間が縮みます。

ただし、下書きの元になるナレッジが古いと、誤った案内を速く大量に送ることになります。始める前に、各ナレッジの更新日と内容の承認者を決め、料金や仕様が変わったときに誰が直すかを明確にしてください。顧客へ直接自動で返信させるのは、下書きの修正率が十分に下がったことを数字で確かめてからにします。シナリオ型とAI型の違いや費用の考え方はチャットボット導入の手順・費用相場とシナリオ型・AI型の選び方で整理しています。

問い合わせ対応の効率化で何から手を付けるか｜月の件数と担当者数で決める判断基準

ここまでの施策を全部そろえる必要はありません。以下は、月の問い合わせ件数と担当者の人数から着手の順番を決める、当社の判断基準です。

月100件未満・担当1〜2人なら共有受信箱とテンプレートで足り、専用ツールは過剰

月の問い合わせが100件に満たず、担当者が1〜2人の窓口では、問い合わせ管理システムやチャットボットは過剰です。共同トレイのような共有の受信箱に窓口を集め、よくある用件の返信テンプレートを10本ほど用意すれば、探す時間と書く時間の大半は消えます。

この規模でも、理由コードの集計だけは最初から続けてください。件数が増えてツールを入れるとき、過去の分類があれば、どの用件をFAQやチャットボットに回すかを実績から決められます。表計算で1件1行、日付・理由コード・処理時間の3列があれば足ります。

月300件超で窓口が3つ以上なら、問い合わせ管理システムで履歴と期限を一元化する

月の件数が300件を超え、メール・フォーム・電話など窓口が3つ以上に分かれている場合は、共有の受信箱では追い切れなくなります。顧客ごとの過去のやり取りを探す時間と、期限を過ぎた案件の見落としが、処理時間の大半を占めるようになるからです。

この段階では、問い合わせ管理システムに履歴と担当と期限を集めます。導入の進め方と定着のさせ方は問い合わせ管理の導入｜属人化を解消する5ステップと定着・失敗回避の進め方で詳しく扱っています。製品の選び方はメール型・チケット型・チャット型の3タイプで比べた問い合わせ管理システム比較（3タイプの選び方とSaaS・受託構築の判断軸）を参照してください。

チャットボット導入を見送るべき場面と、FAQや連携の構築を外部に頼む切り分け

次の場面では、チャットボットの導入を見送ります。回答が1つに決まる質問が全体の1割程度しかない場合、FAQやナレッジの更新担当が決まっていない場合、問い合わせの多くが契約内容の確認など顧客ごとの照会である場合です。最後の場面では、チャットボットより、顧客が自分で契約や注文の状況を確かめられる画面を作るほうが件数は減ります。

外部に頼みやすいのは、FAQや問い合わせ管理と基幹システム・顧客管理のデータ連携、会員情報を照会して答えるチャットボットの構築です。理由コードの設計と、有人へ渡す条件の決定は、自社の窓口責任者が持つべき部分です。顧客情報と連携して答えるチャットボットや、社内のナレッジを元に答えるAIの構築を検討している場合は、一創のAIチャットボット開発で要件の整理から相談を受けています。

よくある質問

問い合わせ対応の効率化を検討するときによく出る質問に答えます。

問い合わせ対応の効率化は何から始めればよいですか？

直近1か月の問い合わせに理由コードを付け、理由ごとの件数と平均処理時間を出すところから始めます。ツールを選ぶ前のこの集計が、件数を減らす施策と処理時間を縮める施策のどちらが効くかを決める判断材料です。集計は表計算で、日付・理由コード・処理時間の3列があれば始められます。上位5種の理由が全体の何割を占めるかを見て、そこから施策を当ててください。

社内問い合わせと顧客からの問い合わせで、効率化の進め方は違いますか？

件数と処理時間に分けて測るという進め方は同じです。両者で異なるのは、問い合わせの発生源を修正するときの取り組みやすさです。社内の問い合わせは、規程や申請画面、社内マニュアルを直せば発生源から減らしやすく、FAQとチャットボットの効果も出やすい傾向があります。情報システム部門の窓口を受付・チケット管理・ナレッジ化の3点で組む手順はITヘルプデスクの仕組みを作る設計手順で扱っています。

問い合わせ件数を減らせたかどうかは、どう測ればよいですか？

施策を当てた理由コードの件数を、施策の前後で同じ期間の長さで比べます。全体の件数は季節や売上の増減で動くため、施策を当てた理由の件数だけを見るのが確実です。あわせて、FAQやチャットボットの閲覧後に問い合わせに進んだ割合と、7日以内の再問い合わせ率も確認します。件数が減っても再問い合わせ率が上がっていれば、顧客が答えを得られずに離れている可能性があります。

電話の問い合わせはどう効率化すればよいですか？

電話は記録が残りにくいため、まず受けた担当者が受付箱に用件と理由コードを残すルールを作ります。そのうえで、営業時間の案内や担当部署への振り分けは自動音声応答（IVR）に任せ、手順の説明はSMSやメールでFAQのページを送る形に切り替えるのが、通話時間を縮める基本の組み立てです。振り分けの設計例はIVRで予約変更や問い合わせを振り分ける設計で説明しています。

Excelやスプレッドシートでの問い合わせ管理はいつまで続けられますか？

担当者が1〜2人で月100件程度までなら、1件1行の一覧で管理できます。限界が来るのは、複数人が同じファイルを同時に更新して上書きが起きるとき、顧客ごとの過去のやり取りをメールから探す時間が増えたとき、期限を過ぎた案件に気づけなくなったときです。このいずれかが毎週起きるようになったら、履歴と期限を自動で残せる問い合わせ管理システムへの移行を検討する時期です。