ケースを閉じる前に、何を残すか
「この問い合わせ、前にもありませんでしたっけ」
問い合わせ対応の現場では、こういう会話が起きることがあります。
前回もFAQを確認したし、必要があれば有識者にも聞いた上で、顧客への回答も返した。
対応としてはたしかに終わっていますが、それでも翌週また似た問い合わせが来る。
別の担当者が同じFAQを探し、同じように有識者へ確認している。前回の対応履歴は残っているのに、どの対応を参照すればよいのか分からない。FAQもマニュアルも更新されず、また同じような問い合わせに向き合っている。
AIを使えば、問い合わせ内容の要約や、過去の対応履歴の検索、返信文のたたき台作成は速くなります。FAQやマニュアルを参照しながら、それらしい回答文を作ることもできます。
ただ、現場で繰り返されている負荷は、回答文を書く時間だけに出ているわけではありません。
前回の担当者が見たFAQも、製品部門へ確認したチャットも、顧客へ返した文面も残っています。ところが、ケース画面を開くと「案内済み」としか書かれておらず、それらが一本の流れとしてつながっていないことがあります。
次の担当者からすると、どこまで確認済みなのか、今回あらためて何を確かめればよいのかが分かりません。結局、FAQを探すところからやり直し、前回と似た確認をもう一度する。
対応履歴は残っているのに、次の対応で使うには情報が足りない。問い合わせ対応では、こういうところにも時間が取られます。
問い合わせ対応のしんどさは、ここにもあります。
ナレッジ登録が後回しになる理由
サポートセンターなど問い合わせ対応の現場では、対応件数が増えても担当者を簡単に増やせるとは限りません。
日々の問い合わせは止まりません。急ぎの確認もあれば、過去のトラブルに似た慎重な対応が必要なものもあります。製品部門や営業、管理部門に聞かなければ返信できない問い合わせもあります。
その中で、「対応履歴をきれいに残しましょう」「ナレッジを登録しましょう」と言われると、現場からはまた作業が増えるように見えます。
問い合わせに答えるだけでも手いっぱいなのに、対応後に毎回きれいなナレッジを登録する。理屈としては分かるが、実際にはそこまで手が回らない。これは、現場の意識が低いから起きている話ではありません。
回答後、担当者には次の問い合わせが来ています。製品部門に確認した内容を整え直し、FAQ向けに書き換え、社内だけで共有すべき注意点と、顧客にも見せてよい説明に分ける。大事な作業ではありますが、対応フローの外側に置かれている限り、後回しになります。
たとえば、問い合わせ対応の画面には、対応結果だけが残っていることがあります。
「案内済み」
「個別対応」
「製品部門確認済み」
こうしたメモは残っていますが、次の担当者が知りたいのはその手前のことです。
「製品部門確認済み」と書いてあるが、確認した理由は残っていない。
返ってきた回答も、次回同じ条件なら確認を省けるのかも分からない。
「個別対応」と書いてあっても、何が個別だったのかまでは読み取れない。
対応結果だけが残っていても、この経緯が抜けていれば、結局また同じ人に聞きにいくことになります。
ナレッジが残らない理由を、「何を残せばいいか分からないから」だけで捉えると不十分です。
多くの場合、問い合わせに答える流れと、次に使える形へ整える流れそのものが分断されています。
ケースログで抜け落ちやすいのは、回答までの意思決定の経緯
過去の問い合わせログを開いても、そのまま次の対応に使えるとは限りません。
ケース画面には回答文が残っていて、「個別対応」という記録もある。ところが、製品部門への確認はチャットで済ませていて、その内容まではケースに戻っていないことがあります。
たとえば、旧プランから新プランへ移行している顧客への回答で、請求担当に確認していたケースがあったとします。
あとからケースを開くと、「個別対応」としか書かれていない。旧プランからの移行が理由だったのか、請求締め日の扱いが通常と違ったのかまでは読み取れません。
次の担当者が知りたいのは、前回どんな文章を返したかだけではなく、その回答にたどり着くまでに何を確認したかです。
AIに担わせる範囲を決める
問い合わせを受けた担当者は、まずFAQを開き、似たケースを探します。
AIにはこの時点で、今回と条件が近い過去ケースを拾い、前回との違いや、そのとき確認していた部署を見えるようにさせます。
たとえば、過去に三つ似たケースが見つかったとしても、請求担当への確認が入っていたのは旧プランからの移行が絡んだ一件だけかもしれません。
今回も同じ条件なら、担当者はそこから確認を始められます。
対応が終わったら、今回新たに分かった条件や確認内容も候補として残します。
正式にFAQへ反映するのか、社内だけで共有するのか。その判断は、あとで人が行います。
一件の問い合わせを、どこまで分解して残すか
たとえば、顧客からこんな問い合わせが来たとします。
「契約途中でプランを変更した場合、今月の請求はどうなりますか」
担当者が過去ケースを調べると、似た問い合わせはいくつか見つかります。
月途中のプラン変更。
旧プランから新プランへの移行。
請求締め日の直前に契約内容が変わったケース。
回答文だけを見ると、どれもFAQを案内して終わっているように見えます。
ただ、ケースコメントやチャットの履歴まで追うと、旧プランからの移行が絡んだケースだけ、請求担当に確認していました。
今回の問い合わせも、その条件に近い。ここまで見えていれば、担当者は請求担当にこう聞けます。
「過去ケースを見ると、通常FAQで返したものもあります。ただ、旧プランからの移行が絡むと、請求締め日の扱いだけ確認していました。今回もそこだけ見てもらえますか」
聞かれた側も、顧客の契約状態や過去の対応を最初から聞き直さずに済みます。
この違いは、返信文を書く時間だけを見ていても分かりません。
短くなるのは、回答文そのものより、その前後にある確認の往復です。
対応後に残すものも同時に仕分ける
対応が終わったケースを、すべてナレッジとして残せばよいわけではありません。
そのまま履歴として閉じるものもあれば、同じ問い合わせが続いているためFAQを修正した方がよいものもあります。
担当者だけが知っておけばよい注意点なら、社内ナレッジに残した方が使いやすい。問い合わせの原因が営業時の説明や導入手順にあるなら、そちらを直した方が早いこともあります。
AIには、対応ログを見ながら、その情報を次にどこで使うかを仮置きさせます。担当者はそれを見て、残すもの、直すもの、今回は残さないものを決めます。
対応後にナレッジ化する作業が別に増えるだけでは、なかなか続きません。対応の流れの中で情報が整理され、必要なものだけが次に使う場所へ戻っていく。
そうして初めて、対応ログが次の問い合わせでも使える情報になっていきます。
成果は、回答までに要した時間だけではない
対応ログの使われ方が変わったかは、次の問い合わせが来たときに見えてきます。
前回の確認理由や回答根拠が残っていれば、担当者は過去ケースを開いたところから確認を進められます。
同じ内容を製品部門へ聞き直す回数が減ったり、詳しい人に相談するときも、背景説明ではなく今回だけ判断が必要な点から話を始められたりします。
問い合わせをきっかけにFAQや営業資料が直され、その後は顧客自身で解決できるようになることもあります。
入社して間もない担当者が、過去ログを見ながら一次返信の方針を立てられるようになれば、そのログは日々の教育にも使えるようになります。
こうした変化は、ケースの処理件数だけを見ていても分かりません。
ケースを閉じたあとに残った情報が、その後どこで使われたか。
問い合わせ対応を改善するときは、そこも追っておきたいところです。
