kakinang INSIGHTS · 2026-10-04

中小企業は何を見れば、AI接客が役立っていると分かりますか?

AI 報告と人の確認を使い、AIが問い合わせ対応を助けているか調べたいです。 との会話数が増えても接客改善とは限りません。サイト訪問が増えたか、同じ問題を何度も聞かれているかもしれません。営業時間外の問い合わせを受ける、リードを見落とさない、顧客が予約を確認するなど、先に改善したい仕事を決めます。報告の数字は手掛かりであり、会話と人の対応を抽出して確認しなければ品質は判断できません。「AI解決率」一つに結論を任せないことが大切です。

小チームが机で接客報告を確認するイメージ
イメージ図。製品画面や実際の顧客記録ではありません

数字の前にサービス結果を定める

三人の接客チームが求めるのは「営業時間外の問い合わせが消えないこと」かもしれず、AIの発話を増やすことではありません。営業時間外の新規会話、人の判断が必要な件、翌日も待ちの件、顧客が有用な次の行動を得たかを見ます。別の会社が営業問い合わせの漏れを防ぎたいなら、連絡先の品質、責任者、実際に約束した時間内の返信を調べます。目標と決定がないまま全報告を一枚に並べても改善につながりません。

Zendeskの公式指標資料は初回返信、解決時間、再開案件、満足度を区別し、初回返信の定義を確認するよう説明します。これは測り方の参考であり、kakinangにZendeskのすべての項目があるという意味ではありません。NISTのAIリスク枠組みも測定を後の管理と結びます。利用者に影響する結果を調べ、知識、当番、例外手順を変えられる責任者を報告の横に置きます。

期間と分母を固定します。二週間のリード追跡率を比べるなら、分母は各週の新規リードから重複やテストを除いた数、分子は初回の有人連絡が済んだ数と決めます。初回連絡が製品の指標になければ会社の作業表に記し、リード数を追跡完了と呼びません。窓口構成、営業日、広告活動も印を付けます。広告で急増した件数に、勤務変更の効果が隠れるかもしれません。

Zendesk Help

報告を実際の流れに戻す

kakinangの事業者分析では有人待ち、未読会話、今日のリードと会話、解決とAIによる解決、平均初回応答と解決時間、期間推移を確認できます。会話、利用量、リード、予約、商務、connectorの報告区分もあり、権限を持つ人は利用できる画面からCSVを書き出せます。見える範囲は役割と有効な機能によります。数字の定義、対象期間、記録に入らない社外業務を確かめてから読みます。

週ごとに入口、処理、次の行動の三層で読みます。チャット開始と新規会話の増減、未読と有人待ちの滞留、解決時間、その後にリードの追跡と顧客による予約確認を見ます。会話が増えてリードが増えない場合、公開の質問が解決した可能性も、受付経路が壊れた可能性もあります。会話で時刻を提案しただけで予約完了と数えず、顧客の確認と業務記録で判断します。

利用量の報告は会話やtokenなどの資源消費を把握する手掛かりで、品質そのものではありません。tokenが増えたら訪問数、会話の長さ、再質問、知識の検索を見てから回答を短くするか決めます。必要な説明を削ると有人負担が増えるかもしれません。CSVは会社の追跡記録との照合に使えますが、権限のある人が保管します。商談ごとの実際の売上や主観的満足度が報告にないなら別に収集し、内蔵指標と呼びません。

紙の図表で週次の接客を確認する仮の場面、実績ではありません
紙の仮データです。製品画面や実績ではなく、入口、処理、次の行動を分けて考えます。

NIST

週表で次に直す場所を決める

小さな講座会社に一週間でサイト新規会話が四十件、そのうち八件が人の判断を要し、五件が連絡先を残し、三件が体験予約を確認したと仮定します。これは方法を説明する仮の数字で、kakinang顧客の成果ではありません。三を四十で割って「AI転換率7.5%」と宣言するのは早計です。住所だけの質問や重複試験も入るからです。五件の連絡先と責任者を一つずつ見て、三件の予約がリードと重なるかも調べます。

人の判断が必要な八件を抽出します。月曜に二件残っているならまず当番と通知を直します。公開済み価格を二人が尋ねたなら知識の古さや出所の検索を調べます。範囲外の依頼をAIが明確に断り人へ案内したなら、それは正しい扱いかもしれません。「AIが役立たない」を原因に分けます。ライブ有人対応と非同期リードの時間は分けて測り、週末に当番のない手順をライブの返信約束で測りません。

週表には期間、値、抽出した事例、修正内容、担当者、次の確認日だけで足ります。FAQを直せば同じ質問が減るか、通知を変えれば待ちが減るか、有人当番を増やせば本当に人が返信したかを確認します。報告だけで因果は証明できず少数例は全顧客を代表しませんが、直せる詰まりは見つかります。定義、分母、次の行動が曖昧な数字を成果の約束にしません。改善ごとに中止条件も決めます。誤った価格の回答が二週続けば関連する公開知識を一時停止して担当者が確認し、通知変更後も未対応の受付が残れば受信箱の責任者と休日当番を調べます。数値が改善しても社員の負荷が増すなら自動解決率だけでなく人の対応時間も検討します。基準は各社のサービス約束に合わせ、人が修正を決めて実行します。次の担当者が再計算できるよう、結論には対象期間とデータの出所を添えます。

リードと予約を照合する仮の場面、実績ではありません
イメージ:報告の数字を人の追跡と比較します。仮の値は成果ではありません。

チームからの質問

AI回答率が高ければ顧客満足ですか?

違います。もっともらしくても根拠のない回答、繰り返し質問、未対応があり得ます。解決と引き継ぎの件数と共に回答の出所、残る問題、実際の返信を調べます。満足度を収集していないなら推測できません。

初回応答時間にはAIの自動文が入りますか?

製品と報告によって定義が違います。Zendeskの初回返信は人の公開回答を基準とします。kakinangの平均初回応答時間は本製品の定義で読みます。有人引き継ぎの速度は要請時刻と人の実際の返信時刻を別に記録できます。

リードはすべて成約と数えますか?

いいえ。連絡先が使えるか、要望が明確か、担当者が追跡したかを見ます。リードは流れの入口であり、成約やサービス完了とは異なります。対応する資料なしにリード数を売上と呼びません。

毎日多くの報告を見ますか?

固定期間と行動を変えられる少数の数値に絞ります。新規会話、有人待ち、未読、リード、確認済み予約などを見て、毎週成功と失敗の例を抽出し、知識、通知、当番のどれを直すか決めます。

出典と参考資料

  1. Analyzing the metrics that matter to improve customer support — Zendesk Help
  2. AI Risk Management Framework Core — NIST