この記事を実践に移す
無料記事で概要をつかんだら、会員ライブラリや料金ページから続きに進めます。
サポート部門は「定型 7 割」が現実線
カスタマーサポートは、一見「丁寧に個別対応する仕事」に見えますが、ログを取って分類するとほとんどの問い合わせが似たパターンに収まります。多くの組織で、定型 7 割／条件分岐 2 割／真の個別 1 割、くらいの分布になります。
AI を入れる際、この 3 層を分けて考えると、どこで効果が出てどこで人が要るかが見えやすくなります。
- - 定型（7 割）：FAQ ベースで完結する問い合わせ。AI で一次回答までいける。
- - 条件分岐（2 割）：契約状況や履歴で答えが変わる。AI ＋ 人の二人三脚。
- - 個別（1 割）：感情や信頼関係が絡む。人がやる。
最初から全部に AI を入れようとすると、条件分岐と個別の領域で誤回答が出て、定型で稼いだ時間以上のリカバリ工数を生みます。順番として、まず定型 7 割の自動化を完成させ、残り 3 割は当面人で受け、データが溜まったら条件分岐の一部に広げていきます。
一次回答テンプレを 30 個から始める
定型 7 割を AI で受けるとき、いきなり全 FAQ を学習させるのではなく、頻度上位 30 件の問い合わせから始めます。問い合わせログから、よくある順に 30 件抽出し、それぞれに対する社内承認済みの回答文を作っておきます。
AI には、この 30 件のテンプレと、回答時の口調ルール（「ですます調」「お客様呼称」「不確実な場合は人につなぐ」など）を渡します。社外へ送る前段で、必ず人が確認するか、確信度の低い回答は自動で人にエスカレートする設定を入れます。
ここで詰めておきたいのは「答えない選択」です。AI が無理に答えようとして誤回答するより、「この件はサポート担当に確認のうえ折り返します」とだけ返して人にバトンを渡す方が、結局リカバリ工数は少なくなります。
人にエスカレートする条件を文章化する
条件分岐の問い合わせを AI で受けると、判断材料が足りない領域で破綻します。最初に決めるべきは、人へエスカレートする条件です。次のような線を文章化しておきます。
- - 解約・返金・苦情を含む問い合わせ
- - 契約内容の変更を伴う問い合わせ
- - 過去 1 か月以内に同件で再問い合わせがある顧客
- - 個人情報や本人確認が要る案件
- - AI の確信度が一定以下の場合
この条件は AI の振り分けロジックに入れておきます。線を曖昧にすると、現場でクレームが起きたときに「なぜそれが AI に回されたのか」を説明できなくなります。
KPI は対応時間より「再問い合わせ率」
サポート AI の導入評価は、対応時間の短縮で語られがちですが、それだけだと「速いけれど結局解決していない」状態を見落とします。代わりに次の 2 つを見ます。
- - 再問い合わせ率（同じ顧客が同件で再度連絡する割合）
- - 一次解決率（最初のやり取りで完結した割合）
対応時間が短くなっても、再問い合わせ率が上がっていれば、AI 一次回答が実は機能していない可能性が高いです。逆にこの 2 指標が改善しているなら、対応時間が同じでも価値は出ています。
失敗例と運用ルール
サポート AI で起きやすい失敗は次の 3 つです。
- - AI が確信を持って誤回答し、顧客に届いてしまう
- - 古い FAQ を学習源にしたまま、商品改定に追従できていない
- - 人へのエスカレート条件が現場で覚えられていない
対策として最低限必要なのは次の 3 点です。
- - AI の出力をそのまま送らない、または確信度低の場合は人を経由する
- - FAQ の更新リズムを月次で固定する
- - エスカレート条件を 1 ページにまとめ、新人にも配る
サポートは顧客の信頼の最前線です。「AI で速くなった」より、「AI で対応の質が安定した」と評価されるのが理想です。
次回予告
次話からは内向きの部署に入ります。まずは人事・採用です。営業や CS とは違い、応募者という外部の人を扱いつつ、社内の人事評価という機微情報も交差する場所です。AI に渡してよい範囲が一段シビアになります。
この回のまとめ：
- - サポートを定型 7 割／条件分岐 2 割／個別 1 割の 3 層で考える。
- - 頻度上位 30 件の FAQ から AI 一次回答を始める。
- - 人へのエスカレート条件を文章化する。
- - KPI は対応時間より再問い合わせ率と一次解決率。
- - FAQ の月次更新と、エスカレート条件の 1 ページ配布。
