 仕事柄、いろいろな企業のコールセンターを訪問する機会があります。
初めての訪問の場合、まず、その企業やコールセンターの説明を受けることになりますが、 その際にいつも、日本企業と欧米企業との大きな違いを感じています。 それは・・・ 欧米企業では、必ずと言って良いほど、最初に組織図を見せられます。 組織図を見ながら、業務の概要などの説明を受けるのです。 欧米企業は、仕事の在り方と組織の形状が合致しており、矛盾がありません。 また、一人一人のスタッフの職務（役割、機能、権限）が明確で、それらがそのまま組織図に反映されています。 したがって、組織図を見れば、その企業やセンターがどのように仕事をし、 チームや個人がどんな役割や責任を担っているかを一目瞭然で理解できるのです。 一方、日本企業の場合は、組織図を見せられることはありません。 リクエストしても、すぐには出てきません。 なぜなら、「組織図なんて作ってない」からです。 それならばと作成をお願いしても、その出来上がりは、組織図というよりも「人員一覧表」程度でしかありません。 それを見ただけでは、仕事の概要はおろか、時には部署名すら曖昧でよくわからないのです。 とてもトレーニングや第三者への説明に使える代物ではありません。 どうしてそうなってしまうのか尋ねると、「いろいろあるから」だそうです。 例えば、人事上の上司部下の関係と実務上のそれとが異なっていたり、恒常的な業務と単発のプロジェクトとの区別がついていなかったり、管理職でないのにSVと称してエージェントの業績評価をしていたり・・・など、 「いろいろ」は枚挙にいとまがありません。 これでは、組織図が書けないのも無理はありませんね。 こうなってしまう原因は、日本企業の組織が仕事と連動していないことにあるように思います。 属人的、とよく言われるように、日本企業の多くは、仕事でなく人を起点に組織や仕事の分担が決められるため、一つ一つの仕事の役割、機能、権限などが明確にされず曖昧です。 明確でなくても、集団で助け合って仕事をこなしていくので、それで済んでしまうのです。 ちなみに日本企業でジョブ・ディスクリプション（職務記述書）が滅多に作られないのは、そのためです。 伝統的な一般事務系オフィスワークなら、それで済むかもしれませんが、 多くの人材を抱え、一貫性を旗印に組織で仕事をするコールセンターにとっては、まさにそのことが致命傷になります。 組織図が描けない組織には、例えば次のような症状が表れます。
こんなやり方で仕事をしている限りは、組織図なんて必要ないし、描こうと思っても描けないのです。 このように見ると、コールセンターにとっての組織図とは、組織がしっかり機能しているか、そうでないかを示すバロメーターだと言えそうです。 熊澤伸宏（文／Vol.26）
0 コメント
 これまで3回にわたり、ライブチャット運営の勘どころについて述べてきました。 今回は、まだまだ誤解の多いライブチャットの運営を“正しく”おこなうために、必ず理解しておきたい鉄則を5つにまとめてシリーズの締めくくりとします。 鉄則その1――ライブチャットは電話を減らすためのものではない 多くのコールセンターが、ライブチャットの導入により“電話を減らす” ことを目的としています。 電話による問い合わせをライブチャットに置き換える ⇒ 電話のエージェント数を減らす ⇒ コストを削減する という理屈なのでしょうが、これが誤りの第一歩です。 ライブチャットを導入する本当の目的は、新たな顧客層を獲得することです。 新たな顧客層とは、「ミレニアル世代」「デジタルネイティブ」などと呼ばれる若年層のことです。 彼らは電話やメールよりもライブチャットを好みます。その方が簡単で早く済むからです。 新しい顧客を増やすわけですから、顧客とのコンタクトは減るどころか増えるのです。 つまり、これまで電話やメールをメインに使ってきたコールセンターがライブチャットを導入することで、彼らとのコンタクトの機会を増やすことができるのです。その結果、セールスの拡大やサービスの強化につながります。 これがライブチャット導入の本質です。 ちなみに、“チャットの導入で電話が減った”という話を耳にします。 それは、企業の側が、顧客に電話よりもチャットを使うよう誘導、あるいは強制するからです。 顧客に選択肢を与えずに、“チャットが支持された”“チャットが電話の代替を果たしている”などと評価するのは、あまりに滑稽と言わざるを得ません。 鉄則その2――むしろ電話よりも高い “チャットは同時セッションができるからエージェント数を減らせることができ、その分人件費が安く済む”と言われますが、それはカスタマーサポート系の一部に限った話であり、大半の、特にカスタマーサービス系のコールセンターには当てはまりません。 なぜなら、ライブチャットの平均処理時間（AHT）は、電話よりも長くなるからです。 ただでさえ電話よりも長いのに、同時セッションにより、AHTはさらに長くなります。同時セッションが2件の場合、一般的にAHTは電話の2倍の長さになります。 単純に考えれば、同時セッションが2件でAHTが2倍ということは、結局のところ電話もライブチャットも必要なリソース（エージェント数や人件費）は変わらないことになります。 また、同時セッションが増えるとエラーが増すなどして、顧客満足が低下することもわかっています。 それをリカバーするための対策を講じる必要があり、そのための追加のコストが必要となります。 そのことも踏まえて、カスタマーサービス系のセンターでは同時セッションは最大2件まで、カスタマーサポート系のセンターでは3件までとするのが一般的です。 さらに、単純定型的な問い合わせが、電話からライブチャットへシフトすることにより、電話には高度で難解、あるいは時間のかかる問い合わせが集中するようになります。そのために、電話のエージェントのトレーニングやナレッジベースの強化、優秀な人材の確保など、新たな投資が必要になります。 これらを考え合わせると、ライブチャットの導入は、コストの増加圧力を高めると考えるべきです。 ※鉄則その2については、ライブチャットの運営シリーズ第2回「本当に電話はチャットより安いのか」も合わせてご覧ください。 鉄則その3――置き換えるのでなく使い分ける 電話／人／コストを減らすというのは、電話をライブチャットに“置き換える”という発想です。 が、それができるのは、“正解を回答する”ことを目的としたカスタマーサポート系の単純定型的な問い合わせに限られます。顧客と“コミュニケーションする”ことを目的としたカスタマーサービス系の問い合わせをライブチャットに置き換えるのは極めて困難です。 これは、両者のコミュニケーションツールとしての性格や使い方が異なることを意味します。それぞれを好む顧客層も異なります。タイプや顧客層が異なるのですから、両者を置き換えることはできないということです。 つまり、置き換えるのでなく、“使い分ける”と考えるべきなのです。 ライブチャットは、“正解を回答する”ことを目的としたカスタマーサポート系の単純定型的な問い合わせにフィットし、その手軽さやスピーディーさから若年層に好まれます。 電話は、“顧客とコミュニケーションする”ことを目的としたカスタマーサービス系の問い合わせに最適なのは言うまでもありません。 ただし、ライブチャットがカスタマーサービス系のコールセンターでまったく使えないというわけではありません。 メインのツールにはなり得ませんが、テキストや画像、URLの送信など、電話を補完するツールとしては大変有効に機能します。 鉄則その4――単純二択のポスト・チャット・サーベイで満足度は測れない ライブチャットの運営シリーズ第1回「ライブチャットの測定指標」で、ライブチャットのマネジメントに必要な24の指標を示しました。 そのうち経営レベルで最も重要と言えるのが、顧客満足度（C-SAT）でしょう。 おそらく、ライブチャットを利用する企業のほとんどが、C-SATを見ていると思われます。 というのは、ライブチャットは「ポスト・チャット・サーベイ」（問い合わせ完了後におこなうアンケート）が大変やりやすく、ほとんどすべてのライブチャット・アプリにその機能が備わっているからです。 そして、そのほとんどの結果が、満足度90%を優に上回っています。そのため、どの企業もその結果を喧伝することになります（どのサイトを見ても満足度が高いのはそのためです）。 そうなるのは、ライブチャット・アプリのアンケートは、そのほとんどが、Yes／Noの単純二択式だからです。 しかし、その方法で得られた回答をもって顧客満足度を評価するのは、あまりに乱暴です。 前述のようなライブチャットの性格などを考えれば、単純二択の設問で得られる回答は、用件が“完了したか、しなかったか”の結果に過ぎないと解釈すべきです。 さらに、ライブチャットの特徴として、不満足な顧客はライブチャットの応対が完了する前に離脱しており、ポスト・チャット・サーベイでは、不満足度が反映されないことも認識すべきです。 鉄則その5――ライブチャットはサービスレベル・コンタクト ライブチャットは「サービスレベル・コンタクト」（注1）です。 テキストによるコミュニケーションという見かけから、メールと同類とみなし、その運営、特にワークフォース・マネジメントをメールと同じく「レスポンスタイム・コンタクト」（注2）としておこなうセンターが大半と言ってよいほど、理解が不足しています。 それでも日本では、まだライブチャットのボリュームが少ないため、結果オーライの状況にありますが、今後のボリューム増を考えると、このままでは立ち行かなくなるのは火を見るより明らかです。 昨年おこなわれた米国のベンチマーク調査では、顧客によるチャット・リクエストの何と21%に企業からの応答がないという悲惨な状況が浮き彫りになりました。 実は日本でも、いくつかの大型センターで、“つながらないチャット窓口”が出現しています。 かつての電話と同じことを繰り返さないよう、サービスレベル・コンタクトによるマネジメントの理解と実践が急がれます。 ※サービスレベル・コンタクトによる要員数算出については、ライブチャットの運営シリーズ第3回「ライブチャットのエージェント数を算出する」 をご覧ください。
注1： ランダム着信、同期コミュニケーション、即時処理、待機時間の発生、処理の重なりが発生といった性格を持つコンタクトタイプのこと。ワークロード人数よりも多くの要員数が必要で、アーランC式により人数を算出する
注2： 非同期コミュニケーション、連続処理という性格を持ち、コールセンターによるコントロールが可能。ワークロード人数と要員数が等しい 熊澤伸宏（文／Vol.24）  ライブチャットの運営シリーズ 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）  “チャットは電話よりコストが安い”と言われます。 本当にそうなのでしょうか？ 日本よりも数年早くチャットが普及した欧米のコールセンターでは、3～4年前にこの種の議論や検証が盛んにおこなわれ、一定の共通認識が出来上がっています。 ところが日本にはその知見がほとんど紹介されず、未だに多くの企業が “コスト削減” を目的としてチャットの導入を進めています。 誤った期待と使い方によって、せっかくのチャットの導入が失敗とならないよう、欧米の知見を紹介しながら、チャットのオペレーションの本質や考え方などについて考察します。 ぜひ、前回の記事「チャットの測定指標」もあわせてお読みください。 なお、ここで言うチャットとは「ライブチャット」のことです。 AIと並んで大流行の「チャットボット」は、日本ではライブチャットと同類のものとして語られますが、両者はまったく異なるツールですから混同しないようにしましょう。 チャットの方が安いと言われる理由と条件 “チャットの方が電話より安い”と言われるのは、チャットの場合、1人のエージェントが同時に複数のチャットの応対をすることができる――その分、チャットのオペレーションに必要なリソース（エージェント数）が少なくて済む――という理由からです。 このことに、コストや人員抑制の切り札として、採用難に喘ぐ日本のコールセンターが飛びついたというわけです。 確かに「同時セッション」（同時に複数のチャットの応対をすること）は、電話にはないチャットの大きな特徴です。しかし、それが額面通りの効果を発揮するのは、以下のようなシンプルな問い合わせの場合に限られます。 顧客の問い合わせ：「ウインドウを閉じる方法を教えてください」 エージェントの回答：「右上のX印を押してください」 この例のように、エージェントがあれこれ考える必要がなく、即時に明確に回答できるシンプルな問い合わせであれば、定型文のコピペで済ませるなど短時間で機械的に処理することも可能です。 だからこそ同時セッションができるのであり、このような性格から、チャットは機器の操作方法やアプリの使い方といった「カスタマーサポート系」のコールセンターで効果を発揮してきたのです。 このことが、チャット・アプリのプロバイダーやメディアにより、チャット導入のメリットとして喧伝されてきたというわけです。 同時セッションにより、AHT（平均処理時間）が増加する 同時セッションは、以下の理由によりチャットのAHTの増加をもたらします。
上述のカスタマーサポート系のコールセンターの問い合わせの場合は、内容がシンプルなためAHTの増加の影響は少なくて済み、その結果、同時セッションによるエージェント数の抑制がコスト削減効果をもたらします。 ところが、内容が多種多様で、「回答する」ことよりも顧客と「コミュニケーションする」ことが求められる「カスタマーサービス系」のコールセンターでは、事情が異なります。 欧米のコールセンターの経験値や調査によると、カスタマーサービス系のコールセンターでは、同時セッション数が2件の場合、AHTが電話の2倍になるというのが一般的な認識となっています。 3件、4件と同時セッション数が増えれば、AHTの増加の度合いはさらに高まります。 これは、AHTが倍増することで同時セッションによるエージェント数の抑制効果が失われることを意味します。 同時セッションを増やすと顧客満足が低下する 同時セッションは、AHTだけでなく顧客満足にも大きな影響を及ぼします。 欧米の多数のコールセンター・マネージャーは、顧客満足を損なわない同時セッション数の上限を、2または3件と考えています（注1）。 これは、同時セッション数が2または3件を超えると顧客満足が低下すると言い換えることができます。 なお、2件とするセンターの大半はカスタマーサービス系で、3件とするのはカスタマーサポート系が多くを占めているのはわかりやすいところです。 企業側としては、同時セッション数を増やしてコスト削減効果を高めたいところではありますが、それによって顧客満足の低下を招いては元も子もありません。 欧米でも、チャット導入の初期は同時セッション数の増加に腐心していましたが、現在では顧客満足が判断基準となっています。 その結果、カスタマーサービス系では2件、カスタマーサポート系では3件とするのが、現状の共通認識となっています。 ちなみに英語圏でこうなのですから、日本語を使う国内コールセンターの場合は、AHTの観点からも顧客満足の観点からも、より厳しい見方をする必要がありそうです。 チャットの導入は電話を減らすことに非ず チャットを導入しようとするコールセンターの多くが「電話を減らしてコストを削減する」ことを目的として掲げますが、それは大きな誤りです。 なぜなら、そう考えるコールセンターは、電話を好む顧客層とチャットを好む顧客層が異なるという認識を欠いているからです。 チャットの導入により電話が減ったように見えるのは、企業が顧客にチャットへのシフトを強制するからです。 それによって、電話を好む顧客は黙って去っていきます。いくらかの顧客はやむなくチャットを使うものの、決して積極的ではありません。その多くは満足度が下がっています。 もちろん、アプリの操作方法やクレジットカードの残高照会、通販の送料確認のようなシンプルな問い合わせの場合は、多くの顧客が電話よりもチャットを使うようになるでしょう。 しかし、それによって電話には高度で難解、あるいは相談型の時間がかかる問い合わせが集中するようになり、エージェントのトレーニングやナレッジベースの強化、質の高い人財の確保などのための新たな投資やコストの増加が必要となります。 このような本質を見逃して、表面的なコール数の減少を評価するのは、あまりに短絡的と言わざるを得ません。 よく知られているように、チャットを好んで利用するのは「ミレニアル世代」「デジタルネイティブ」などと呼ばれる若年層です。 チャットの導入に積極的に反応するのはこの世代であり、彼らの参入は、それまでコンタクトのなかった新しい顧客層の開拓をもたらすことになります。また、オムニチャネルの活性化にも貢献します。 これがチャット導入のビジネス上の本質的な目的であり、コスト削減とするにはかなりの違和感があることに気付いていただけることでしょう。 以上、AHT、顧客満足、顧客層という3つの観点から、チャットのコストや目的について考察をおこないました。 「人手とコストがかかる電話から、安くて簡単に済むチャットにしたい」といった安易な考えでは、決して目論見通りに行かないであろうことを、ご理解いただけたでしょうか。
注1： 例えば、Call Centre Helper Webinar Poll –Best Practices for Voice, Email and Webchat. September 2015によれば、顧客満足を損なわない同時セッション数は2件（45%）と3件（39%）で大半を占め、4件超は7%に過ぎない
熊澤伸宏（文／Vol.22）  コールセンターの“チャットシフト”が加速しています。 顧客とのコミュニケーション起点のWebサイト化、オムニチャネルの進展などによって、もはやチャット無しには顧客の支持を得られない状況になってきたからです。 しかしながら、その運営手法やノウハウが確立されていない（日本だけでなく世界的に）ため、チャットのオペレーションの現場は、意図してコントロールされている状態とはとても言い難いのが現実です。 とりわけ、科学的管理の実践に不可欠なKPIなどの測定指標が定まっていないことが、その大きな理由として挙げられるでしょう。 そこで、コールセンターの教科書プロジェクトでは、ライブチャット（注1）の業績評価、運営管理のための測定指標を整理し、代表的な24の指標にまとめました。 以下ではまず、ライブチャットの特徴を挙げ、そのうえでライブチャットに特徴的かつ代表的ないくつかの指標について説明し、最後に24の指標を紹介します。 ライブチャットの特徴 ライブチャットは、「ランダム着信」「即時処理」「キューイング」「ワークロードをコントロールできない」といった環境から、「サービスレベルコンタクト」のひとつであり、電話（インバウンドコール）に似ています。 しかし、以下に示すようなライブチャット特有のユニークな特徴があることで、電話のマネジメント手法をそのまま流用することができません。
最大のニーズは「簡単で速いこと」 ライブチャットの利用者の主役は「ミレニアル世代」「デジタルネイティブ」などと呼ばれる若年層です。 電話やメールを敬遠し、LINEなどのインスタントメッセージングをコミュニケーションのメインとする彼らは、企業とのコンタクトにおいても、最も簡便で即時の回答が期待できるライブチャットを最も好みます。 したがって、「迅速性」と「簡便さ」が担保できなければ、途端に彼らの支持を失うことになります。 となると、ライブチャットの導入によって「ミレニアル世代」の新しい顧客層の獲得を目論んでいた企業の思惑も外れてしまいます。 そのため、企業は「迅速性」を担保できるオペレーションの態勢を整え、「簡便さ」を提供できるサイトの機能強化を図ります。 そして、それらのパフォーマンスをモニターするための指標として、「平均初回レスポンス時間」（Average First Response Time; FRT）や「初回チャットコンタクト完了率」（First Chat Contact Resolution; FCR）および「サービスレベル」（Service Level; SL）で「迅速性」を管理します。 「FRT」は電話でいうところの「平均応答時間」（Average Speed of Answer; ASA）に相当します。 「FCR」と「SL」は電話でおなじみの指標と同じです。 また、「簡便さ」を評価するために「顧客努力指標」（Customer Effort Score; CES）を用います。 やっかいな「同時セッション数」と「平均処理時間」 「同時セッション数」（Chat Concurrency; CNC）はライブチャットの最大の特徴と言えるでしょう。 これがあることで、エージェント数の計算に、単純に「アーラン式」を使うことができません。 「CNC」をきっちり正確に測定するのは困難ですが、通常は以下の計算式により、エージェント数の算出に使えるレベルのCNCを求めることができます。 平均同時セッション数＝合計ライブチャット処理時間÷合計チャットオペレーション時間 ライブチャットの「平均処理時間」（AHT）が電話の2倍の長さになるのは、「CNC」の影響です。 また、「ドロップ」「タイムアウト」の発生も、「AHT」を長くする要因となり、「AHT」の予測をますます困難なものとします。 このように、計算や予測が困難な「CNC」と「AHT」ですが、いずれもエージェント数の算出のキーとなる指標であるのが、頭の痛いところです。 ライブチャット独自の運営指標 リアルタイム・マネジメントやワークフォース・マネジメントに使用するライブチャット独自の運営指標として、以下のようなものがあります。 これらは、ライブチャットの運営の仕方によって必要性が異なります。自センターのニーズに合わせて使用しましょう。
これら6つの独自指標を含めた全部で24の測定指標を下表に示します。 この中で、上記の説明にない指標の定義や使い方などは、電話（インバウンド・コンタクト）の場合と同様とお考えください。それらの詳細がお知りになりたい方は、『コールセンター・マネジメントの教科書』第6章をご覧ください。  ※この記事の内容は、2020年5月18日付のコラム「ライブチャットの測定指標（KPI）とパフォーマンスレポート」にて更新されました。
注1： 「チャットボット」と区別するために、欧米ではエージェントによるチャットを「ライブチャット」と表記するのがほとんど。「Webチャット」とする場合もあるが極めてまれ。
熊澤伸宏（文／Vol.21）  前々回（9月12日）のコラム「コールのオーバーハングを踏まえてインターバルを設定する」について、データの観点から少し掘り下げてみたいと思います。 大切な点は「インターバルを15分にするには、そのセンター（業務）のAHTが7分30秒以下であることが望ましい」ということでした。 さて、ではその元となるAHT（average handle time; 平均処理時間）自体は正確に把握できているでしょうか？ AHTとは、1件のコールの処理（通話＋保留＋後処理）に要する平均時間のことで、計算式は以下の通りです（注1）。 （通話時間＋保留時間＋後処理時間）÷応答コール数 読者の皆さんがお使いの統計管理システム（注2）が、この計算によるAHTを標準で出力してくれるのであればよいですが、そうでない場合は自前で計算をする必要があります。 その際、2つの点に注意する必要があります。 ひとつは、保留時間です。 統計管理システムによって、保留時間が通話時間に含まれているものと、そうでないもの（保留時間が通話時間とは別に単独で出力されている）があります。 さらに後者の場合、保留1回あたりの時間である場合と、1コールあたりの合計時間（1コールの中で2回保留した場合、2回分の保留の合計時間ということです）である場合があります。 これらをしっかり確認しておかないと、計算を誤ってしまうことになります。 もうひとつ注意すべきなのは、応答コール数をカウントするタイミングです。 統計管理システムによって、応答コール数を応答開始時にカウントする場合と、応答終了時にカウントする場合があります。 そのため、1本のコールが時間帯をまたがってオーバーハングした場合、応答開始時（前の時間帯）にカウントする場合は、後ろの時間帯の応答コール数が実際よりも少なく、応答終了時（後ろの時間帯）にカウントする場合は、前の時間帯の応答コール数が実際よりも少なくなります。 つまり、実際にはエージェントが応答していても、応答コール数として件数がカウントされない時間帯があるということです（注3）。 そうなると、コール数の予測、エージェント数の算出やスケジューリング、それらの実績のレポートなどに狂いが生じるかもしれません。 なので、皆さんがお使いの統計管理システムがどのような振る舞いをしているかを、必ず確認しておきましょう。 以上をお読みになって、にわかに不安に駆られた方がいらっしゃるかもしれません。 が、コールのオーバーハングは、前の時間帯からまたがって来るものと、後ろの時間へまたがるものがあるため、通常の場合、前後のオーバーハングが相殺されることで、大きな問題にはならないのです。 したがって、時間帯のインターバルをAHTの2倍以上の長さにする――インターバル15分の場合はAHTを7分30秒以下にする――ということを守っておけばよいでしょう。 ただし、オーバーハングが一方通行で発生する場合、例えば、特殊な事情により短時間にコールが集中するケース、あるいは、営業時間の開始直後や終了直前に大量の着信が発生するケースについては、オーバーハングによる影響をきっちりと考慮してください。
注1： 『コールセンター・マネジメントの教科書』第6章参照
注2： 米アバイアのCMS（call management system; コール・マネジメント・システム）に代表されるPBX/ACDの運用管理のレポーティングをおこなうシステム。『コールセンター・マネジメントの教科書』 第11章参照 注3： アバイアのCMSの場合、応答終了時にカウントされます。ちなみに「I_ARRIVED」というデータ項目を使うと、前の時間帯で着信コール数を把握することができます 長崎 智洋（文／Vol.13）  総合職、一般職などのように、「職能」（注1）で区別をつけたがる日本の企業では、「ジェネラリスト」か「スペシャリスト」かということがよく話題になります。 例えば、どちらが出世に有利なのか、どちらのタイプの人材を採用すべきかといったことです。 では、センター長、マネージャー、スーパーバイザーといったコールセンターのマネジメント（以下、コールセンター・マネージャー）の仕事についてはどうなのでしょう。 「コールセンター・マネジメントの仕事は企業経営の縮図だ」「センター長は中小企業の社長のようだ」と言われるように、コールセンター・マネージャーには「広範な守備範囲」が求められます（注2）。 また、他の一般事務系オフィスワークと比べるとコールセンターのオペレーションは極めてユニークであり、そのマネジメントには「高度な専門性」が要求されます（注3）。 このことから、コールセンター・マネージャーの仕事を「職務」（注4）の観点で考えると、そこにはジェネラリストとスペシャリストの両方の要素が含まれることがわかります。 ところが、日本の企業ではコールセンター・マネージャーは議論の余地なくスペシャリストと決め付けられます。 なぜなら、職能で考える日本の企業では、スペシャリストのことを「特定の部署や業務の専門性を極めた人」と定義するからです。 コールセンター・マネージャーの仕事は、一朝一夕に高い成果を挙げることはできません。 それを極めるには多くの時間がかかるため、必然的にコールセンターに長期間留まることとなり、そのことが、「特定の部署に長く留まる人＝スペシャリスト」という決め付けとなるのです。 コールセンター・マネージャーを担うことで、中小企業の社長のような広範な業務を経験することができても、決してジェネラリストとは言われません。 あくまでも、コールセンターという“狭い世界”の専門家という評価を超えることはできないのです。 では、日本の企業におけるジェネラリストとは、どういう人たちのことを言うのでしょうか。 一般的な定義としては、「幅広い分野の知識を持ち組織全体を俯瞰してみることのできる能力を持つ人」となりますが、 ここでいう幅広い分野とは、自社内のさまざまな組織や業務のことを意味します。 つまり、ジョブ・ローテーションにより短期間で社内の多くの部署を経験し、仕事の知識やスキルは広く浅くに留まるものの、協調性やコミュニケーション能力に長け、顔が広く、根回し上手で人望が厚いといったイメージです。 伝統的な日本企業では、このような人、つまりジェネラリストを有能と評価する一方、スペシャリストは、視野が狭い、オタク、わがまま、協調性がないなどネガティブな評価をされる傾向にあります。 スペシャリストと決め付けられるコールセンター・マネージャーも、日本企業においては後者として見られがちなのは残念なことです。 しかし、一歩、会社の外に出るとどうなるでしょう。 社内では有能とされ、出世コースの“日本的ジェネラリスト”は、社外では評価されません。 笑い話にもありますが、「部長やってました」は他社では通用しないのです。 一方、社内では色眼鏡で見られるスペシャリストは、その専門性が大きな武器となり、社外では高く評価されます。 ジェネラリストとしての広範な守備範囲と、スペシャリストとしての高度な専門性を併せ持つコールセンター・マネージャーは、“どこへ行っても役に立つ”有能な人材として、高い評価を得ることができるのです。 つまり、職務を基準に考える労働市場や諸外国では、センター・マネジメントにおける広範かつ豊富な知識、経験、スキル、見識を有するコールセンター・マネージャーこそ、特定の企業や組織に限らず、“どこへ行っても”その能力を発揮し貢献することができる人材と位置づけ、そのような人材のことをジェネラリストと呼びます。 その観点から考えると、“日本的ジェネラリスト”は、特定の企業内でしか役に立たないスペシャリストと定義づけることができそうです。 ちなみに筆者は、8つの企業でコールセンター・マネージャーとして従事しました。 日本企業的観点からは“転職を繰り返し・・・”とネガティブな意味合いで言われましたが、筆者にはそのような感覚はまったくありません。 なぜなら筆者は、30年超にわたって一貫してコールセンター・マネジメントを職とし、一度たりとも“転職”をしていないからです。 そんな経験から声を大にして申し上げたいのは、コールセンター・マネージャーはジェネラリストであり、その知識や経験、スキルは、世の中に広く大きな価値を提供できる仕事であるということです。
注1： 職能 = 仕事をするための能力。日本企業では、純粋な意味での能力よりも、年齢、学歴、経験年数、肩書といった個人の属性を能力判定の基準とする傾向にある
注2、注3： 『コールセンター・マネジメントの教科書』 序章参照 注4： 職務 = 仕事そのもの、またはその内容 熊澤 伸宏（文／Vol.12）  コール数の予測やエージェント数の算出、スケジューリング、サービスレベルの監視、レポーティングなどのために、インターバルを設定します。 インターバルとは、予測や測定をするための時間の間隔のことで、1時間、30分、15分といった単位で設定します。 インターバルは、センターの規模が大きくなるほど細かくなる傾向にあります。 なぜなら、ボリュームが大きいため、できるだけ細かい間隔で予測や測定をおこなって、その間の変化を正確にとらえたり、予測と実績との誤差を少なくする必要があるからです。 ところが、コール数やエージェント数の予測を細かいインターバルで緻密におこない、実績との誤差がほとんどなく、エージェントもスケジュール通りに勤務しているにもかかわらず、キュー（注1）が発生しサービスレベルが低下するというエージェント不足の状態に陥ることがあります。 その原因の多くは、コールの「オーバーハング」にあります。 コールのオーバーハング（注2）とは、1本のコールが前後の時間帯にまたがることを意味します。 例えば、インターバルを15分とした場合、前の時間帯（9:00～9:15）に着信したコールの応答が、後ろの時間帯（9:15～9:30）に入っても続くため、その分、後ろの時間帯に必要なエージェント数が不足することになります。 この問題に対処するには、コールのオーバーハングの発生を踏まえてインターバルを設定することが必要です。 具体的には、インターバルをAHT（average handle time; 平均処理時間）の2倍以上の長さにするということです。 つまり、インターバルを15分にするには、そのセンター（業務）のAHTが7分30秒以下であることが望ましいということです。 そうしておかないと、常に多くのオーバーハングに見舞われることとなり、時間帯別のきめ細かな予測やスケジューリングが機能しなくなってしまうので、注意が必要です。
注1： キュー = 顧客のコールがエージェントにつながるための順番待ちのこと
注2： オーバーハング ＝ 建築物の壁面や山の断崖など、垂直な面の一部が張り出している形状のこと 熊澤 伸宏（文／Vol.11）  Google Trendsによるコールセンターとコンタクトセンターの検索ワード人気度比較（2004年1月～2018年8月） 左上から時計回りに日本、全世界、イギリス、アメリカ合衆国 Googleで検索されるワードの人気度（注）を見ることができるGoogle Trendsを利用して、コールセンターとコンタクトセンター、Call CenterとContact Center（イギリスの場合はCall CentreとContact Centre）の比較をしてみたところ、興味深い結果が得られたので紹介します。 コールセンターやコンタクトセンターの当事者たちの大方の予想（？）を裏切って、コールセンターの圧勝です。 私が調べたおもな20カ国の中では、オランダがそろそろ逆転しそうな傾向を見せている以外は、イギリスを除くすべての国でコールセンターがコンタクトセンタ―を上回っています。 英語以外を母国語とする国の影響も多少はあるかもしれませんが、全体的な傾向は表しているでしょう。 唯一の例外であるイギリスは、2011年8月を境にコンタクトセンター（Contact Centre）が上回るようになり、2015年以後はその差を拡げていることがわかります。 ちなみに2013年6月にコールセンター（Call Centre）が派手にスパイクしていますが、これはBBCが「The Call Centre」という番組を放送したことによるものです。 アメリカは驚きです。 言うまでもなく、コールセンター／コンタクトセンターの最先進国であり、アメリカ発の各種メディアの表記は、圧倒的にコンタクトセンター（Contact Center）で占められているからです。 日本の場合は、何か裏付けとなるデータがあるわけではありませんが、世間一般的には、コールセンターが圧倒していることは感覚的に理解できます。 とは言え、日本でも“業界的には”、コンタクトセンタ―の露出が急増しているはずですが、検索ワードではコールセンターがいまだに増加を続けているのに、一方のコンタクトセンターは2012年ころを境にそれまでよりも減少し、その後増加する気配はありません。 一般に、電話が圧倒的にメインのコンタクト・チャネルである場合はコールセンター、Eメール、チャット、SNSなどマルチ・チャネルの場合はコンタクトセンターと定義されています。 ITベンダーなど、それにこだわって両者の使い分けをしている企業も見られますが、チャネルの種類による区分は、多分に業界寄りの発想である気がしないでもありません。 世間一般的には、チャネルはどうあれ（そもそも一般消費者がそんなことを意識しないでしょう）、企業や組織の顧客コンタクトの窓口のことをコールセンターとするという単純明快な認識なのではないでしょうか。 さまざまな理由で、コールセンターとコンタクトセンタ―のどちらにするかを検討する機会があるでしょうが、GoogleTrendsのデータは、今後もしばらくの間、業界の当事者の悩みの種となりそうです。
注：人気度の数値は、特定の地域と期間について、グラフ上の最高値を基準として検索インタレストを相対的に表したものです。100 の場合はそのキーワードの人気度が最も高いことを示し、50 の場合は人気度が半分であることを示します。0 の場合はそのキーワードに対する十分なデータがなかったことを示します（Google Trendsより）。
熊澤 伸宏（文／Vol.10）  日本企業は、技術系の分野においては世界をリードするプロセスやノウハウを持ちながら、一般事務系オフィスワークにおいてはからきし弱いと言われます。 個人の暗黙知に頼り、集団で助け合いながら仕事をするという日本流のスタイルが、個人の役割や責任をあいまいにし、それによってムリ・ムラ・ムダや無責任体質を引き起こします。 その結果、時間当たりの労働生産性が、主要先進7カ国中37年連続で最下位（日本生産性本部）に甘んじるという不名誉な状況を招いているのです。 この日本流のスタイルでコールセンターのオペレーションを運営しようとするから、上手くいかないのです。 コールセンターのオペレーションは、顧客とエージェントの1対1のコミュニケーションの集合体です。 つまり、仕事の最小単位である1つひとつのコンタクトは、1人ひとりのエージェントが他から明確に独立して仕事をしているため、そこに“集団”が介入する余地はありません。 また、個人の暗黙知に頼ることで、コールセンターの生命線である“一貫性”が損なわれ、次のような事態を招きます。
このような状態から抜け出すために真っ先におこなうべきなのが、仕事の可視化と標準化です。 可視化・標準化するのは、チームの仕事だけでなく、個人（注）の仕事についても必要です。 この、個人の仕事の役割や責任を明確にするのが「ジョブ・ディスクリプション」です。 ジョブ・ディスクリプションには、企業やセンターのミッションや目的を達成するために、各ポジションが果たすべき役割や責任が定義されています。 多くのスタッフが集う一方、1つひとつのコンタクトが独立しているコールセンターだからこそ、全員の意識と行動に一貫性を確保するために、ジョブ・ディスクリプションは必須のツールなのです。 さらに、ジョブ・ディスクリプションが存在することで、自分が担うポジションのあるべき姿と自分の現状とのギャップを具体的に知ることができ、それを埋めるためにスキルや能力の強化を図るなど、自己啓発のためのツールとしても機能します。 ジョブ・ディスクリプションは、コールセンターにとって“Nice-to-have”でなく“Must have”のツールなのです。 ※ジョブ・ディスクリプションについては、『コールセンター・マネジメントの教科書』第２章（P.74～76）で、作成の仕方について詳しく説明しています。また、代表的な７つのポジションのジョブ・ディスクリプションのサンプルを掲載（P.556～564）しています。
|
RSSフィード
|
サイトポリシー ｜ プライバシーポリシー ｜ 特定商取引に基づく表記 ｜ Staff Only
Copyright © 2018 - 2022 コールセンターの教科書プロジェクト All Rights Reserved |