750 測定値

顧客サポートのオージェアン厩舎への取り組み: 私たちのサクセスストーリー

に Social Discovery Group6m2023/05/05

長すぎる; 読むには

Social Discovery Group のチームは、4 年間で蓄積された 1,500 件のチケットのバックログをクリアするという困難な課題に直面しました。この記事では、部門のプロセスを再構築するために行った手順について説明します。私たちは STATIK アプローチを採用しました。これは、バックログを解消するのに非常に効果的であることが証明されました。

featured image - 顧客サポートのオージェアン厩舎への取り組み: 私たちのサクセスストーリー

かつて、Social Discovery Group のビジネスサポート部門は、4 年間で蓄積された 1,500 件のチケットのバックログをクリアするという困難な課題に直面していました。

このような大量の問題を管理することは大変な作業であり、KPI を維持するのに常に苦労していました。

私たちの最善の努力にもかかわらず、チケットはスプリントごとにシャッフルされ続け、顧客は不満を抱き、私たちは圧倒されました.

この記事では、ヘラクレスの伝説的な第 6 の労働を思い起こさせながら、この一見不可能な仕事に取り組んだ経験を共有したいと思います。

SDGroup チームが直面した課題と、部門のプロセスを再構築するために取った手順について説明します。

私たちは STATIK アプローチを採用しました。これは、バックログをクリアし、チームに必要な救済をもたらすのに非常に効果的であることが証明されました.

したがって、チケットのバックログに取り組むための実用的な洞察を探している場合は、読み続けてください!

1,500 チケット待ち行列に至った経緯

ビジネスサポート部門として、私たちはサービスに関するクライアントの苦情や提案を含むチケットを処理する責任があります。

たとえば、クライアントが当社のウェブサイトの支払いシステムで問題を経験した場合、SDG テクニカルサポートチームに問題を提起することがあります。

同僚は、問題の再現手順やスクリーンショットなど、すべての関連情報を収集し、Jira でチケットを作成して、部門に割り当てます。

その後、追加のテストを実行して、問題が一時的な顧客の不具合ではなく、実際に発生した問題であることを確認します。確認された場合は、バグレポートを作成し、優先順位を付けて、解決のために開発チームに転送します。

平均して、1 日 20 ～ 30 枚のチケットを受け取っていました。問題の再現に 2 ～ 3 時間を費やしましたが、ケースの詳細、サービスの再起動、データベースからのデータ、開発チームからの分析など、他の部門からの支援が必要になるたびに、タスクが滞る傾向がありました。

私たちの同僚はしばしば迅速に対応することができず、バグレポートに割り当てられた別の開発者チームはありませんでした。さらに、開発チケットは、ビジネスタスクに比べて優先度が低かった。

その結果、優先度の高いチケットでさえ数か月間未解決のままになる可能性があり、優先度の低いタスクは何年もボードに残っていました。

お分かりのように、この流れは期限を守る上であまりにも多くの不確実性をもたらし、それが私たちと私たちのクライアントの両方に不満をもたらしました.この状況により、いくつかの問題が発生しました。

問題が十分に迅速に解決されなかった場合、クライアントはストレスと不満を感じ、明確なタイムラインを提供できませんでした.
クライアントがほぼ毎日、未解決の問題の更新を要求したため、当社のサポートチームは不満を感じていました。
サポートチームが私たちに書いたメールには、「問題はまだ解決されていません」という同じ回答がありました。
私たちのチームは過負荷で、古いタスクをピックアップして、それらを繰り返し発生するケースとしてリンクすることができませんでした。
ボード上にある 1,500 の未解決のタスクの気が遠くなるような数を見て、私たちは絶望を感じました。前進するにはアプローチを変える必要があることはわかっていました。

これは、その期間中のチケットのライフサイクルの様子です。

問題のバックログを管理しているときに発生した問題のいくつかを見てみましょう。

サポートチームには、問題を迅速に文書化してフィルター処理するためのスクリプトがありませんでした。
「新規」ステータスのタスクは、往々にして行き詰まることがありました。問題を解決するのに十分な情報やアクセス権がない場合、問題は「エスカレート済み」ステータスに移行し、他の部門の同僚に支援を求めました。残念ながら、彼らが応答するまでに数週間または数か月かかる場合があります.また、やってくるタスクの量が圧倒的に多いため、コメントを見逃してしまうこともありました。
最終的に問題を確認した後、「修正待ち」ステータスに移行しました。開発リソースが慢性的に不足しているため、これらのチケットは何年も未解決のままになる可能性があります。クライアントは、将来的により多くのリソースを受け取ることを期待して、チケットをクローズしませんでした.
大量のタスクのバックログにより、重複が発生しました。以前にどのタスクが開始されたかを思い出すのに苦労することが多かったため、それらをマージして閉じるのは困難でした。

この組織化されていないアプローチにより、 4 年間で未解決のチケットが 1,500 件発生しました。

STATIK アプローチとヘラクレスの第 6 の労働

私たちの部門は、顧客の問題を解決するという主要な目的に対処するのではなく、チケットの処理に集中しすぎていることに気付きました。それは、Social Discovery Group 製品に対する顧客の忠誠心を高め、当社のサービスや Web サイトの脆弱性を検出することです。

「仕事量に耐えられないのなら、なぜもっとスタッフを雇わないのだろうか?」と思うかもしれません。しかし、経験上、効率的なプロセスを確立することで、余分なリソースを必要とせずに進めることができます。

同様に、ヘラクレスは、川の流れをアウゲスの厩舎に向け直すことで、たった1日でそれらを一掃することで、彼の労働を一人で完了しました。

チケットボードを効率化するために、Mike Burrows の著書「Kanban from the Inside」を参照し、かんばん方式を実行するための体系的な戦略である STATIK アプローチを実装しました。

STATIK アプローチを実装する際、次の5 つの手順に従いました。

1. ビジネスサポート部門からの顧客の期待を確認し、顧客は提供されるサポートに満足する必要があると結論付けました。これを実現するには、次のことを確認する必要があります。

タスクに関する私たちの作業の透明性により、クライアントはいつでも自分の要求で何が起こっているかを理解できます。
タスクに対する作業の迅速さ。問題がどのような状態であっても、フィードバックのための決定的な時間を提供します。

2. 不満の内外の原因を定義しました。内部ソースは、私たち自身の仕事を妨げ、フラストレーションを引き起こしたものです。

外部ソースは、お客様にフラストレーションを引き起こし、エクスペリエンスを妨げた原因です。

3. ワークロードのソースと性質を分析しました。私たちの部門に提出されたチケットを調査し、そのチケットが送信された部門、頻度、および応答時間と解決策に関する顧客の期待によって分類しました。

4. 現在の能力を評価しました。この段階で、チケットをどれだけ効率的に処理しているかを評価し、1 週間で現実的に管理できるタスクの数を決定しました。

さらに、チケットの開始から本番環境でのバグ修正のリリースまでにかかった平均時間を計算しました。

5. チケットのライフサイクルを再構築し、新しいプロセスを作成しました。

初期のチケットライフサイクル

得られた洞察を使用して、新しいタスクライフサイクルを開発しました。

次に、前述の問題をすべて解決するための包括的なアプローチを実装しました。次の手順を実行しました。

サポートチームが最初のレベルでタスクをフィルター処理するためのスクリプトを作成しました。
問題を調査するために顧客の入力が必要なタスクに対して、一時的な「レポーターに戻る」ステータスを導入しました。必要な情報が 3 日以内に提供されない場合、タスクは自動的にクローズされます。
「エスカレート済み」ステータスを削除し、より具体的な「問題の確認」ステータスに置き換えました。
重複するタスクの確認とクローズに 2 か月以上を費やした結果、最初に作成した 1,500 のチケットのうち、800 の一意のチケットしか残っていませんでした。
サービスレベルアグリーメント (SLA) を実装し、各ステータスにタイマーを設定しました。「問題確認」ステータスには 7 日間のタイマーがあり、「開発」ステータスには 30 日間のタイマーがありました。
「問題確認」ステータスのタスクがあることで、同僚に応答を求める動機になりました。 Jira でコメントする代わりに、プライベートメッセージまたは Slack スレッドを使用して、コミュニケーションアプローチを変更しました。これにより、以前は数週間かかっていた応答時間が 1 日に短縮されました。
「修正待ち」ステータスにタイマーを設定しませんでしたが、お客様とのコミュニケーションとディスカッションにより多くの時間を割り当てました。タスクが実行不可能と判断された場合は、顧客に通知し、より重要なタスクを優先しました。これにより、保留中のタスクが 50% 削減されました。さらに、顧客がタスクの重要性を説明できるミーティングの開催を開始し、ワークロードの優先順位をより適切に設定できるようになりました。
「開発」ステータスについては、30 日のタイマーを設定し、このステータスのタスク数を 4 つに制限しました。これにより、設定された時間枠内でバグを修正することに集中し、ボードの「開発」ステータスで 20 ～ 40 のタスクの不要な視覚的ノイズに圧倒されるのを避けることができました。
私たちのプラクティスが持続可能であることを確認するために、90 パーセンタイルの原則を導入しました。これは、各ステータスのタイマーによって決定されるように、タスクの 90% を時間どおりに完了する必要があることを意味します。 90 パーセンタイルを構築するために、Jira の管理図と Jira ヘルパープラグインを使用してこれを監視しました。
最後に、チームに追加のモチベーションを導入し、90 パーセンタイルの原則に従えばボーナスを約束しました。これは、オーガスがヘラクレスに自分の馬の 10 分の 1 をボーナスとして約束したのと同じです。