問い合わせを減らすには、件数が多い原因を確かめ、説明・発見経路・手続きの障害を直すことから始めます。窓口を見つけにくくして件数を下げても、顧客の問題が解決したとは限りません。
Zendeskの問い合わせ削減の説明も、内容と増加要因を分析して対策を選びます。この記事では架空のネット通販（EC）事業を使い、原因別の改善表と注文当たりの問い合わせ率、再問い合わせによる確認方法を示します。特定製品の導入効果を保証する例ではありません。
件数が増えた理由を分ける
取引が増えたのか、同じ取引で困る人が増えたのかを分けて確認します。
問い合わせ日時、目的、注文や契約の段階、利用した経路、同じ問題での再連絡、処理結果を残します。顧客が送った複数のメールを、そのまま別の問題として数えると実態がずれます。最初の相談と同じ問題での追加連絡を区別し、件数の単位を先に決めてください。
注文増加、商品変更、障害、案内の変更、広告による顧客層の変化も確認します。目的別の件数を並べ、実際の相談記録を読むと、「配送が遅い」と「配送予定が分からない」を分けられる場合があります。同じFAQ（よくある質問と回答）へ送る前に、この違いを確かめます。
顧客の言葉を整理するには顧客の声（VoC）の収集・分析を使えます。分類できない内容は無理にその他へ押し込まず、どの情報が不足したかを残してください。
原因別に改善を選ぶ
回答を足す対策と、問い合わせが起きる業務を直す対策を使い分けます。
| 確認した問題 | 改善の候補 | 確かめる行動・結果 |
|---|---|---|
| 情報が足りない | 送料・期限・条件を疑問が起きる場所に表示 | 注文前に総額と条件を判断できるか |
| 答えはあるが見つからない | 言葉・分類・画面からの入口を修正 | 顧客が自力で回答へ進めるか |
| 手続きが進まない | 入力エラー、権限、処理状態を改善 | 対象の操作を完了できるか |
| 進捗が見えない | 確認済みの状態と次の連絡予定を案内 | 状態確認の再連絡が減るか |
| 個別判断が必要 | 担当と必要情報を明示して引き継ぐ | 繰り返し説明せず担当へ届くか |
説明用の架空例として、「発送予定を教えて」という相談が多い店舗を考えます。共通のFAQだけでは各注文の予定が分からないため、注文履歴から開く詳細画面に、確認済みの予定と更新時点を表示する案です。
| 状態 | 表示位置 | 案内文の例 |
|---|---|---|
| 改善前 | 共通FAQのみ。注文詳細は「準備中」 | 通常3〜5日で発送します |
| 改善後：予定確認済み | 注文詳細の配送状況欄 | 発送予定：10月9日。10月7日15時更新。変更があれば、この欄とメールでお知らせします |
| 改善後：遅延で未確定 | 同じ配送状況欄を更新 | 入荷遅延のため、発送日は確認中です。10月8日17時までに状況を更新します。お急ぎの場合は注文の問い合わせ窓口へご連絡ください |
日付・更新時刻は架空の運用例です。実際には担当者が守れる更新予定を設定し、発送予定と到着予定を区別します。未確定の日時を推測で埋めず、次の確認予定と連絡先を示すことが改善の中心です。
Intercomのヘルプ内容の説明は、実例、顧客の言葉、内容の見直しを扱います。何の操作を完了したいかが伝わる実例を付け、読むだけで手続きが進むかを試してください。
注文当たりの問い合わせ率を計算する
件数と、対象の取引量を分母にした率を併記します。
次の架空の計算例では、集計条件を次のようにそろえます。
- 対象：改善前・改善後それぞれ30日間に受付が完了した注文。注文に関係しない会員登録や採用の相談は除きます。
- 1件の数え方：同じ注文・同じ相談目的での最初の相談を1件とします。注文ID・顧客ID・相談目的で追加連絡を区別し、別目的の相談は別件とします。
- 観測期間：各注文の受付後7日間。両期間とも、最後の注文まで7日間の観測を終えたと仮定します。
| 期間 | 対象注文数 | 初回相談件数 | 注文当たりの相談率 |
|---|---|---|---|
| 改善前の群 | 2,000件 | 300件 | 15％ |
| 改善後の群 | 3,000件 | 300件 | 10％ |
この架空例では、改善前は300÷2,000×100＝15％、改善後は300÷3,000×100＝10％です。件数は変わりませんが、率は5ポイント低下しています。これは問い合わせした顧客の割合ではなく、注文当たりの相談件数の比率です。同じ注文で目的の違う相談が複数あれば、両方を数える定義にしています。
商品構成や流入経路が変わった可能性もあります。同種の注文・同じ観測期間で比べ、季節、障害、顧客層などを確認します。率の差だけでFAQやシステム変更の効果と断定しません。
自己解決と再問い合わせを確認する
担当者への問い合わせが発生しなかったことと、問題が解決したことは別です。
Zendeskの解説は、人の窓口へ送らなかった状態と、返金・変更などが実際に完了した状態を区別しています。FAQ閲覧数やチャットの終了数を、解決数として自動的に扱わないようにします。
説明用の架空の件数で、評価方法を考えます。解決と記録された相談を、同じ問題で7日以内に再連絡したかで確認するとします。7日の観測を終えた200件のうち25件が再連絡なら、再問い合わせ率は12.5％です。改善後、観測を終えた240件中48件なら20％です。初回の相談率が下がっても、この再問い合わせが増えたなら、回答の不足や完了判断を調べる必要があります。
7日という期間は説明用です。相談の性質に応じて決め、期末近くで観測が終わっていない相談を同じ分母へ混ぜません。解決不明、離脱、回答待ちも分けて残します。顧客が簡単に目的を達成できたかは顧客努力指標（CES）なども補助になりますが、回答者だけの結果を全顧客へ一般化しません。
小さく試して運用へ戻す
一つの相談目的に絞り、変更前後の記録と失敗した経路を残します。
まず「発送予定の確認」などの対象を選びます。案内する状態、未確定時の文面、表示場所、個別窓口を決め、通常・遅延・情報取得失敗で試します。公開後は、対象の相談率、再問い合わせ、処理の完了、担当者の作業を同じ条件で確認します。
説明用の仮定で試算します。月100件の相談対応が不要になり、1件6分を別の対応へ回せるなら、600分＝10時間の余力です。1時間3,000円で換算すると3万円相当ですが、人員や支払いが減らなければ現金の削減ではありません。システム費と更新作業も加えて判断します。
問い合わせの多い回答だけを更新して終わりにせず、原因になった画面や業務の担当へ戻します。窓口の到達が難しくなった、重大な相談が届かなくなった場合は、件数減を成功と扱わず経路を見直してください。
まとめ
問い合わせ削減は、顧客の問題を減らし、必要な相談は届く状態にするために進めます。
- ✓相談の目的と取引量を確認して原因を分けます。
- ✓説明・発見経路・手続き・進捗のどこを直すか選びます。
- ✓件数と率、再問い合わせ、実際の完了を合わせて見ます。
- ✓時間の余力と現金の支出削減を区別して評価します。
一つの問い合わせ目的を選び、上の原因表へ実際の記録を当てはめてください。回答を増やす前に、顧客がどこで止まったかを確認できます。
