 ライブチャットの運営シリーズ 3回目は、ライブチャットのエージェント数の算出について解説します。 シリーズ1回目で述べたように、ライブチャットの運営は、そのノウハウや方法論が世界的にみても未だ確立していません。 その最たるものが、ワークフォース・プランニング、つまりエージェント数の算出です。 同時セッションの存在やAHT（平均処理時間）の測定が困難なことがそう言わしめているのですが、だからといって、いつまでもアバウトなエージェント配置のままで済むはずがありません。 そこで、コールセンターの教科書プロジェクトでは、ライブチャットのエージェント数の算出のための考え方をまとめ、その算出モデルをここに公開します。 ライブチャットのコンタクト数を予測する エージェント数を算出するためには、その元となるライブチャットのコンタクト数の予測が必要です。 ライブチャットをどのように運用しているかによって、発生の要因となる情報やデータが企業によって異なることを除けば、電話と同様に、回帰分析や時系列分析などの手法を使ってコンタクト数の予測ができます。 具体的には、『コールセンター・マネジメントの教科書』第3章や、Bizコンパスの連載記事「世界の先進コールセンターが実践する業務量予測法とは」をご覧ください。 ライブチャットはサービスレベル・コンタクト 多くの人が、ライブチャットを「レスポンスタイム・コンタクト」（注1）と誤解しています。 おそらく、ライブチャットがテキストによるコミュニケーションであり、メールに似ていることによるものでしょう。 ライブチャットは、明確に「サービスレベル・コンタクト」です。 なぜなら、ライブチャットに対する顧客の最大の期待は、「早くて簡単であること」だからです。 おそらく顧客はライブチャットに対して、電話以上に “待たされる”という発想はないでしょう。 したがって、ライブチャットのオペレーションの第一義的な使命は、「受信したライブチャットに迅速に応答する」ことであり、電話と同様にサービスレベルを設定して、アーランC式によりエージェント数を算出します。 では、ライブチャットのサービスレベルはどれくらいに設定すればよいでしょうか。 現状では日本にはその事例が皆無なので、欧米の例を見てみましょう。 「コールセンターの教科書コラム」の昨年の記事「閲覧注意！サービスレベルの標準値」で紹介した、英国のオンライン・コールセンター専門誌の発表（注2）によると、ライブチャットのサービスレベルは、「80% of Live Chat answered within 40 second」、つまり受信したライブチャットの80%は40秒以内に応答するというものでした。 日本の場合、現状では一部の企業を除きライブチャットのボリュームが少ないため、大半が「受信＝即応答」の状況にあります。 したがって、あえて80/40に下げる必要はないでしょうが、今後のライブチャットのコンタクト数の予測を見て、自社にとって適切なサービスレベルを設定してください。 同時セッション数を設定し、処理ユニット数を求める アーランC式でエージェント数を算出する際に考慮しなければならないのが、同時セッション数（CNC）です。 必要なのは、ライブチャットのシステムにあらかじめ設定している「最大同時セッション数」（Maximum CNC）ではなく、オペレーションの実績に基づく「平均同時セッション数」（Average CNC）です。 平均同時セッション数もライブチャットの運用の仕方によってさまざまな影響を受けるため、きっちり正確に計算するのは困難ですが、通常は下記の計算式により、エージェント数の算出に使えるレベルの平均同時セッション数を求めることができます。  「合計ライブチャット処理時間」（Total Live Chat Handle Time）は、特定の時間帯に処理したすべてのライブチャットの応対時間（電話の通話時間に相当）、保留時間（ライブチャット応対中のサイレントやインアクティブなどの時間）、後処理時間の合計時間です。 言い換えるなら、特定の時間帯に処理したすべてのライブチャットのAHT（平均処理時間）の合計ということになります。 「合計ライブチャット・エンゲージメント時間」（Total Live Chat Engagement Hours）は、特定の時間帯にエージェントがライブチャットのオペレーションに従事した合計時間です。 アーランC式の計算には、コンタクト数が必須ですが、チャットの場合、同時セッションを考慮した件数であることが必要です。 それが「処理ユニット数」で、同時に処理したライブチャットのセッションを1つにまとめた“みなしコンタクト数”のようなイメージで、下記の計算式により求めることができます。 アーランC式でつｋあうた使うために、データの単位は1時間とします。  処理時間をどう測るか アーランC式の計算要素として不可欠な処理時間（平均処理時間または合計処理時間）ですが、同時セッションをはじめ、タイムアウト、サイレント、フェイルオーバーなど（それぞれの定義は前回および前々回の記事をご覧ください）の存在が、正確な測定を困難にしています。 現状のライブチャットのオペレーション・システムは、1つひとつのセッションごとにタイムアウトなどの要因を考慮した処理時間をレポートするまでには至っていません。 そのような現状において、少しでも実態に近い処理時間を測定するためには、タイムアウトなどの発生や終了などのタイミングと対処方法をすべてルール化しておくことが必要です。 例えば、最後のアクションから5分経過してもサイレント状態の場合はセッションを終了するといったことです。 すべてのセッションを統一のルールに基づいて運用することで、システムからレポートされる処理時間を、単なる数値でなく“データ”としてエージェント数の算出に利用することができます。 そうして正確な処理時間が得られたならば、平均処理時間にコンタクト数を乗じて合計処理時間を求め、それを処理ユニット数で割って「平均ユニット処理時間」を算出します。処理ユニット数1件あたりの平均処理時間というイメージです。 チャット・コンタクトのエージェント数算出モデルでは、通常の平均処理時間に替わって、この「平均ユニット処理時間」を使います。 ライブチャットのエージェント数算出モデル 以上のようにして求めたサービスレベルや処理時間などの要素に基づく、アーランC式によるライブチャットのエージェント数算出モデルを以下に示します。  この算出モデルにより求めたエージェント数が“完ぺきに正確”というわけにはいきませんが、現状のライブチャットのオペレーションをめぐるさまざまな環境や条件のもとでは、これが最も有効に利用できるツールです。 ※筆者が講師を務める「コールセンターの業務設計講座 ～リソース・マネジメント編～」では、ライブチャットの測定指標やエージェント数の算出方法に関する詳しい解説をおこないます。上記の算出モデルのExcelワークシートを入手することができます。ご興味のある方はぜひご参加ください。 次回は5月30日（木）に大阪（マイドームおおさか）で開催します。詳細はこちら
注1： メール、Web問い合わせフォーム、Fax、レターなどのように、処理の形態が連続作業であり、ワークロード人数算出モデルによる要員算出をおこなうコンタクトのこと
注2： Call Centre Helper “How to Design a Contact Centre for Important Customers” 2018 熊澤伸宏（文／Vol.23） コメントはクローズされています。
|
RSS フィード
