Intelligent customer service dispatching system

背景

スケジューリングと聞くと、Alibaba Cloud の大規模なマシンリソースのスケジューリングを思い浮かべるかもしれません。しかし、Alibaba Group のカスタマーエクスペリエンス事業部 (CCO) においてスケジューリングの対象となるのはマシンではなく、カスタマーサービスリソースです。

なぜカスタマーサービスにスケジューリングが必要なのでしょうか。CCO は現在、Ali Group およびエコシステムのカスタマーサービス業務を担っています。お客様はさまざまなチャネルを通じて多様な問題の解決を求めています。日々の着信量は膨大で、さらに突発的な着信も頻繁に発生します。たとえば、Tmall のバウチャーに問題が発生すると、数分のうちに数千件のホットラインやオンライン相談が寄せられることがあります。こうした多様かつ大量で突発的なお客様の問い合わせに対し、サービス提供能力が追いつかず、ユーザーが長時間待たされたり、問い合わせを諦めたりする事態が生じています。ここにスケジューリングの必要性があります。

カスタマーサービススケジューリングの核心的な課題とは何でしょうか。それは、カスタマーサービスリソースの稼働率とサービスレベルを向上させ、より少ないリソースでより良いユーザー体験を実現することです。大量のカスタマーサービススタッフを雇用すればユーザー体験の向上は可能ですが、人的リソースの浪費につながりやすくなります。人員が増えれば、トレーニングコスト、管理コスト、人件費も増大します。

マシンスケジューリングと比較して、カスタマーサービスのスケジューリングには以下のような複雑さがあります。

1) 新しい物理マシンがデータセンターに追加された場合、仮想化後すぐに使用できますが、新しいカスタマーサービススタッフの採用にはオンラインサービス能力を身につけさせるための長期的なトレーニングが必要です。

2) カスタマーサービススタッフ間には大きな個人差があり、スタッフごとに業務スキルが異なります。スキルグループ B のスタッフにスキルグループ A の業務を直接対応させることは困難です。一方、マシン間の差異は小さく、多くの業務で同タイプのマシンを使用できます。

3) カスタマーサービススタッフは人間であり、出勤するか休憩を取るかは本人の選択に委ねられています。業務効率や品質は、気分、経験、対応するメンバー、勤務時間によって変動します。スケジューリング時にはスタッフの感情への配慮が必要ですが、マシンのスケジューリングではそのような配慮は不要です。

4) 予期しないシナリオが多く存在します。ビジネス上の問題、システム障害などは不規則に発生し、変動が非常に大きいため、1 日先の人材を正確に配置することは困難です。

これほど複雑なカスタマーサービスのスケジューリングを、オンサイト管理者だけで対応できるでしょうか。答えはノーです。スケジューリングシステムが導入される前、オンサイト管理者は基本的に手動でスケジューリングを行っていました。業務量の増加に伴い、以下の欠点が徐々に露呈しました。

1) 対応の遅さ：たとえば、週末にオンラインキューが発生した場合、オンサイト管理者は電話で報告を受けてからパソコンを起動し、手動で臨時シフトを組む必要があります。キューの発生からスケジューリングが有効になるまで 10 分以上かかることも珍しくありません。

2) 不正確さ：データに基づく指針が不足しており、全体的な計画と最適化の能力が脆弱です。たとえば、スキルグループ A でキューが発生しているときに、オンサイト管理者がスキルグループ A のトラフィックの一部を B に振り分けようとします。しかし、どのくらい振り分けるか、誰に割り当てるかは場当たり的な判断になりがちで、その判断結果を確定させることもできません。

3) 手段の不足：利用可能な手段は極めて限られており、手動でのシフト変更、ストリームの手動切り替え、休憩管理、お知らせの掲示などに過ぎず、カスタマーサービスの能力と潜在力を十分に発揮できていません。

カスタマーサービススケジューリングの核心的な課題を明確にし、難しさを理解し、現状を把握した上で、自動的かつインテリジェントなカスタマーサービススケジューリングシステム「XSigma」の構築を決定しました。

XSigma の全体像

XSigma スケジューリングシステムは、機能モジュールに応じて「手」「脳」「目」の 3 つに分けられます。「手」とは、カスタマーサービスリソースの稼働率、サービスレベル、顧客満足度を向上させる手段であり、オーバーフロー転送、予約折り返し、オンサイト管理、インセンティブ、シフトスケジューリング、緊急シフトのリリース、トレーニングなどがあります。これほど多くの手段の中から、異なるビジネスや異なるシナリオでどのように選択するかが難しいポイントです。ここで、意思決定を行う「脳」、すなわちディスパッチセンターが必要になります。その結果生じる複雑なスケジューリングロジックを、オンサイト管理者、ビジネス担当者、開発者がどのように理解しやすくするか。可視化技術により、複雑なスケジューリングロジックを直感的に理解できるリアルタイムのグラフィカルインターフェイスに変換します。これがスケジューリングシステムの「目」、すなわち大規模スケジューリング画面です。「手」「脳」「目」の機能が揃った後、それらをより良く連携させ、継続的に改善するにはどうすればよいでしょうか。シミュレーション演習システムを通じて検証します。

2. 事前準備：シフトスケジューリング

需要を予測し、供給を準備できれば、カスタマーサービスのスケジューリングは半ば成功したようなものです。私たちのビジネスでは、異なるタイプのカスタマーサービスでスケジューリングモデルが異なります。クラウドカスタマーサービスは自己選択シフトモードを採用しています。管理者は各時間帯に必要な人数を設定するだけで、クラウドカスタマーサービスが自分の都合に合わせてシフトを選択します。SP (パートナー) はシフトスケジューリングモードを採用しており、管理者が各時間帯のトラフィック量に応じて各スタッフのシフトを配置する必要があります。各時間帯の接続率を最大化すると同時に、スタッフの休憩と勤務時間を調整し、各スタッフの総勤務時間が概ね均等になるよう保証する必要があります。これは管理者の全体計画能力が試される場面であり、スタッフ数が増加すると、手動スケジューリングは管理者に大きな負荷をかけます。

どのモデルであっても、今後 2 週間に必要なサービス量を事前に予測する必要があります (ビジネススケジュールは 1〜2 週間の粒度で組まれます)。これは標準的な時系列予測の問題です。既存データを組み合わせることで、部門・スキルグループの粒度で今後 2 週間のサービス量を予測できます。ただし、このオフライン予測はあくまで近似値であり、正確な予測は困難です。

パートナー企業のカスタマーサービススケジューリングについては、複数の制約条件下での最適化問題として抽象化できます。実際のシナリオでは、組合せ最適化アルゴリズムを使用しています。

3. 水平拡張：予測型緊急シフト

事前のスケジューリングだけでサービス量を正確に見積もることは困難です。来週の月曜日の 13:25 にバウチャーの問題が発生し、大量のユーザーが相談に訪れることを事前に知ることはできません。

こうした突発的なトラフィックや勤務中のサービス量を超えるトラフィックに対し、マシンをディスパッチするように、一群のカスタマーサービススタッフを迅速かつ水平的に拡張できないでしょうか。ソーシャル化されたクラウドカスタマーサービスであれば、それが可能です。たとえば、キュー数が一定値を超えると、クラウドカスタマーサービスの緊急シフトが自動的にトリガーされます。実践により、クラウドカスタマーサービスはシフト選択から勤務開始まで通常 10 分以上かかることが分かっています。この 10 分以上の貴重な処理時間をさらに短縮するにはどうすればよいでしょうか。緊急シフトを予測型緊急シフトに強化するのです。数分先の大規模トラフィックを事前に予測し、前もって勤務を開始します。

ここには 2 つのモデルが関わっています。1 つはサービス量のリアルタイム予測モデルで、メンバーの操作行動、メンバーの行動、障害シナリオなどのリアルタイムデータを総合的に分析し、過去の着信データと組み合わせて、スキルグループの今後 30 分の 1 分ごとの着信量を予測します。

サービス量予測データの入力を得て、緊急シフトモデルは現在のサービスメンバーの状況、今後 30 分のカスタマーサービスのスケジューリング状況、メンバーの消費速度、オーバーフロー関係などの総合的な指標を組み合わせ、緊急シフトをトリガーするかどうかとリリースするクラスのサービス量を推論します。緊急シフトがトリガーされると、オフライン通知モジュールが電話やテキストメッセージなどの手段で適切なカスタマーサービススタッフに出勤を通知します。

マシンスケジューリングとは異なり、カスタマーサービスの体験を常に考慮する必要があります。出勤を希望しないスタッフへの妨害を避けるため、通知の受信可否をスタッフが自主的に設定できるようにしています。

4. 負荷分散：オーバーフロー、転送

予測型緊急シフトは効果的ですが、現時点ではクラウドカスタマーサービスにのみ有効です。SP などの選択制ではないカスタマーサービスにはどう対応すればよいでしょうか。オンラインキューが発生しているとき、特定のスキルグループで大量のキューが発生する場面がよく見られます。たとえば、マーチャント回線が逼迫している一方で、コンシューマー回線のカスタマーサービスが暇をしていることがあります。この忙しい・暇の偏りをどう解決するか。直感的で極端なアイデアは、すべてのグループを 1 つの大きなプールに統合し、負荷分散による分配ですべてのメンバーを忙しくすることで効率を最大化することです。しかし実際には、すべてのスキルグループが互いの業務を担えるわけではありません。ここで、ビジネスとオフライントレーニングのバランスを取り、カスタマーサービスに複数のスキルを身につけさせる必要があります。

XSigma はスキルグループの転送とオーバーフローの設定機能を提供しています。トリガー条件を満たせばリアルタイムでオーバーフロー転送が行われ、オンサイト管理者が手動でカスタマーサービスのスキルグループを変更していた過去の課題を解決します。

一部のシナリオでは、スキルグループ間のオーバーフローの粒度はやや粗いと言えます。たとえば、スキルグループ A のキューをスキルグループ B にオーバーフローするよう設定しても、スキルグループ B のすべてのメンバーが A の業務を担えるわけではありません。特定のトレーニングを修了したカスタマーサービスのみが引き継げるため、XSigma はカスタマーサービスにスキルタグを付ける機能も提供しています。

5. 垂直拡張：柔軟性 +1

一部のビジネスはより複雑で、オーバーフロー先のスキルグループを見つけることが難しいため、現在対応中のカスタマーサービスに目を向けます。オンラインカスタマーサービスは同時に複数のメンバーに対応できます。あるカスタマーサービスの最大サービスキャパシティが 3 であれば、同時に最大 3 人のメンバーに対応できます。この値は、管理者がそのスタッフの過去のサービスレベルに基づいて設定します。

多くのスタッフの最大同時対応数は同じであっても、フルキャパシティでメンバーに対応しているときのサービスレベルや忙しさは大きく異なることが分かりました。なぜでしょうか。

スタッフのレベルには差異があります

下図に示すように、あるスキルグループのカスタマーサービスの最大サービスキャパシティは 3 です。先月、このスキルグループのスタッフが同時に 3 人のメンバーに対応したシナリオでの平均応答時間分布 (平均応答時間はスタッフの応答速度に比例) を見ると、データは概ね正規分布を示しており、同時対応時におけるスタッフ間のサービスレベルに差異があることを示しています。

シナリオの違いもあります

たとえば、カスタマーサービス A と B の最大サービスキャパシティがいずれも 5 で、両者とも 5 人のメンバーに対応しているとします。しかし、A の 5 人のメンバーは会話がほぼ終了に近いのに対し、B の 5 人のメンバーは始まったばかりです。この例では、スタッフ A と B の現在の忙しさは明らかに異なります。

スタッフ間のサービスレベルに差異があり、実際のシナリオも大きく異なる場合、余裕のあるスタッフがスキルグループのキュー発生時にサービス上限を超えられないでしょうか。

XSigma はスタッフがサービス上限を超えることを可能にする 2 つの戦略を提供しています。

1) アクティブ +1 モード

スキルグループがトリガー条件に達すると、XSigma はカスタマーサービスワークベンチ上に +1 ボタンを自動的に表示します (下図の赤枠参照)。スタッフはクリックして、自主的に 1 人のメンバーの着信を追加できます。この方法は拡張権限をスタッフに委ねるものであり、自分が忙しいかどうかを知っているのはスタッフ自身だからです。

2) 強制 +1 モード

一部のスキルグループが強い管理型の場合、強制 +1 モードの有効化を選択できます。XSigma はデータに基づいて適切なスタッフを自動的に選択し、サービスキャパシティの上限を超えさせます。たとえば、以前の最大サービスキャパシティが 5 であった場合、同時に 6 人のメンバーに対応させます。

6. 山を削り谷を埋める：予約折り返し

ホットラインの場合、スタッフが同時に複数の通話に応答することは不可能であり、オフラインで対応可能なカスタマーサービスも少数です。このような状況で大量のキューが発生した場合はどうすればよいでしょうか。

データ分析により、多くのスキルグループの忙しさは 1 日の中で変動し、ピークとローピークがあることが分かりました。下図はあるスキルグループの残りサービス数を示しています。10〜13 時と 17〜21 時の 2 つの忙しい時間帯があり、この 2 つの時間帯のアイドルサービス数はしばしば 0 になるのに対し、他の時間帯は比較的アイドルであることが分かります。これらの忙しい時間帯の着信を忙しくない時間帯に移動できれば、カスタマーサービススタッフの稼働率を大幅に向上させると同時に、お客様のキュー待ちの手間も省けます。

どうすれば実現できるでしょうか。当日のサービスを翌日のサービスに変換します。予約折り返しをスケジューリングすることです。下図に示すように、主に 2 つのモジュールがあります。

1) 予約トリガー。ユーザーが電話をかけてきた後、予約トリガーはスキルグループの混雑状況に応じて予約をトリガーするかどうかを判断します。

2) 折り返しトリガー。システムのアウトバウンドコール方式を使用し、スキルグループの混雑度がローピークにあると判断されると、折り返しコールがトリガーされます。ユーザーの電話が接続されると、高い優先度で分配リンクに入り、カスタマーサービススタッフが有効な勤務時間内で実際にお客様と会話できるようになります。

7. 最適割り当て

ディスパッチの目標は「カスタマーサービスリソースの稼働率とサービスレベルを向上させ、より少ないカスタマーサービスリソースでより良いユーザー体験を実現する」ことです。これまでの戦略はカスタマーサービスリソースの稼働率向上に重点を置いていました。ユーザー満足度を向上させる戦略はあるでしょうか。割り当ての部分から着手します。

本質的に解決すべき問題は「メンバー (タスク) とカスタマーサービスのマッチング最適化」です。従来のモードでは、あるスキルグループのキューから最も長く待っているメンバーを見つけ、そのスキルグループの下で最もアイドルなカスタマーサービスを見つけてマッチングを完了させます。この公平な分配方法は単一の次元しか考慮しておらず、グローバルレベルでメンバー、カスタマーサービス、およびスケジューリング分配に関連する問題に関するさまざまな情報を把握できていません。

マッチング最適化問題は、実際には二部グラフマッチング問題です。図に示すように、ある時点で、スキルグループの下で未割り当ての顧客 (タスク) と、残りサービス能力を持つカスタマーサービススタッフを取得できます。各タスクと各カスタマーサービスの間のマッチング確率を把握できれば、安定結婚アルゴリズムを通じて最適なマッチングを見つけることができます。

タスクとカスタマーサービスの間のマッチング確率をどう見つけるか。分類回帰問題として抽象化し、コアは大量のサンプル (x1, x2, x3, ..., xn)(y) を構築することです。過去のセッションタスクにおいて、y は顧客評価またはセッション期間 (ターゲットは任意選択可能) であり、x には過去 30 日の満足度や平均応答時間などのオフライン指標といったカスタマーサービスの特徴、現在のセッションでのサービスメンバー数や最大メンバー数などのリアルタイム指標、さらに質問タイプ、待ち時間、注文番号、繰り返し相談数などのタスクの特徴も含まれます。サンプルが準備できたら、分類アルゴリズムを選択してトレーニングを行います。最終的に CNN を使用しました。

反復プロセスの中で、モデルは優れたカスタマーサービスにより多くのトラフィックを割り当て、指標が比較的低いカスタマーサービスのトラフィックが減少することが分かりました。スタッフの燃え尽きを防ぎ、公平性を確保するため、モデルにバランシング調整機構を導入しました。

8. インテリジェントトレーニング：大黄ロボット

最適割り当てを通じて満足度を向上させる重要な理由は、能力が高くサービスレベルの高いカスタマーサービスにより多くのトラフィックを割り当てることにありますが、このようなスタッフの割合は高くありません。なぜでしょうか。11 月と 12 月の 2 か月間の高トラフィックに対応するため、ビジネスチームは大量のクラウドカスタマーサービススタッフを採用・トレーニングせざるを得ません。これらの新人の流入は必然的に満足度に影響を与えます。つまり、満足度指標をさらに向上させるには、新人カスタマーサービスのサービスレベルを向上させる必要があります。

新人にとって、上岗前にレベルを向上させる唯一の方法はトレーニングです。従来のトレーニングは、クラウドカスタマーサービススタッフに動画やその他の学習教材をオフラインで視聴させ、筆記試験を受けさせるものです。プラットフォームのツールやソリューションに不慣れなまま直接メンバーに対応すると、メンバーの体験は悪化します。

運転免許のトレーニングシーンを比較したところ、科目 1、科目 2、科目 3 などの異なるプロセスがあることが分かりました。科目 1 は理論学習、科目 2 と科目 3 は実戦シミュレーションです。この種の実戦シミュレーションを導入すれば、新人カスタマーサービスのサービスレベルを大幅に向上させられます。

私たちは革新的に、ロボット (大黄) を使用してカスタマーサービスをトレーニングする新しいカスタマーサービス研修モデルを提案しました (特許出願済み)。トレーニングテナントで、新人カスタマーサービスは大黄のアバターをクリックすることで、非常にリアルな模擬セッションを生成します。メンバーとのチャットを通じて、プラットフォームツールの使用方法を継続的に学習し、顧客の問題を解決する能力を継続的に向上させます。会話结束后、大黄ロボットはその会話を評価し、特定のソリューションを使用してユーザーの質問に答えるべきだったことを伝えます。

新人カスタマーサービスは、現在、大黄との 80 回の会話を完了してから実際の業務に就く必要があります。会計年度全体で数万人的なカスタマーサービススタッフがトレーニングを受け、サービスセッション数は数百万ラウンドに達しました。A/B テストの結果、大黄による試用期間を経たカスタマーサービススタッフは、満足度、不満足度、平均応答時間、平均サービス期間などの各種指標で有意な改善が見られました。

9. 統一ディスパッチセンター

これまでの説明から分かるように、カスタマーサービスのスケジューリング戦略は多数かつ複雑であり、各戦略はカスタマーサービスリソースの稼働率とサービスレベルの向上に一定の役割を果たしてきました。ここで問題となるのは、異なるシナリオでこれほど多くの戦略をどのように選択するかです。たとえば、スキルグループ A で突然 100 人のメンバーがキューに並んだとします。このとき、他のスキルグループに直接オーバーフローすべきか、アクティブ +1 をトリガーすべきか、それとも緊急シフトをリリースすべきか。ここで意思決定を行う「脳」が必要です。

この「脳」をさまざまな複雑なビジネスシナリオに適用可能にすることが難しい点です。現在、プラットフォームには数十のテナントがあります。Taobao 系のテナントだけでも数十のカスタマーサービス部門があり、各部门はさらに一連のスキルグループに細分化されています。部門ごとにビジネスシナリオは異なり、既存データの蓄積が著しく不足している状況では、1 つの意思決定モデルをトレーニングして多種多様なビジネスに直接適応させることは困難です。そこで、オンサイト管理者の専門知識を直接活用し、その意思決定ロジックをルールとして蓄積するというアプローチを採用しました。

現在、プラットフォーム上では数万のルールが設定されており、毎日数千のルールが有効になっています。これらのデータの蓄積により、インテリジェント最適化技術を通じて真にインテリジェントなスケジューリング意思決定脳を実現できます。

10. スケジューリングモニタリング大画面

カスタマーサービスのスケジューリング戦略は多く、ロジックは複雑であり、スケジューリングの結果は実際にプロセス全体の参加者の感情に影響を与えます。そのため、皆が理解しやすいよう XSigma スケジューリング大画面を構築しました。実践により、ディスパッチ大画面はユーザーのディスパッチシステムに対する信頼を確立し、開発者や管理者がシステムの問題を発見、特定、解決するコストを削減できることが分かりました。たとえば、管理者が XSigma プラットフォームでいくつかのルールを設定します。たとえば、スキルグループ A のキュー数 >= 1 でスキルグループ B へのオーバーフローをトリガーする、といったものです。開発者にそれが有効になったかどうかを確認させますが、現在は視覚的なスケジューリング大画面があり、各スキルグループのサービス量や残りサービス量などのリアルタイムモニタリングデータを観察できるだけでなく、各種戦略が有効になるリアルタイムのスケジューリングプロセスや、毎日スケジューリングされるリアルタイムのサマリー詳細データも確認できます。

11. シミュレーション演習

スケジューリング最適化シナリオにおいて、スケジューリングシステムの品質を評価することは非常に重要です。XSigma がさまざまなシナリオに適応できるかどうかを評価する方法はあるでしょうか。独身の日のプロモーション期間中にスムーズにスケジューリングできることを事前に証明できるでしょうか。スケジューリングプロセスの問題をタイムリーに発見できるでしょうか。これは私たちだけでなく、ビジネス担当者も切実に知りたいことです。

慎重に検討した結果、解決すべき問題は技術的なフルリンクストレステストと非常に似ていることが分かりました。必要なのは、ビジネスに対するフルリンクストレステストです。そこで、カスタマーサービススケジューリング向けのシミュレーション演習システムを構築しました。

大黄ロボットをベースに、すでにメンバーのアクセスをシミュレートできます。カスタマイズと改造を通じて、ロボットは独身の日タイプのシナリオなど、さまざまなタイプのトピックを作成できます。これに基づき、ビジネス担当者の推定量と組み合わせて、各スキルグループの着信量を設定できます。

独身の日の前に、ビジネス担当者はこの演習システムを使用して 2 回の大規模演習を実施しました。演習は実際のサービス量に基づいて行われ、以前の口伝え方式ではなく、スケジューリングの上流から下流までのすべての参加者にリアルなプレッシャーをかけました。演習中に発見されたいくつかの問題を改善した後、大規模プロモーション中の突発的トラフィックへの対応に対する信頼が大幅に向上しました。