Amazon Connect 専任担当の丸山です。
今日は予期しないコール量の対応について書きたいと思います。
予期しないコール量といえば、少し前までは「大人気につき注文殺到」「不具合発覚で注文殺到」といった、コール量が増える「要因」があって「結果」としてコール量が増えるイメージでした。
しかし今年からはこれに加えて、「対応可能オペレータが減少」して、1人あたりの対応コール量が増加するケースも考えなければいけなくなりました。
さて、Amazon Connectはスケール対応可能なコンタクトセンターサービスです。
席数に応じた契約や課金体系ではないのです。
コール量がスパイクしても安心です。
とはいっても、インフラだけがスケールしても現実的にお客様対応はスケールしません。
予期しない大量のお問い合わせを適切に対応するために、Amazon Connectが実行できるアクションと対策をまとめます。
基本は有人対応を削減
本ブログでは詳細を割愛しますが、有人対応によらないチャネルの提供やセルフサービス化を図ることが大切です。
対応例
- WEBによる受注・申し込み
- IVRやFAQによる自己解決
- チャットボットによる自動化対応
それでもスパイクする有人対応をAmazon Connectと戦う
ここからは、Amazon Connect でできることをご紹介します。
大量のお問い合わせが増えたらときにできること
大量のお問い合わせが殺到したあとでも、Amazon Connectなら即座に柔軟な対応が可能です。
緊急対応エージェントを追加
Amazon Connect は席数課金ではないため、いつでも電話対応をするオペレーターを増やすことができます。
いつもは別の業務をしている方も電話対応をしていただくことが可能です。
スーパーのレジ応援みたいですね。
対応スタッフを確保できれば何人でも追加可能です。
対応可能な人さえいれば、ですが。
現状をお伝えするメッセージをお伝えする
急激なコール量の増加にはなにかしらの原因があるかと思います。
お電話がつながったときに、最初に混み合っている状況とその理由をご説明すると親切ですね。
Amazon Connectでは自動応答メッセージを誰でも簡単に設定することができます。
お問い合わせ種別に応じたDTMF分岐
急激なコール量が増加すると、その対応に追われ通常のお問い合わせに対応ができなくなってしまいます。
急増した問い合わせと、通常の問い合わせをわけて対応したいところです。
Amazon Connectでは「XXXに関するお問い合わせは1番を〜」といったプッシュボタンによる分岐(DTMF分岐)の利用が可能です。
その場で設定すれば、数分で反映されます。
急増した問い合わせと、通常の問い合わせを分岐させることが可能です。
急増した問い合わせ側がオーバーフローしていても、通常の問い合わせを対応可能な状態とすることができます。
自動応答で対応する
例えば、サーバーワークスの場合はAWSに障害が発生するとお客様からのお電話が急増します。
しかし、AWSの基盤障害の場合は弊社でできることはなく、正しい最新情報を提供しつつ復旧をお待ちいただくようお詫びすることしかできません。
このような対応であれば自動応答でも可能です。
自動応答のメッセージは1つの処理で「3000文字」という上限がありますが、3000文字までの情報をつなげれば事実上無制限の文字数をアナウンスすることが可能です。
簡潔にお伝えしたほうがよいのですが、長めのメッセージもアナウンスできる点をご安心いただければと思います。
SMSを配信する
お客様がご希望いただければ、SMSを配信してURLをご連絡することも可能です。
音声だけでは伝えきれない情報の連絡に最適です。
大量のお問い合わせに備えて事前にできること
大量のお問い合わせが殺到したときのことを想定して、事前に準備できることがあります。
コールバックを提供する
対応できるオペレータがいないときにコールバックを利用することが可能です。
お客様はキューで待機する必要はありません。
エージェントが対応可能になったときに呼び出されます。
コールバックを活用することで、お客様が待機していただかなくて良くなるのはもちろん、接続時間削減すなわちAWS費用削減につながります。
推定待ち時間を提供する
問い合わせフローの中でメトリクスの各種情報を取得可能です。
「キューに保存された問い合わせ」や「キューの最も古い問い合わせ」の情報を利用すればどのくらいお待たせするかお知らせすることが可能です。
待ち時間予想を事前に通知することで顧客満足度を向上させることができます。
また、待ち時間が長い場合はおかけなおしを助言することもできます。
キューの待機数に応じた分岐
キューの待機数が一定以上の場合、おかけ直しをお願いして切断することができます。
強制切断はあまり利用したくない方法ですが、混み合ってしまった場合はこれもひとつの方法ですね。
30分以上ひたすらまたされてイライラするより、わたしはいいと思います。
キュー待機中に情報を提供する
待機中は「しばらくおまちください」といったアナウンスや、音楽をかけておくことができます。
2分おきに「大変おまたせして申し訳ございません」というわりこみアナウスの設定も可能です。
他にも、おまたせしている間に関連するFAQの情報をアナウンスするという活用もできます。
待機中にも自己解決のチャンスですね。
キューのサイズを設定する
キューにはサイズ=キュー内の最大問い合わせ数をオプションで設定できます。
キューに転送する処理の中で、設定したサイズを超えているかどうかによって分岐が可能です。
これにより事前にオーバーフロールーティングを定義することができます。
サービスクォータの管理をする
AWSは各種サービスにサービスクォータが存在しています。
サービスクォータは、Amazon Connect にもあります。
https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/amazon-connect-service-limits.html
下記項目は余裕を持った数値で申請しておくと安心です。
- インスタンスあたりの同時通話数
- インスタンスあたりの同時チャット(チャット利用をする場合のみ)
大量のお問い合わせがきていることを把握する方法
大量のお問い合わせがきていること、お客様をおまたせしているということをタイムリーに把握できるようになっているでしょうか。
メトリクスの監視
リアルタイムメトリクスもしくはリアルタイムメトリクスの情報を参照できるサービスを常に見ていれば、キューの待機数を把握することが可能です。
運用体制によってはそれでも構わないのですが、常にデータを見てるわけではない環境もあると思います。
そういった場合はCloudWatchメトリクスを監視することをおすすめします。
https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/monitoring-cloudwatch.html
例えばQueueSizeを監視すれば一定数以上のキューがたまったときに通知をすることが可能です。
「レジ応援お願いします」の自動アナウンス的なことができますね。
いろいろなメトリクスがあるので、運用に必要なメトリクスを見極めてください。
ほんとうにどうしようもないときは
ここまで、細かい設定を含めた活用法をご紹介してきましたが、どうにもならないときもあるかもしれません。
例えば、通常業務が続けられないほどの事態も想像しなければいけないことをわたしたちは今現実に体験しています。
有人対応を停止する
自動応答アナウンスを読み上げて切断する問い合わせフローを用意し、電話番号に設定すれば有人対応を即停止することができます。
体制が整ったとことですぐに再開することが可能です。
まとめ
Amazon Connect は、ハンズオンの資料などをみて受発信できるところまでであれば誰でもできる簡単なサービスです。
大切なのは運用。そして運用をきちんと見据えた設計です。
今まで体験したことがない緊急事態が発生するかもしれないという現実感をみなさんお持ちかと思います。
変化に対応できる Amazon Connect を上手に活用してシステムで解決できることはサクッと解決していきましょう。