【第11回】顧客コンタクトの新たな主役、ライブチャットのエージェント数の算出法

ECなどWeb起点の顧客コミュニケーションの進展にともない、電話からライブチャット（注）へのシフトが加速しています。ボリューム的には、まだまだ電話を凌駕するほどではありませんが、近い将来には電話と並ぶメインのコンタクトチャネルとして、欠かせない存在になることは間違いありません。

ただし現状では、その運営手法やノウハウが確立されておらず、大半が自己流のアバウトな運営に留まっています。その最たるものが、エージェント数の算出を始めとするワークフォース・プランニングの分野です。

なぜなら、ライブチャットをメインに活用するのが、ECやWebのサポートを担うWeb担当者（コールセンターやカスタマーサービス畑でない、いわゆる“Web屋さん”）であること、また、スタートアップなど小規模のビジネスがほとんどのためボリュームが少なく、専門知識やノウハウがなくても大過なく“済んでしまう”からなのです。

また、ライブチャットは、いつでも自由にセンター側の都合で受付を遮断（Webサイト上のライブチャットのウィジェットの表示を停止したり、ライブチャットの案内自体を消してしまう）できることが、そのことに拍車をかけています。
例えば、予想を超えるライブチャットのコンタクトが集中し、エージェントの人数が足りず処理しきれない場合、Web上のライブチャットのウィジェットを消すことができます。いい加減なスタッフィングをしていても、これができることで、自分たちのオペレーションは混乱をきたさずに済ませることができるのです。
これでは、わざわざワークフォース・プランニングの専門知識を学び、厳密なスタッフィングをしようなどとは考えないのも当然でしょう。

しかし、いつまでもその状況に甘んじているわけにはいきません。

2018年に実施された米国のベンチマーク調査では、顧客のライブチャットの21％に、企業が応答していないという現実が明らかにされました。
残念なことに、日本でも、ライブチャットが一向につながらない某有名企業の大型センターの存在が知られています。

そんなことにならないよう、今のうちからライブチャット運営の起点であるエージェント数の算出の方法論を確立させて、顧客のニーズにしっかり対応できる態勢を整えておく必要があります。

注：　本稿では「チャット」でなく「ライブチャット」と表記します。欧米では、名前は似ていても、性格の異なるまったく別種のチャネルである「チャットボット」と区別するために、ライブチャット（またはWebチャット）という呼び方が一般化しています。日本では、本質を理解しないまま両者を同類のチャネルとして扱い、ライブチャットのことを“有人チャット”、チャットボットのことを”無人チャット”などと表記する向きが多く見られますが、誤解と混乱を助長するそのような表現は避けるべきでしょう。


◆ まずはライブチャットのコンタクト数を予測する

最適なエージェント数の算出のためには、まずは、その元となるライブチャットのコンタクト数を正確に予測することが必要です。

これについては、ライブチャット独自の方法論があるわけではなく、電話のコール数の場合と同様に、ヒストリカルデータ（過去の実績）やビジネスドライバー（将来のコンタクト数に影響を与える何らかの要因）の情報を利用して、回帰分析や時系列分析などの統計手法により予測することができます。

詳しくは、第3回および第4回の記事で解説しています。

なお、ビジネスドライバーの情報として、Webサイトのビジター数等のデータから、ライブチャットの発生数や発生割合等を分析することができますので、WebマスターやWebの分析担当者のサポートを仰ぐとよいでしょう。


◆ ライブチャットは「サービスレベル・コンタクト」

第9回の記事で、エージェント数を算出するコンタクトのタイプを、「サービスレベル・コンタクト」と「レスポンスタイム・コンタクト」のいずれかに分類する必要があることを説明しました。それによって、エージェント数の計算方法が異なってくるからです。

ライブチャットについては、テキストで会話をするという“見かけ”から、メールと同類と考え、レスポンスタイム・コンタクトだと誤解している人が多くいますが、そうではありません。

ライブチャットは、議論の余地なく、サービスレベル・コンタクトです。

なぜならライブチャットは、着信がランダム（不規則）であること、応答したら即処理する必要があること、コンタクト数の繁閑によってエージェントの待機時間が発生すること、コンタクトの発生（タイミングやボリューム）を企業側の意思でコントロールできないこと、といった特性を持つからです。

そして何よりも、ライブチャットに対する顧客の最大のニーズが、“速くて簡単なこと”だからです。

つまり、電話と同じように、着信したライブチャットに迅速に応答すること＝応答スピードがとても重要だということです。そのためにサービスレベルの目標値を設定し、アーランC式を用いて、予測したコンタクト数に応じた最適なエージェント数を配置します。

アーランC式によるエージェント数算出については、第６回の記事で詳しく解説しています。


◆ ライブチャットの用語や単位を定義する

ライブチャットは、その運営手法やノウハウが確立していないため、用語や単位の定義が定まっておらず、使い方がまちまちです。特に、同時セッションの存在が、ライブチャットの件数や処理の単位の捉え方を複雑にし、混乱を招いています。

そこで本稿では、無用な誤解を避けるために、用語や単位の定義を図１のように定めました。

◆ ライブチャットのエージェント数算出モデル

ライブチャットはサービスレベル・コンタクトですから、エージェント数の算出にはアーランC式を使います。
表１がその算出モデル「ライブチャット・エージェント・カルキュレーター」です。

このモデルで計算するためには、「新規チャット・リクエスト」「サービスレベル」「平均同時セッション」「マルチセッション」「平均処理時間」の5つのパラメーターの設定が必要です。

それぞれを、どう設定したり反映すればよいのか、パラメーターごとに説明します。

(1) 新規チャット・リクエスト

顧客が新規にライブチャットのリクエストをした件数（図１の®）です。電話（インバウンドコール）の「着信コール数」とは異なり、エージェントが応答して進行中のチャットセッションにおけるチャット（図１のA1以降）は含まず、新規のリクエストに限ることに注意してください。

また、顧客の新規のリクエストにエージェントが応答しない「不応答」が発生した場合は、それも除きます。
不応答には、顧客による「放棄」やエージェントによる「受付拒否」があります。

これらを除いた、実際にエージェントが応答したリクエストである「新規チャット・リクエスト応答数」が、エージェント数算出の起点となります。
ちなみに、「新規チャット・リクエスト応答数」＝「チャットセッション数」と言い換えることができます。

(2) サービスレベル

サービスレベルの考え方は電話の場合とまったく同じです。では、その目標値はどう設定すべきでしょうか。

2019年に欧米を中心とする世界250超のコールセンターを対象に行われた調査によると、他のチャネルと比べて、ライブチャットのサービスレベルは80%から100%、および20秒から60秒の範囲で分散しており、業界標準と呼ぶことのできる値を特定するのが困難な結果となっています。
強いて言うならば、わずかの差ですが、最頻値が20秒以内／80％以上であり、平均値が30秒以内／90％以上となっています。

このことから、ライブチャットのサービスレベルは、限りなく電話に近い目標値が設定されていることがわかります。ただし、いくつかのベンチマークデータを見る限り、その実績は目標値に遠く及ばないのが現状です。

一方、日本では、一部の大規模センターでライブチャットが一向につながらないといった状況が見られますが、大半のセンターは即応答、つまりサービスレベルはほとんど100%近い状況にあります。
ただしそれは、科学的で質の高いマネジメントの成果というわけではありません。大半のセンターのライブチャットのボリュームが少ないこと、および、ライブチャットの窓口を自由にクローズできることによるものであることを認識しておかないといけません。

その上で、今後のボリューム増加と顧客の期待を鑑みて、適切なサービスレベルを設定する必要があります。

(3) 平均同時セッション数

1人のエージェントが、同時に複数のライブチャットに応答することを「同時セッション」と言います。

また、業務の難易度や回答の品質、エージェントのスキルなどを考慮して、ライブチャットのシステムにあらかじめ設定する同時セッションの最大値のことを「最大同時セッション数」と言い、実際にオペレーションした結果の同時セッションの平均値のことを「平均同時セッション数」と言います。

エージェント数の算出に必要なのは、平均同時セッション数の方で、エージェントの業務量と必要人数を決める重要な要素となります。

ライブチャットのシステムやアプリから、平均同時セッション数のデータが得られない場合は、厳密に正確とは言えませんが、下記の計算式（表１の下部）によってエージェント数算出に使えるレベルの平均同時セッション数を求めることができます。

平均同時セッション数＝チャットセッション合計処理時間 ÷ チャット業務ログイン時間

​「チャットセッション合計処理時間」とは、チャットセッションにおける「エージェントの応答時間」「顧客の応答時間」「キュー時間」の合計時間です。

「応答時間」とはチャットの書き込み（入力）をしている時間のことです。

「キュー時間」とは、同時セッションが発生している際に、顧客がエージェントのレスポンスを待っている時間のことを指します。顧客がキュー状態にある時、エージェントは他の顧客の応対をしているか、自分宛てのメッセージを入力しているかのいずれかです。

「チャット業務ログイン時間」とは、エージェントがライブチャットのオペレーションを行うためにライブチャットのシステムやアプリにログインした実績時間の合計です。

なお、同時セッションの機能を利用していない場合は、表１の「平均同時セッション数」を「１」としてください。

(4) マルチセッション数

ライブチャットには同時セッションがあるため、「新規チャット・リクエスト応答数」に「平均同時セッション数」を反映した「マルチセッション数」を使います。

「マルチセッション」とは、1人のエージェントが同時に処理した複数のチャットセッションをまとめて1件のチャットセッションと見なすイメージで、下記の計算式により求めます。アーランC式で使うために、通常は1時間単位とします。
​

１時間あたりマルチセッション数＝１時間あたりチャットセッション数 ÷ 平均同時セッション数

(5) 平均処理時間

最も厄介なのが、チャットセッションの平均処理時間をどう測定するかということでしょう。

ライブチャットには、顧客がチャットセッションの途中で会話を中断、放置、あるいは放棄する（これらを総称して「タイムアウト」と言います）という特有の事象が存在します。これらは顧客の一方的な行為のため、エージェントは状況がわからないまま、顧客のレスポンスを待ち続けます。顧客はすでにライブチャットの会話をやめているのに、チャットセッションは継続したままになっているということです。このことが、チャットセッションの終了の判断を曖昧にし、処理時間の正確な測定を困難にするのです。

ライブチャットのシステムやアプリからは、エージェントの操作に基づく単純な意味での処理時間しか提供されないので、少しでも実態に近い処理時間を測定するには、タイムアウトの定義を具体化し、終了のタイミングをルール化することが必要です。

例えば、顧客に最後にチャットメッセージを送信してから20分経ってもレスポンスがない場合、その時点で強制的にチャットセッションを終了する、といったことです。

重要なのは、それをエージェント個人の判断に任せるのでなく、統一したルールとして運用することです。バラバラなやり方では、どんなに多くのデータを集めてもエージェント数算出の使い物にならないからです。
一部のライブチャットのシステムやアプリでは、タイムアウトの定義を設定して判断を自動化できるものがあります。

以上のことを踏まえた上で、下記の計算式により「マルチセッション平均処理時間」を算出します。
ライブチャットのエージェント数を算出するには、個々の「チャット」や「チャットセッション」ではなく、「マルチセッション」の平均処理時間を使います。
​

マルチセッション平均処理時間 ＝（チャットセッション平均処理時間 × １時間あたりチャットセッション数）÷ マルチセッション数

​ちなみに、同時セッションの機能を利用しない場合、「チャットセッション平均処理時間」は、同時セッションを利用する場合より短くなります。図１にそのシナリオを示しています。

「チャットセッション１」は、3パターンとも、構成する個々の「チャット」の処理時間は同じです。しかし、同時セッションをすることによって、「キュー」が発生します。その分、チャットセッションの処理時間が長くなるというわけです。同時セッション数が増えれば、キューの時間も長くなり、チャットセッションの処理時間はさらに長くなります。

処理時間が長くなるということは、エージェント数の増加圧力が高まります。異なる顧客の混同など、エラーのリスクも高まります。“同時セッションができるから、チャットの方が電話より効率的”という単純な論調を鵜呑みにせず、しっかり測定・検証した上で、同時セッション利用の判断をする必要があります。


以上の説明を踏まえて、表1の算出モデルを利用してください。

現在のところ、他に同様のモデルは存在しません。これで完ぺきというわけにはいきませんが、現状ではこのモデルが唯一、合理的かつ科学的で、最も有効に利用できるツールだと言えます。

このモデルは、こちらの専用ページからダウンロードして利用することができます。


（Original: 2019年9月30日 - Last modified: 2022年1月30日）

---

この記事はNTTコミュニケーションズ社が運営するビジネスマガジンサイト「Bizコンパス」（現在は非公開）に、「AI時代を生き抜く「本物」のコールセンター運営法」として連載した寄稿を、同社の許諾により転載したものです。なお、同サイトへの掲載時点とは異なる情報や文言表記について、オリジナルの内容を損なわない範囲で更新している場合があります。