アカウントエスカレーションに関するサポートエンジニアリングマネージャーガイド
概要
このページでは、カスタマーアカウントエスカレーション におけるサポートマネージャー DRI の役割について、サポートマネージャー向けにガイダンスを提供します。
アカウントエスカレーションは、サポートエンジニアリング（サポートマネージャーまたはエンジニア）から カスタマー緊急事態をエスカレーションへ転換する ことで開始される場合や、STAR の結果として開始される場合があります。また、エスカレーションの種類（すべてのアカウントエスカレーションがサポートの関与を必要とするわけではありません）と 重大度 に応じて、カスタマーサクセスチームが アカウントエスカレーションを開始 し、サポートチームに支援を依頼することもあります。
アカウントエスカレーションチーム
各エスカレーションには エスカレーション DRI がいて、エスカレーションを成功裏に解決するために貢献するチームを率います。チームは以下の役割の一部（最低でもエスカレーション DRI、リードサポートエンジニア、サポートマネージャー DRI）または全てで構成されます。
- エスカレーション DRI（CSM、AE、または CSE マネージャー）
- リードサポートエンジニア
- サポートの関与に関するサポートマネージャー DRI
- 関与する他の CSM リーダーまたはアカウントマネージャー
- プロダクトマネージャー
- 開発エンジニア
サポートマネージャー DRI の責務
サポートマネージャー DRI には以下の目標があります。
- 不確実性を明確に定義されたリスクへと変換することで、不確実性を最小化する
- エスカレーションの終了基準（ゴール）を定義し、それらの基準達成に向けたサポートチームの取り組みを導く
- リードサポートエンジニアを任命し、エスカレーション DRI とアクションプランをすり合わせる
- エスカレーションに関連する他の重要な詳細とともに、エスカレーション Slack チャンネルでタイムリーに更新を提供する
- エスカレーションがクローズされた後、エスカレーション DRI とともにエスカレーション振り返り Issue に取り組む
不確実性
不確実性とは、未知の情報がある状況のことです。マネージャーとして、私たちは不確実性を明確に定義されたリスクへと変換し、プロアクティブに管理できるようにするための適切な質問をする必要があります。不確実性は備えることができないものであり、ほとんどの状況では、状況解決のためにリソースを不必要に消費する原因となります。
不確実性の例
次のシナリオを考えてみましょう。
あるお客様が LDAP 設定の問題を抱えており、ユーザーが認証できないという報告がありました。サポートチームは 2 日間にわたり、お客様の LDAP 設定からの想定に基づいて問題を調査しました。3 日目になって、お客様の新しいコメントから、お客様が誤った設定の LDAP プロキシを使用していることがわかりました。
このプロキシの存在を知らなかったことが「不確実性」を生み、トラブルシューティング期間が長期化し、結果として問題解決にかかる時間も延びました。お客様のアーキテクチャについて質問していれば、この情報をもっと早く得ることができ、プロセスの早い段階でより良い行動方針につながった可能性があります。
すべての不確実性を考慮できるわけではありませんが、私たちはリスクを減らす努力ができます。それにより、エスカレーションの終了基準達成に向けて作業範囲をより適切に絞り込めます。
ワークフロー
アカウントエスカレーションのサポートマネージャー DRI を務めるには、以下のステップに従ってください。
ステップ 0: 準備
カスタマーサクセスエスカレーションプロセス が遵守されていることを確認する。
お客様のタイムゾーンを念頭に、エスカレーションに最適なリードサポートエンジニアを判断する助けとなるよう、エスカレーションが必要となった原因のお客様の課題を明確に把握する。お客様が最近開いたすべてのサポートチケットをレビューすることで、この範囲をさらに明確化できます。
NOTE: 私たちは現在、AMER で エスカレーションフォーカス型サポートエンジニア役 を この Issue に基づいて試行しています。最初の連絡先として、テクニカルリードを務めてもらうか、リードサポートエンジニアに技術的なガイダンスとサポートを提供してもらうため、指定されたエンジニアにご連絡ください。
組織のエスカレーションステータスは Salesforce アカウントから直接同期されます。つまり、組織がエスカレーションされていると標識されるには、対応する Salesforce アカウント側でそのように表現されている必要があります。
エスカレーション状態にあると、チケットの組織ノートにそれに関するメッセージが含まれるようになります（これは組織がエスカレーション状態にある間に作成されたチケットにのみ適用される点にご注意ください）。
ステップ 1: リードサポートエンジニアの割り当て
アカウントエスカレーション中に リードサポートエンジニア として行動するサポートエンジニアを割り当てます。エスカレーション DRI と協力し、エスカレーション対象のお客様のリージョンに合わせて、エンジニアの所在地として最も適したリージョンを判断します。
エスカレーションがグローバルな取り組みを必要とする場合は、オンコールマネージャーと協力して、それらの他のリージョンのリードサポートエンジニアを特定します。
AMER リージョンの場合は、エスカレーションフォーカス型エンジニア に連絡し、リードを務めてもらうか、すでに別のエスカレーションをリードしている場合はバックエンドサポートを提供してもらいます（詳細は この Issue を参照）。
リードサポートエンジニア（必要に応じてそのマネージャーも）と同期し、ワークロードを評価します。
- 必要に応じて、エスカレーションに優先的に取り組めるよう、割り当て済みのチケットや他の責務を引き継ぐ手伝いをします。
注意
技術的な観点から、リードサポートエンジニアは解決をオーケストレートしますが、エスカレーションの唯一の技術オーナーであることは期待されていません。リードサポートエンジニアの役割は、すべてのリージョンと開発チーム間の協働を導き、問題の迅速な解決を確実にすることです。
ステップ 2: スコープと終了基準を定義する
エスカレーションチームと一緒に、明確な作業スコープを定義します。終了基準（ゴール）を明示するようにしてください。スコープと終了基準の両方をサポートエスカレーション Slack チャンネルに記録する必要があります。
お客様との協働を通じて、エスカレーションに直接関連するチケットを特定し、それらもチャンネルに記録します。
- リードサポートエンジニアは、関連するすべてのチケットを担当として割り当てられるべきです。
- サポートマネージャー DRI は、関連するすべてのチケットの CC リストに自分自身を追加するべきです。
エスカレーション対象のチケットに集中し続けるために、エスカレーションのスコープ外の優先度の低いチケットは遅延する可能性があることをお客様が理解していることを確認してください。
ステップ 3: エスカレーションの進捗更新
エスカレーションチームと協力し、アカウントエスカレーションに関連する Slack チャンネルで日次または週次の更新を提供します。これは #esc_<CUSTOMER> 形式の名前のチャンネルです。これらの更新には以下を含めるべきです。
- 終了基準達成に向けた進捗
- ステータス
- 関連するチケットを伴う現在のタスク
- 次のステップ
- ブロッカー
エスカレーションチームと協力して、Slack チャンネルを最新の状態に保ちます。エスカレーション DRI はこの情報を使って Salesforce ケースを更新し、それが信頼できる唯一の情報源（SSOT）として機能することを保証します。
日次更新の一時停止
エスカレーションは、複数日にわたって動きが見込まれない「監視」期間に入ることがあります。このような場合は、日次更新を一時停止することが適切です。これを行うには、アカウントエスカレーション用の Slack チャンネルに投稿し、1) エスカレーションの現状、2) 更新を再開する想定タイムラインを明確に定義します。例えば次のとおりです。
ステータス: お客様は 5 日後（2023 年3 月15 日）に本番環境で Redis をアップグレードする予定です。 次のステップ: 今後 5 日間、お客様からの更新を監視する。この期間中に問題が報告されなければ、次の更新は 2025 年3 月15 日 を目標とする。
日次更新が一時停止されている間も、更新の再開を促すような動きがないかを毎日チェックし続けます。
ステップ 4: 進捗を評価する
現在のタスクの進捗が遅れていないか、または停滞していないかを判断します。どちらかが該当する場合は、リードサポートエンジニアと協力して、専門の開発チームへさらにエスカレーション し、作業が正しい方向に進むようにします。
ステップ 5: 安定性を評価し監視する
お客様が安定したら、エスカレーションチームと協力してクロージング戦略について合意します。ほとんどの場合、合意した期間お客様をエスカレーション状態のままにし、ステータスを監視します。監視期間が経過してもお客様が安定したままであれば、エスカレーションをクローズします。
アカウントエスカレーションをクローズする前に:
カスタマーサクセスエスカレーションページ に記載されたステップを確認し、必要に応じて協働してクロージングのステップを完了させます。
組織のエスカレーションステータスは Salesforce アカウントから直接同期されます。つまり、組織のエスカレーション状態を解除するには、対応する Salesforce アカウント側でそのように表現されている必要があります。
- お客様が今後開くチケットには
org_in_escalated_stateタグが付かなくなります。組織ノートにエスカレーション状態の見出し 1 ノートも表示されなくなります。
- お客様が今後開くチケットには
ステップ 6: 振り返り
エスカレーションチームと協力して、（エスカレーションのクローズから 3 週間以内に）作成された Issue で振り返りを完了させます。
必要と判断された場合、サポートチームを代表して振り返りの同期ミーティングを主導し、最終的なフィードバックを集め、すべてのチームメンバーが残されたアクションアイテムと期日を明確に理解できるようにします。
FAQ
アカウントエスカレーション中にお客様が緊急チケットを開いた場合、どのように対処すればよいですか？
リードサポートエンジニアの稼働時間中の主な優先事項は、エスカレーション中のお客様です。一般に、エスカレーション中のお客様は 通常の緊急プロセス を トリガーすべきではありません。リードサポートエンジニアがお客様と直接連携し、必要に応じて追加リソースを要請します。アカウントオーナーは、
#a_customer_escalationチャンネルでサポートに緊急事態を通知する必要があります。リードエンジニアの勤務時間外に緊急事態が発生した場合はどうなりますか？
この場合、お客様は 緊急サポートプロセス をトリガーできます。リードサポートエンジニアとマネージャー DRI の間でこの可能性に関する事前認識があり、スケジュールされたオンコールサポートエンジニア、マネージャー、開発チームに事前のコミュニケーションが送られている必要があります。
マネージャーとリードサポートエンジニアは、この期間中「警戒態勢」に入り、可能であればサポートを提供することを検討するべきです。ただし、最低でも、オンラインに戻ったときに緊急事態をレビューし、サポートエスカレーションのインシデントとタイムラインで実施したトラブルシューティングの取り組みを記録し、お客様とのポストモーテムレビューを実施します。
アカウントエスカレーションごとに ZD チケットは 1 件だけですか、それとも複数になることもありますか？
原則として、アカウントエスカレーションは「このアカウントは、何らかの理由で、警戒/リスクの高い状態にある」ということを意味します。
想像してみてください、あなたはとてもお腹が空いていてリンゴを取りに歩いて行こうとしています。横断歩道で割り込んできた車に対して、いつもよりも少しだけ無礼なジェスチャーをする可能性が高くなるかもしれません。
このため、Zendesk の組織には「エスカレーション状態」のチェックボックスがあります。エスカレーション状態にある場合、お客様は全体的に感情と緊急性が高まった状態にある可能性が高いのです。 個々のチケットがエスカレーションの終了基準に関連しているかどうかは様々ですが、すべての接点が全体的なお客様のセンチメントに関わります。
認識し、エスカレーションチャンネルに情報を回し、ポジティブなお客様体験の創出にどの程度貢献できるかをそこにいる人々に伝えてください。一方で、マネージャーとリードサポートエンジニアに、典型的なサポートワークフローから逸脱する必要があるかどうかの判断を委ねてください。
同期ミーティングはどのくらいの頻度で開始すべきですか？毎日？毎週？
同期ミーティングの適切なペースは、エスカレーションチームと協力して決定する必要があります。一般的なルールとして、エスカレーションの重大度に依存しますが、例外もあります。
お客様が安定している場合、アカウントエスカレーションをクローズするまでにどのくらい待つ必要がありますか？
状況次第です。お客様が現在のソリューションに納得していて、インスタンスの状態が安定しているままであることを確認します。エスカレーションチームと同期して一緒に決定し、終了基準が満たされていることを確認します。これに関しては固定のルールはありません。
bfd74782)