こんにちは親愛なる読者。 今日は、会社の技術サポートへの呼び出しの優先順位を決定するためのシステムがどのように配置されているかを説明します。組織内に存在することにより、要求への応答時間を大幅に短縮し、サービスユニットの限られたリソースを正しく割り当て、緊急の顧客の緊急の問題に可能な限り迅速かつ効率的に対応できます。 当社の実例でシステムの機能を検討します。
そのため、特定のサービス/製品について組織Xに頼った状況を想像してください。 おそらく、購入の段階でさえ、会社を選ぶ知恵には疑問を抱いていましたが、何らかの理由でまだサービス/製品を購入していました。 後で判明したように-非常に無駄です。 サービス/製品の品質は期待を満たしていないため、返品はできませんが、この製品を動作させるには依然として必要です。 解決策はサポートサービスです。 しかし、これは不運です。 サポートサービスは、ヘルプのリクエストに気付いていないようです。電話ですぐに連絡することはできません。 おなじみですか？
このような問題に関連するものは何ですか？また、サービス部門のリソースの不合理な分配と顧客の要求の誤った優先順位付けに関連していますか？ JSC Infovotchの優先順位付けシステムの例を使用して、これらの質問に光を当てようとします。
テクニカルサポートサービスへの連絡の優先順位を上げるまたは下げるための主な基準、仕事の仕組み、および従業員とその直属の上司の注文の順序を検討します。 はじめに、顧客請求システムが内部からどのように見えるかを調べましょう。
キューを操作する際のサービス部門でのコールの優先順位付けでは、しばしば疑問が生じます。 組織は、サービス提供のこの側面に適切な注意を払い始めるために、一定レベルの成熟度まで成長する必要があります。 もちろん、優先順位付けの基準が「成熟」し、「人的要因」によるエラーの数が許容できないレベルに増加するレベルに達する必要があります（増加する「騒がしい」顧客や経営陣からのエスカレーションから容易に気づきます）。プロセス自動化の経済的効果が具体的になりました。
従業員が部門のビジネスプロセスの日常的な管理に費やす時間を分析したことがありますか？ あなたがこれをしなければならなかったとしても、それほど頻繁ではないと思います。 一方、ルーチンは従業員の時間をかなり費やす可能性があります。 これは、メカニズム全体の機能を保証するため、重要ではないということではありませんが、同時に、この作業は管理者がKPIで確認したい測定可能な結果をもたらしません。 たとえば、テクニカルサポートサービスでは、従業員がアプリケーションの管理に費やした時間（つまり、優先順位付け、サービスフィールドへの入力、およびCRMシステムの大規模なアプリケーションメカニズムのネジのその他の同時締め付け）を誰も知りたがらないでしょう。 管理では、原則として、処理および解決されたアプリケーションの数、品質管理の結果、およびCSAT（顧客満足度）のみ。 一方、実践では、この問題に対処する必要があることが示されています。
アプリケーションごとに1分または2分*アプリケーションの数=？
そして一週間はいくらですか？ そして一ヶ月？ そして一年？
そして、この時間数に平均給与計算サービスデスクを掛けるとどうなりますか？
マネージャーは常により重要なタスク、緊急、およびルーチンの一部を自動化するための時間を費やしており、この自動化が影響する関連部門の同意とサポートを得ることも常に可能ではありません。 幸いなことに、現在の経済モデルでは危機が発生し、企業が経済モードで働き、太った年に巻き込まれた巨大なプロセスの最適化に目を向けるようになりました。 プロセスの最適化と自動化の以前の緊急ではないタスクが前面に出てきます。 これは私たちの組織で起こりました。
この国の経済状況は、新しいタスクごとの従業員の雇用を促進していません。また、経済状況の成長危機により、部門の長は、サービスが損なわれず給与が伸びないように、プロセスの監査を行わざるを得ないという独特の状況を作り出しています。
そのため、目標は、コール数の増加と新入社員の雇用制限に関連して、以前のレベルのKPIテクニカルサポートを提供することです。
タスク：
- テクニカルサポートエンジニアの呼び出しの優先順位を決定するための簡素化と統合。
- 処理アプリケーションの正しい順序を保証します。
問題は、より多くの仕事があり、労働者の数が増えていないか、ゆっくりと増えていないこと、優先順位の要件が多くの異なるニュアンスのある実際の状況を反映していないことです。
解決する方法：
- 従業員の労働時間の管理（この記事は考慮されません）;
- 従業員のさらなるトレーニングと生産性（また他の時間）。
- プロセス、特にアプリケーションの優先順位付けプロセス（後述）の日常的な管理の人件費を削減します。
従業員は、特定の要件に基づいて、平均して控訴の資格を与え、適切な優先順位を割り当てるために最大1分半かかります。 これは、コンタクトセンターで異議申し立てを処理するプロセスの不可欠な部分であり、いかなる状況でも排除することはできません。 私たちの場合、治療で一度割り当てられた優先順位は、アプリケーションの作業中ずっと彼と一緒に維持され、新しいデータを考慮して再集計されることはありませんでした。 このような状況では自動化は必要ありませんでしたが、ユニットの責任者は、隣接するユニットから受信したすべてのエスカレーションを念頭に置いて、すべてのオープンコールを調べ、顧客からのリクエストの処理順序に「手動制御」を適用しました。 マネージャーが1人しかいないチーム内の小さなボリュームでは、このアプローチは正当で十分です。 しかし、その有効性は非常に限られており、2つ以上のシフトを持つ企業には適さず、「人的要因」を排除しません。 エスカレーションについて次のシフトから同僚に通知するのではなく、間違いを犯したり、見落としたり、単にアプリケーションを忘れたりする可能性が常にあります。 そのような失敗の結果として、原則として、顧客は苦しみ、これは受け入れられません。 その結果、ケースの「更新されない」優先度インジケータの問題を解決するために、アプリケーションの優先順位付けシステムをテクニカルサポートに完全に作り直し、「ヒューマンファクター」を可能な限り排除することにしました。
会社でCRMシステムが長い間使用されているという事実のために、私たちは顧客と、顧客との仕事、製品と顧客、インフラストラクチャと製品などの最も一般的な問題と状況の両方についてかなりの量のデータをすでに蓄積しています。 n。 ワークショップで同僚と相談し、他の企業で同様の動的優先順位付けシステムを構築する経験を研究した後、私たちは現実を満たし、ビジネスプロセスに適合する独自のシステムを開発しました。
0〜1の数値形式の優先度システムを構築することを決定しました。優先度値が「1」の治療が最高の優先度を持ちます。 最初に処理する必要があります。 したがって、値「0」は最も低い優先度を持ち、より重要な要求をすべて処理した後にのみテクニカルサポートエンジニアの視野に入ります。 一般的なスキームは次のとおりです。
ご覧のとおり、既存のSLAシステムと申請の特別な受領源が、控訴の優先順位の基礎として採用されました。 当社には、お客様にさまざまなSLAを提供する3種類の技術サポート契約があります。 これらの各契約は、その基本番号を受け取りました。 同じことがアプリケーションのソースにも当てはまります。 この場合、2つの基本的なものから選択するときに、システムは自動的に高い優先順位を付けます。 そして、楽しみが始まりました。 基本的な値は、テクニカルサポートの作業で考えられるすべてのニュアンスを考慮していません。
例を挙げます。
非常に大規模で非常に重要な顧客から、インターフェースのアイコンを変更する提案が寄せられました。 私たちは何をすべきですか？ このような嫌な絵文字を描いた怠慢なデザイナーを見つけることに全力を尽くし、彼/彼女にすぐにすべてをやり直させ、レイアウトを承認し、技術部門に負担をかけ、すぐにこの顧客の修正プログラムを発行する必要がありますか？
同時に、小規模のクライアントが製品で深刻な問題に直面しているため、ビジネスが実際に停止し、サポートチームにリクエストを送信します。
最初のリクエストの優先度を下げて、2番目のクライアントを支援する必要があります。それほど大きくなく、非常に重要ではありませんが、誰の問題がより深刻ですか。
武器庫には限られた数のリソースしかないため、全員が一度にオンデマンドで利用できるようにすることは不可能です。 そして、顧客の大多数はこれをよく知っています。 最大かつ最も重要な顧客でさえ、いアイコンによる問題の即時解決を主張しません。これは、ささいな不便であり、通常の操作を妨げる実際の問題ではないためです。 したがって、限られたリソースの条件で正しい優先順位を設定することは非常に重要です。 同様に重要なのは、このメカニズムの正確さとシンプルさです。
このロジックに基づいて、基本的な優先順位付けシステムを、さまざまな状況でアクティブ化された特定の係数で補完しました。
つまり、最終的な式は次のようになります。
基本メトリック+浮動メトリック=合計優先度値。
上記の例の計算を説明しようとします。
たとえば、No。1の場合、計算は次のようになります。
プレミアムSLA +プリセールスエスカレーション+アフターエスカレーション+組織の重み* 10000を超えるユーザー数+問題の重大度*機能的な要望+期間= 0.07 + 0 + 0 + 0.03 * 0.38 + 0.56 * 0.02-0 = 0.07 + 0.0114 + 0.0112 = 0.09ご覧のとおり、適切な入力データ（プレミアムサポート、大規模クライアント）にもかかわらず、最終的な優先順位インジケーターは非常に低くなっています。
たとえば、No。2の場合、計算は次のようになります。
拡張SLA +プリセールスエスカレーション+アフターエスカレーション+組織の重み*ユーザー数100 +問題の重大度*重大な問題+作業時間= 0.04 + 0 + 0 + 0.03 * 0.03 + 0.56 * 0.42 = 0.04 + 0.0009 + 0.24 = 0.28ここでは状況は逆です。 組織はまったく大きくなく、技術サポート契約が控えめであるという事実にもかかわらず、問題の重要度が高いため、アプリケーションの優先順位は例1のアプリケーションを上回っています。
つまり、必要なデータのセット全体を保有しているシステムは、最初の顧客の重みが大きいにもかかわらず、小さな組織から低い優先度でより重大な問題を自動的に引き起こしました。 システムは、9つの異なるパラメーターでアプリケーションの優先度を自動的に再計算し、18の異なる係数を使用して基本優先度インジケーターを上げ、基本優先度数を増減できます。 このインジケータは静的ではありません。 循環の分類に新しいデータが表示されると変更され、処理キュー内のアプリケーションのランキングが即座に変更されます。 これにより、アプリケーションを処理する必要のある順序で正確に配布できます。
これが、コールラインがテクニカルサポートエンジニアを探す方法です。 アプリケーションの優先順位を確認する必要はもうありません。 テクニカルサポートエンジニアは、優先順位の高い順にアプリケーションを上から下に処理するだけです。
ご覧のとおり、優先順位付けシステムを作成する際、アピールの処理中に発生する可能性のあるすべてのニュアンスを考慮しようとしました。これは、適用された問題の重大度、保守契約で修正されるSLA、さまざまな種類のエスカレーション、および運用開始時からの操作の期間ですらありますCRMシステムで。 そして、これらのパラメーターのほとんどが自動的に設定されるという事実を考慮して、当社のエンジニアはもはや治療の優先順位の管理に時間を費やさず、緊急に助けを必要とする人々と連絡を取りながら、顧客の問題の研究とソリューションの開発に集中できます シフトマネージャーは、すべての「特別な」アプリケーションに関する情報を常に念頭に置いて再開に対応する必要がなくなり、顧客はすべての要求ができるだけ早く処理され、テクニカルサポートの視野から消えることがないことを確認できます。フル解像度。
新しいシステムはCRMに実装され、2016年12月の初め（51週間）から運用されています。 パイロット運用中に、エスカレーションの数が減少していることにすでに気付いています。
注意深い読者は、「バックログ」が現在の実装では考慮されていないという事実に間違いなく注意を払うでしょう。 問題は、これが自動化の次の段階であることです。 バックログ自動計算メカニズムの準備ができ次第、既存の優先順位付けシステムに追加して、係数を再計算します。 それまでの間、バックログの「追跡」は手動モードで実行されます。 メカニズムが完全に準備され実装された後、バックログを計算するためのメカニズムの説明に別の投稿を当てます。
近い将来、上記の優先順位付けメカニズムの係数を計算するための数学的装置の詳細な説明を含む記事も公開されます。
シムについては、私はすべてを持っている、私はコメントで話してうれしいです。
UPD：最後に、同僚がこの優先順位付けシステムの数学的装置について説明した記事を公開しました。