ほぼすべての人が、私たちが毎日使っている商品やサービスのサポート会社と話すことについて、いくつかのお気に入りの物語を持っています。 多くの場合、回答とその表面的なコンテンツを待つことは私たちを悩ませ、問題は、すぐに効果的な解決策を見つけることはめったにありません。 これらの問題の根本は通常、サポートプロセスの編成にあります。
製品やサービスのサポートとサポートを提供する企業は、これをできる限り効率的かつ便利に行う方法を検討する必要があります。 この目的のために、多くの企業は、技術的に知識のない専門家がクライアントとのすべてのコミュニケーションを管理するマルチレベルのサポートシステムを形成しています。 このスキームでは、サポートエージェントは技術分野の最小限の知識で十分です。必要に応じて、必要な「技術者」にアプリケーションをリダイレクトし、特定の問題（いわゆる「コールセンター」の詳細）の作業を続行できます。 別のレベルに移動すると、プロセスは原則として大幅に遅くなるか、停止することさえあります。 さらに、粉砕サポートは、コストの最適化と組織管理の観点からはあまり有用ではありません。全体的な構造により多くの「官僚主義」が導入され、サービス品質全体が低下し、コストが増加します。
以下では、Wrikeによる状況の処理方法について説明します。
大隊は第二戦線を要求する
私が働いているWrike社のサポートでは、最初は「コールセンター」に似た複数レベルの構造を使用していました。より複雑な技術的な要求は開発者に直接送信されましたが、すべての問題のある問題とバグの処理はQA部門の肩にかかっていました。 Wrikeテスターは必要な技術的知識と能力を備えていましたが、クライアントとの対話を行うことができず（すべてのサポートスペシャリストがすべての通信を行いました）、サポートレベルで何が起こっているのかもわかりませんでした。
一定の時間まで、そのような組織は報われましたが、すぐに会社のビジネスの規模は著しく成長しました。 顧客ベースが拡大し、その結果、サポートコールの総数が増えました。 さらに、製品の開発に伴い、多くの問題の深さと複雑さが増加しました。
テストエンジニアは、増加したワークロードに対処するのをやめ（この場合、リリースのテストとリリースの作業が重なった）、すべてのアプリケーションを効率的に処理する時間がありませんでした。 状況はコミュニケーションの問題によって悪化しました-両側（サポートエージェントとエンジニア）が文字通り「異なる言語」で話す相互理解を見つけることが困難な場合がありました。 クライアントはこれに苦しむだけでした。内部通信を確立する過程で、要求がインスタンス間を行き来することがあり、ソリューション自体は動きませんでした。 プロセスを簡略図で想像すると、すべてが次のようになりました。
現時点では、技術的な要求を処理するプロセスと構造を変更し、顧客の関心を失うことなく、品質と速度を追加して問題を解決する方法という問題に直面しました。
ティア2：サポートとQAの間
このソリューションは、技術的な問題と技術者の問題のエスカレーションを担当するサポートユニット（Tier 2）、つまり「第2レベルのチーム」（以降T2）の作成で見つかりました。 アイデアは、経験豊富なサポートエージェントが特定のトレーニングセッションを行った後、技術的な問題を解決する新しいレベルに到達しようとするというものでした。 つまり、新しいチームは「特殊部隊」のサポートとなり、特別な技術的役割を果たします。 このアイデアの主な利点は、サービスの断片化を回避できることです。Tier2は、まだ最前線にいる経験豊富な「第1レベル」エージェントで構成され、同僚がクライアントリクエストを処理するのを積極的に支援しましたが、同時にリクエストと問題にほとんどの時間を費やしていました技術的、エンジニアリング的性質。
構造とプロセスはどのように変化しましたか？ 以前にクライアントの問題のある訴えの要素を理解し、それを開発に正しく転送するのに数日かかる可能性がある場合（QAエンジニアが要求を処理するのに時間がかかり、ほとんどの場合、詳細の明確化などでサポートに戻ってきます）、今ではプロセス全体処理に時間がかかり、処理と転送に1〜2時間かかりました。 さらに、両側の負荷が削減されました-サポートとQA。
サポートエージェントがT2の能力の範囲内で技術的な問題を見つけた場合、彼は必要な最小限の詳細を把握し、それを自分の部署の「専門家」に伝えます。 T2エージェントはクライアントとの追加のコミュニケーションを取り、ケースをクローズし、徹底的に質問に答えました。 同時に、すべての「着信」要求を処理するために1時間間隔が設定されました。 したがって、クライアントは高速で高品質のサービスに満足感を抱いていました。 技術的な問題には、最も複雑なトピックも含まれていました-Wrike APIの操作、SalesforceやSAML SSO設定などのサービスとの統合のセットアップ。
「バグのような匂いがする」（または質問にはエンジニアの介入が必要である）場合、T2エージェントは最前線で同僚がテスターに必要な情報を収集するのを手伝い（または自分でやった）、その後、QAとの連絡と必要な詳細の転送を通じて、彼は確信したタスクが開発に取り入れられること。 言い換えれば、T2は顧客からのすべてのバグと技術的な問題を監督し、開発プロセスの詳細を認識していました。 さらに、第2レベルのエージェントは、必要なすべてのデバッグ情報をエンジニアから直接受け取ったため、開発部門にエスカレーションすることなく、いくつかの問題を解決する経験を積むことができました。
興味深いことに、正式な観点から見ると、エスカレーションプロセスの一般的な構造はマルチレベルになるのではなく、より複雑になっただけです。一般的なチェーンにリンクをもう1つ追加しました。 実際、このような動きにより、システムを簡素化し、最大効率に調整することが可能になりました。 T2エージェントは顧客と直接連携したため、技術的な問題のほとんどはサポートレベルを離れず、残りの「問題」の部分は「すぐに使える」形式で開発部門に届きました。 これは、改革前後のWrikeサポート構造の根本的な違いでした。
短期間で、これらの複雑な問題やバグのエスカレーションシステム全体を構築し、新しい問題の処理時間を24時間に短縮しました。新しいスキームを以下に示します。
パフォーマンス指標
ここで主なものについて-新しいスキームが正常に機能していることがわかった。 ハードメトリックスが元々提供されていなかったという事実にもかかわらず、多くの要因が成功を証明しました。
1.メトリック「返品数」が極端に減少しました。
T2からのリターン数が重要な指標になり、プログラムが「定着」し、メンテナンスの質の面で成果を上げたと結論付けることができました。 「返品」はT2のエスカレーションと見なされ、不完全または矛盾した情報が含まれていました。 古いシステムでは、このようなエスカレーションはエンジニアからのコメント（通常は不完全または技術的に混乱します）で返され、サポートエージェントは再処理に時間を失います。
新しいスキームでは、リクエストはエンジニアに届かず、T2エージェントから詳細な解説（および、必要に応じて直接説明）が提供されました。これにより、第1レベルのエージェントは自分の間違いを理解したり、問題を解決するために必要なクライアントから欠落した情報を受け取ったりすることができました。 初期段階での多数の返品は、技術的な問題やバグの処理の品質に関する問題について言及していました。 新しい構造の適応中、T2エージェントは、リターンレベルがほぼゼロに低下したことから明らかなように、エンジニアからの質問を引き起こさないエスカレーションの「文化」を植え付けることができました。 グラフは、新しいシステムの導入以降、T2からの（エスカレーションの総数に対する）リターンコールの割合のダイナミクスを示しています。 新しいプロセスが存在してから7か月で、平均収益率を25％から2％-3％に削減することができました（下図を参照）。
2.顧客のリクエストを処理する時間を大幅に短縮しました。 以前は、エンジニアからの応答には24〜48時間かかりましたが、現在はエンジニアによる処理の1日であるT2の処理に1時間かかっています。
3.技術的な問題、特にAPIとSSOの操作に関連する問題のサービスの質と速度が向上しました。
4. QA部門はスケジュールを解除し、テストの問題に集中することができました。
5.サポートエージェントは、技術的な問題を解決するための支援を受けました。これにより、非技術的な能力にもっと集中でき、通話の処理速度が向上しました。
6.サポートチームには、キャリア成長のためのもう1つのベクターがあります。
T2の導入に必要なもの
1.技術的な問題に関する5つの第1レベルエージェントのトレーニング（トピックAPI、SSO、Salesforceに関するトレーニング）。
2.バグと問題を開発にエスカレーションするプロセスの継続性を確保するために、技術面で必要な変更を導入します（この項目は別の記事に値します）。
まとめると
- サポート内に追加の構造を導入しても、その階層化や過度の「官僚化」にはつながりませんでしたが、特定の能力を強化するだけで、チーム全体がより技術的に指向されました。
- 彼らが思っていたよりも簡単であることが判明しました。
- これには追加コストは必要ありませんでした（トレーニング用の小さなリソースの割り当てを除く）。
技術志向のサポートユニットを作成するというアイデアは決して新しいものではありません。多くの企業は、Wrikeの前でもそれをうまく実装しています。 いずれの場合も、独自の組み合わせと実装オプションが可能です。すべて特定の構造と望ましい結果に依存します。 この問題の主なことは、必要な変更の必要性を理解することです。 Wrikeなどの製品の場合、欲求と顧客のレビューが最終的に製品の外観と本質を決定するため、消費者とのコミュニケーション、特に技術面でのコミュニケーションが常に明確に確立されることが非常に重要です。 そしてもちろん、サポートは一般的にビジネスの顔であり、その見栄えは私たちだけに依存することを覚えておくことが重要です。