「旧世界では、時間の30％を使用して優れたサービスを作成し、時間の70％でそれについて話しました。 現代の世界では、それは逆です。」-ジェフ・ベゾス、Amazon CEO
「 これは世界で最悪のサービスです！」 すぐにお金を返してください！ 」-すべてのテクニカルサポートエンジニアが少なくとも1回、ただしユーザーからこれを聞いた。 言うまでもなく、最も不満を感じる人は 、「 電話に27分間掛けました 」、「 4日目は問題を解決できません ！」と話します 。サポートで働いたことのない人は、個人的な経験によって提供されるサービスの質を判断します。そして、私たちは彼にどのように判断し、電話に出て問題を解決しますか？あなたのユーザーに良いサービスを提供するかどうかを判断する方法は？
実際、ここで車輪を再発明する必要はありません。すべてが長い間考えられてきました。 主要業績評価指標（KPI / kpi）と数値を参照するだけで十分です。 数字-目標を設定する新しいエンジニアであれ、スタッフを増やす必要性を確信する必要があるトップマネージャーであれ、誰もが理解できる言語。
それらを適用する方法とそれらをどうするかについての多くのメトリック、数百の本と記事があります。 私たちのチームで使用されており、実践が示しているように、それらが目的を果たしているものについてのみ伝えたいと思います。 さらに、ここでクレイジーなグラフィックスや科学的研究を行うのではなく、単に人生の興味深い話をいくつかお伝えします。
私は最初から始めます。 私がParallelsで働くようになったとき、すでに世界中のMacユーザー向けに約500万人のParallels Desktopがありました。 この資産には、アウトソーシングの最初のサポートライン、モスクワの2番目のライン、24時間年中無休のシフトスケジュールが含まれていました。 多くのチームがあり、仕事もしていました。 次のメジャーリリースでちょうど来ました。 たまたま、すべてのトレーナーが私たちのサポーターのトレーニングのためにインドにいた。 彼らは私に仕事のルールと製品の説明書を読んでもらい、「上陸パーティー」は夜勤に投げ込まれました。
まず第一に、勤勉な学生として、私はすべての測定基準を研究し（そして20以上ありました！）、それを理解し、新しいエンジニアが私を教えてくれるようになるまで、安全に忘れていました。 私の頭には絶対的な混乱がありました-どのようなメトリックが何に責任があるのですか？ どのように考慮されますか？ そして最も重要なこと-どのように私は何に影響を与えることができますか？ もちろん、最終的に私はそれを理解しましたが、チームリーダーとして最初にしたことは、目標からメトリクスの半分を削除し、最も重要なものだけを残すことでした。
サポートの卒業証書や専門コースはありません。 資産は控えめなスタッフとリソースです。 私が学んだこと、学んでいることはすべて、実践と自分自身の過ちによってもたらされます。
次に、基本的な指標について説明します。 それらのいくつかは、チームのエンジニアにとっての目標でもあります。 狂ったスケジュールや不必要な「水」なしで、すべてを非常に簡潔に述べようとします。 不明な点がある場合は、コメントで質問してください。
着信ボリュームまたはヒット数
測定方法 特定の期間に作成されたアプリケーションの数をカウントします。
なぜこれが重要なのでしょうか？ アプリケーションの着信量を予測し、準備することができます-より多くのエンジニアを時間通りに雇用し、トレーニングします。
私が最初にサポートに来たとき、私たちは文字通りの意味で「圧倒された」リリースで覚えています。 そして、経験豊富な人が突然病気になった場合、少なくとも何とかしてアプリケーションをばらまくために、6つのシフトを連続して働かなければなりませんでした。 そのため、応答の遅延が最大2週間に達しました。 私たちはユーザーに電話し、彼らは言った：「 あなたは知っている、私はすべてを再インストールした、あなたは長すぎると答えた 。」
着信アプリケーションの数に関するデータが数年にわたってあるという事実により、リソースを適切に割り当てて計画する方法を学びました。 今では、ほとんどすべてのリリースが非常に穏やかで見過ごされているため、これまで夢にも思わなかったほどです。
2016年には、1日あたりの最小リクエスト数-1アプリケーション（10月9日）と最大数-52アプリケーション（3月16日）を記録しました。 驚くべきことに、1月の祝日でさえ、1日あたり平均8〜12のアプリケーションが届き、電話がない日は1日もありませんでした。
IRT-新規アプリケーションの初期応答時間または処理時間
測定方法 新しいアプリケーションの合計反応時間をとり、一定期間に作成されたアプリケーションの数で割ります。
なぜこれが重要なのでしょうか？ テクニカルサポートからの応答を長時間待たなければならない場合、誰もそれを好みません。 平均して、ユーザーは1時間以内にソーシャルメディアリソースでの回答を待ち、24時間以内に自分のメールへのリクエストを待ちます。 ここでは、自動応答は考慮されていません。「アプリケーションが作成されました」、問題に関する情報を含む通常の適切な応答のみです。
どういうわけか、私も実験を実施しました。私は5つの異なる企業で申請を行い、回答を待ちました。 24時間以内に私に連絡するという自動返信を含む2つの手紙がすぐに届きました。 30分後、彼らは会社＃3から私に答え、解決策を提供し、＃4は平均して約7時間答え、最後の手紙には答えがなかった。 驚いたことに、私に連絡するという約束の後、企業＃1と＃2は長い間失われました。1つの答えが数日後に、もう1つの答えが1週間後に届きました。
最初に企業クライアントへのサポートを提供し始めたとき、私たちはどれほど迅速に対応するのか分かりませんでした。 それらを実装するために実際に必要なSLAは何ですか？ IRTのダイナミクスを3か月間監視し、「ヒューマンファクター」やリリースを含むすべての種類のコンポーネントを考慮に入れ、現在では期限を認識し、それを超えるよう努めています。
FCR-最初の連絡先の解決または1回の応答で解決されたアプリケーションの数
測定方法 Parallelsでは、1つのアプリケーション内のインタラクションの数を追跡し、最初の応答で解決されたアプリケーションをカウントすることが常に慣習となっています。 ユーザーは新しいアプリケーションに戻ることができますが、明確な質問があるため、最近の傾向と議論から判断すると、これは完全に真実ではありませんか？ 多くの企業は、サポートに連絡した瞬間から7日間ユーザーを「フォロー」します。 ユーザーが一度来て、決定を受け取った後に再び電話をかけなかった場合-これは素晴らしい、FCRです。
なぜこれが重要なのでしょうか？ エンジニアが最初の答えからアプリケーションを決定した場合-これは、チームの技術的な「ポンプ能力」の指標です。 また、最初の回答から解決されたチケットの質問を追跡することにより、ナレッジベースのどの記事を実際に書く必要があるか、および製品ドキュメントに追加する情報を理解できます。
FCRは、サポートラインと製品によって大きく異なります。 たとえば、個人向けのサポートの2行目では、FCRは企業顧客向けのサポートの1行目と一致しています。 ここで理由は簡単です-大企業には独自の管理者がいます。彼らはすでに初期の分析と問題を実行しており、彼ら自身がそれを解決できなかったときにのみやって来ました。
TTR-解決までの時間
測定方法 アプリケーションを作成してから問題が解決するまでの合計時間をとり、一定期間に作成されたアプリケーションの数で割ります。
なぜこれが重要なのでしょうか？ アプリケーションの解決が速いほど、ユーザーの満足度は高くなります。
しかし、シフトエンジニアが自分で問題を解決できない場合はどうでしょうか。 開発、QA、またはマーケティングに携わる必要がある場合はどうでしょうか？ それは、あなたの会社でプロセスがどれだけ効率的かつ正確に構築されているか、平均的なユーザーが来た結果をどれだけ早く受け取るかにかかっていることがわかります。 そして、すべてが迅速かつ明確になり、アプリケーションが正確に「スタック」している場所を簡単に追跡できるように構築する必要があります。 たとえば、1.5年で、スキームを3回変更しました。アプリケーションを「さらに」エスカレートする方法、特定の状況で誰が書くべきか、どこに電話をかけるか、そして最も重要なのはどの情報を提供するべきかという明確な指示があります。
また、人生の例です（テクニカルサポートではなく、サービスに関するものであり、非常に示唆的なものです）。 先週、私は切手のために郵便局に行き、良い27分の列に立ちました、そして私が窓に行ったとき、切手がこの窓にあり、私はもう1つ、2番目のものが必要であることがわかりました。 2番目のウィンドウには誰もいなかったので、再び黙って待たなければなりませんでした。 さらに9分、私はすでに仕事に遅れており、その後スヴェトラーナが現れます。 2分後に、スヴェトラーナは切手について知っておくべきすべてのことを私に話し、37と35の切手がどのように異なるかを説明し、郵便はがきをすぐに彼女の窓に持って行くように申し出ました。 私はスヴェトラーナを待っていたことを後悔しませんでした。 彼女が私のリクエストを迅速に解決した方法は、退屈な待ち時間を解消し、私はこのサービスにとても満足していました。
QA-品質保証またはアプリケーション品質
測定方法 エンジニアの実行されたアプリケーションが選択的にチェックされ、推定が行われ、一定期間の平均推定が取られます。
なぜこれが重要なのでしょうか？ 量と迅速な回答で、品質を失いたくないからです。
特に多くのアプリケーションがあり、各アプリケーションに多くの情報がある場合、他の人の作業を評価することは困難です。 さらに、評価は主観的なものになる可能性があります。誰もが異なる考えを持っているからです。 何らかの客観性を持たせるために、アプリケーションを評価するいくつかの主要なブロックを含む特別なフォームを開発しました。 QAマネージャー（ちなみに、過去にエンジニアであることを忘れないでください）は「yes / no」のみを設定し、最終スコアは自動的に計算されます。
また、評価に挑戦するためのルールもあります。 調停のようなものであることがわかります-それぞれがその観点を表現する2つの利害関係者と客観性を表現する独立した専門家がいます。
そしてもちろん、 CSATは顧客満足度または顧客満足度です 。これについては詳しく説明しませんが、それは重要ではないからではなく、彼らが常に最も確実に誰もが知っているからです。 私たちにとって、これは最も重要な指標の1つです。最も重要なことは、ユーザーが満足しているということですね。 私たちは常に「悪い」レビューを分析し、良いレビューを誇りに思っています。
エンジニアが自分で「 幸福の貯金箱 」を作成することを強くお勧めします-良いものをすべて集めて自分の手で保持することで、時々あなたがここにいる理由を読んで理解することができます。 個人の貯金箱からの例（スペルと句読点を保存）：
もちろん、セカンダリメトリックもあります。 いくつかの特別な場合に年に一度得られる数字があります。 しかし、メトリックから逃れようとする状況があります。 彼らはどの方向を見るかを示すことはできますが、全体を語ることはできません。 人々は常に数字の後ろに立ち、人々は間違いを犯し、違った考え方をします。そして一般に、KPIをやる気をそそるものと考えることがあります。 参加するか、捨てるか、単に指標に従うか-常にすべてをチームとボスに伝えてください。
それで、最後に、KPIはどうあるべきか、そしてあなたがそれらを必要とするかどうか決定する方法は？ メトリックは優れた実績のあるツールだと思います。 しかし、彼には明確で詳細な指示が必要です。 20世紀で最も影響力のある管理理論家の1人であるピータードラッカーは 、測定できるもののみを管理できると述べました。 時間をspareしまないで、自分で整理して、なぜ、何のために、どのようにチームの全員に説明してください。
基本原則に従ってください ：
- 選択する指標は、会社のグローバル目標を達成する必要があります。 技術サポートを最も反応のよいものとして知られるようにするには、新しいアプリケーションの反応時間/処理時間を測定します
- 受け取った数字を現実と相関させる-ある角度から写真を見ないようにするには、いくつかの参照指標が必要です。 視野角を広げ、特定の数字を追加して確認してください：本当ですか？ そうでない場合、選択したメトリックが正しくないことを意味します
- チームがメトリックに影響を与える必要があります。 例として、着信アプリケーションの数でさえ、何らかの形で影響を与えることができます。 最も単純なものから-すべてのユーザーが同じ質問で来ていることがわかった場合は、KBナレッジベースでこの記事について書いてください。 トライト？ 次に、PMプログラムマネージャーでFRタスクを開始して、製品をより便利にします。
- チームの全員が、彼の現在の目標と目標の達成方法を理解する必要があります。 定期的に話し合ってください。 進行状況を監視するために、これを週に1回または1か月に1回試行します。
そして最後に、数字は真実を物語っています。 はい、はい、痛いときでも。 本当に痛いです。 これにも備えてください。
Z.Y. KPIトピックは非常に興味深いことがわかったため、最近のSupNetマネージャーとテクニカルサポートスペシャリストの会議で議論しました。 リンクは会議から報告されます。 ちなみに、Facebook ページのような次のmitapに参加してニュースをフォローしたい場合は。