BLOG
カスタマーサービスにおける次の進化

「カスタマーサービスソフトウェアはこの10年で大きく進化したが、どれも同じ問題を解決しているように見える！」。これは、全体的な応答時間と解決時間の短縮に関する最近のブレインストーミングの会話で、あるカスタマーサービスリーダーが発した言葉です。

現代のカスタマーサービス担当者の役割は、ますます複雑になってきています。カスタマーサービス担当者は、高度な共感とコミュニケーションを必要とする最前線の顧客対応に努めなければならないだけでなく、顧客に影響を与える混乱が生じたときに、複数のシステム、チャネル、「信頼できる情報源」を駆使して、バックオフィスのエンジニア／開発／ITチームとコミュニケーションをとり、協力しなければならないという負担がかかっています。テクノロジーの進化と社内システム、ツール、プロセスの複雑化は、問題をさらに深刻にしています。

この点を説明するために、金融サービス会社ABCに勤務するカスタマーサービス担当者の例で、ログイン失敗に関するチケットを受け取った場合を考えてみましょう。カスタマーサービス担当者は、ヘルプデスクシステムのキューの一番上にあるチケットを受け取りますが、このチケットに加えて、同様の問題に関する50件のチケットがキューに蓄積していることに気づきます。オンラインポータルにパフォーマンスの問題がある可能性があることに気づいたカスタマーサービス担当者は、エンジニアリングチームに問題をエスカレーションし、支援を求めました。

このシナリオでは、従来のカスタマーサービスソフトウェアに関連するカスタマーサービスワークフローとプロセスの限界が見え始めています。このソフトウェアは、カスタマーサービス担当者が単発の顧客要求を迅速に解決して対応できるようにチケットキューを整理して優先順位をつけるなど、フロントオフィスでの顧客とのコミュニケーションやチケットに関する問題を解決する素晴らしい機能を備えています。しかし、システム停止やバグなどの中核的な問題を解決するために、バックオフィスのエンジニア／開発／ITチームの支援を必要とする場合はどうでしょうか。

カスタマーサービス担当者は、技術的な問題をエスカレーションするためのワークフローやプロセス、そして解決に向けた進捗状況の可視化など、多くの課題に直面しています。典型的なワークフローは、次のようなものです。

1. 顧客がパフォーマンスの問題に遭遇し、カスタマーサービスにヘルプデスクチケットを提出する。
2. カスタマーサービスは、ヘルプデスクシステムでチケットを受け取る。
3. カスタマーサービス担当者は、コミュニケーションプラットフォームのタブを切り替える。SlackやTeamsの共有チャンネルで呼びかけ、（場合によっては個々の専門家に）表面化した技術的な問題にバックオフィスでも気づいているかどうかを確認する。
4. この例では、エンジニア／開発／ITチームは気づいていない。カスタマーサービス担当者は、社内のWikiやスプレッドシートを参照し、どのチームがサービスを担当しているかを把握する。
5. カスタマーサービス担当者は、別の社内ヘルプデスクシステム（Jiraなど）に移動し、社内チケットを提出する。
6. エンジニア／開発／ITチームがインシデントを解決すると、コミュニケーションプラットフォームに更新が投稿される。
7. カスタマーサービス担当者は、ヘルプデスクチケットシステムとコミュニケーションプラットフォームを同時に切り替えて、情報を収集し、顧客に対応しなければならない。

さらに、可視性の問題から、カスタマーサービス担当者は自分自身や他の人に問いかけます。

• バックオフィスのチームは、顧客に影響を与えるテクノロジーの問題を認識しているのか。
• 修正作業は行われているのか。
• この問題について、顧客に伝えられることは何か。
• この問題の解決に向けた進捗状況はどうか。どれくらい時間がかかるか。

最悪なのは、顧客のチケットが技術チームに引き渡されると、カスタマーサービスの評価基準となるビジネスルールや成功基準が適用されなくなることです。その結果、初回コンタクト解決率、応答時間、解決時間、および顧客満足度に悪影響が生じます。これは、タイムリーな顧客対応に必要な手段や可視性をカスタマーサービスが欠いているためです。

今日、ほとんどのカスタマーサービス組織は、技術チームからサイロ化されています。このサイロ化の影響は、コラボレーションを促進するためのツールやシステムによってさらに悪化します。例えば、カスタマーサービスは、面倒なコピー＆ペースト作業によってさまざまなプラットフォームで情報を重複させ、他のチームが技術的な問題を解決している間に、複数のシステムに注意を散らしていることがよくあります。

カスタマーサービスとエンジニアの両チームとの会話からは、顧客体験を向上させるために、コミュニケーションの壁を取り払い、コラボレーションすることを強く望んでいることが分かります。エンジニア／開発チームは、デジタル資産の健全性を示すもう一つの重要なシグナルとして顧客を扱い、ダウンタイムを減らすことに注力しています。一方、カスタマーサービスチームは、顧客の期待に応えるために応答時間と解決時間を短縮することに引き続き注力しています。技術的な問題が最初に顧客から提起された場合、カスタマーサービスチームは、顧客に影響を与える混乱を正しくエスカレーションするための合理的な方法を必要としています。特に技術チームによる技術的な問題の解決を含むときは、顧客チケットのライフサイクルの始めから終わりまでが完全に可視化されていなくてはなりません。

そこで、次のような疑問が生じます。バックオフィスのチームが顧客に影響を与える障害に気づいていない場合、カスタマーサービスが顧客の問い合わせやリクエストに迅速に回答し、最前線からテクノロジーの問題をエスカレーションするために必要な可視性と情報をどのように提供すればよいのでしょうか。

異なるアプローチ

カスタマーサービスと技術チームの連携がうまくいっていないことが、ダウンタイムやレスポンス、解決時間の増加につながっていることを組織が認識したとき、異なる視点が必要になります。デジタル資産の健全性を示すもう一つの重要なシグナルとして、顧客を認識するのは今なのです。

「顧客は重要なシグナルである」が受け入れられると、組織はカスタマーサービスと技術チームの間の壁を取り払う方法を見出します。PagerDutyを他のテクノロジースタックの中枢神経系として、またリアルタイムオペレーションを行うメカニズムとして活用することで、各チームはインシデント対応プロセスに従事するために選択したシステムを離れることなく「自分の持ち場で働く」権限を与えられます。

PagerDutyをインシデント対応に関わる他のテクノロジースタックと統合することで、各チームは自分が選んだシステムで作業を行うことができます。PagerDutyは、各チームが作業を行うさまざまなシステムやプラットフォームにインシデント情報を配信し、「唯一の信頼できる情報源」となるのです。

カスタマーサービスエージェントが「ABC社」でインシデント関連のチケットを受け取るという以前のシナリオとは異なり、ワークフローは以下のステップに簡略化されます。

1. 顧客がパフォーマンスに問題を感じ、ヘルプデスクチケットをカスタマーサービスに提出する。
2. カスタマーサービスは、ヘルプデスクシステムでチケットを受け取り、会社のバックエンド技術に問題があることに気付く。
3. カスタマーサービス担当者は、ヘルプデスクチケットのシステムUIに直接ある内部ステータスダッシュボードで、デジタル資産の健全性を確認できる。
4. 技術的な問題が技術チームに知られていない場合、カスタマーサービスは、特定のビジネスサービスを担当するチームに対して「インシデント」を作成し、トリアージする。アラートは修復に携わるメンバーだけに飛ぶ。
5. カスタマーチケットとPagerDutyインシデントの間には、双方向のリンクが自動的に作成される。解決までの進捗は、チケットプラットフォームのチケット／ケースビューに流れる。
6. カスタマーサービス担当者は全ての情報をリアルタイムで受け取ることができ、顧客対応にかかる時間を短縮することができる。

そして何より、このコラボレーションプロセス全体は、カスタマーサービス担当者が日常業務で使用しているチケットシステム内で直接行われるのです。

カスタマーサービスチームと技術チーム間のコミュニケーションとコラボレーションプロセスを最適化することで、エスカレーションプロセスにおいて顧客に影響を与えるような混乱が発生するリスクを軽減することができます。カスタマーサービスチームは、複数のシステムを行き来したり、プラットフォーム間で同じ情報を重複させたりする必要性を排除できます。その結果、初回コンタクトの解決、応答時間、解決時間、そして最終的には顧客満足度が改善されます。

この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。