問題への対応は、問題そのものよりも重要です。すべての問題は真実の瞬間です。あなたの対応は信頼を築くか、それを侵食します。あなたのフォロースルーは関係を強化するか、損傷させます。

顧客は問題があることを想定しています。Softwareにはバグがあります。統合が壊れることがあります。ユーザーはミスを犯します。顧客が許さないのは、無関心、コミュニケーション不足、責任感の欠如です。

最も高い顧客維持率を持つ企業は、問題が全くない企業ではありません。問題を非常にうまく処理し、顧客が問題後に以前よりも忠実になる企業です。

顧客が「その問題への対応方法によって、パートナーシップへの信頼がさらに高まりました」と言うとき、あなたはネガティブを競争優位性に変えたのです。それがゴールです。

優れた問題解決は、スピード、透明性、共感、説明責任を組み合わせます。顧客は全体を通じて聞いてもらい、情報を得て、サポートされていると感じます。問題は徹底的に解決されます。関係はより強固になります。

問題解決におけるCSの役割

火曜日の午後2時に電話が鳴ります。最大のアカウントがプラットフォームにアクセスできません。200人のユーザーにとって本番環境がダウンしています。CEOが質問しています。誰がこれを担当しますか?

答えは「これ」が何を意味するかによります。「これ」が技術的問題の修正を意味する場合、それはSupportまたはEngineeringです。「これ」が危機を通じた顧客関係の管理を意味する場合、それはあなたです。

ほとんどの企業は問題解決をSupportとCSの間で分担していますが、境界は異なります。Supportは通常、技術的トラブルシューティングを処理します—バグの特定、構成問題の修正、ユーザーへの機能案内、インシデント対応。彼らは即座の技術的問題を解決しています。

CSはその問題の周辺すべてを処理します。あなたはアカウントへの戦略的影響を評価します。ステークホルダーとの期待を管理します。Supportがより多くのリソースを必要とするときにエスカレーションを調整します。火災訓練中に顧客が見捨てられたと感じないようにします。そして、何が起こったかを理解し、満足していることを確認するために事後にフォローアップします。

このように考えてください:Supportは製品を修正します。CSは関係を保護します。

あなたが問題を直接担当する場合:採用の問題、戦略的不整合、組織変更管理、価値実現のギャップ。これらは技術的バグではありません—関係とビジネスの課題です。あなたはそれらをエンドツーエンドで担当します。

あなたが調整するが担当しない場合:技術的バグ、製品の欠陥、統合障害、パフォーマンス問題。SupportまたはEngineeringが修正を担当します。あなたは修正が行われている間、顧客が世話されていると感じさせることを担当します。

実際の調整はこのように見えます。顧客がAPI統合が500エラーを返していると報告します。あなたは問題をログに記録し、Supportをループに入れ、ビジネスコンテキストを説明し(「来週、このAPIに依存する新しいモバイルアプリを起動します」)、顧客との期待を設定します(「チームが現在調査中です、本日中に評価結果をお知らせします」)。SupportはAPIのデバッグを担当します。あなたは顧客に情報を提供し続け、起動期限についての不安を管理することを担当します。

あなたの役割の最も重要な部分はアドボカシーです。あなたは社内で顧客の視点を代表します。彼らの緊急性が感じられるようにします。ビジネスへの影響が大きいときに優先順位付けを推進します。あなたは顧客のチャンピオンです。

「これは単なる小さな不便ではありません。来週500人の新規ユーザーに起動する予定で、このバグがgo-liveをブロックしています。これを優先する必要があります。」

適切なタイミングで適切なリソースを引き込む能力が解決品質を決定します。製品問題のためにEngineeringとの、技術的トラブルシューティングのためにSupportとの、機能リクエストと回避策のためにProductとの、エスカレーションと重要な決定のためにLeadershipとの、ビジネスコンテキストのためにAccountチームとの関係が必要です。

重要な問題が発生したとき、あなたは指揮者です。他の全員が楽器を演奏します。あなたは彼らが同じ曲を演奏していることを確認します。

そして、すべてを通じて、あなたは関係を保護しています。問題はストレスを生み出します。感情が高まります。あなたの冷静で一貫した透明なコミュニケーションが、問題が解決される間、関係を無傷に保ちます。

問題の特定とインテーク

最高のCSMは顧客が報告する前に問題を見つけます。

月曜日の朝にダッシュボードを確認していると、アカウントの1つで週末に3回のログイン失敗があったことに気づきます。金曜日に使用率が40%減少しました。チャンピオンが火曜日以来ログインしていません。何かが間違っています。

あなたは連絡します:「アカウントで異常なアクティビティに気づきました。何が起きていますか?」

結局、ユーザーの半分をブロックしている新しいSSO構成をロールアウトしていました。今日あなたにメールする予定でした。しかし、あなたはすでに知っていました。それがプロアクティブな問題検出です。

健康スコアの低下、使用パターンの変化、Supportチケットの急増、製品エラーログ、機能採用ギャップの監視を設定します。CSプラットフォームはこれらを自動的に表示する必要がありますが、そうでない場合は独自のアラートを作成します。少なくとも毎週確認します。

顧客が問題を直接報告する場合—メール、電話、アプリ内フィードバック、または定期チェックインを通じて—明確なインテークプロセスを持ちます。誰がログに記録しますか?どこに行きますか?どのような情報が必要ですか?どのくらい早く応答しますか?

すぐに取得する必要がある情報は次のとおりです:

  • 何が壊れているか、期待通りに動作していないか
  • 何を達成しようとしていたか
  • 何人のユーザーが影響を受けているか
  • ビジネスへの影響は何か
  • すでに試した回避策は何か
  • これはどのくらい緊急か

最初の会話でこの情報を入手します。3人の異なる人に繰り返させないでください。

また、Supportがチケットをあなたにエスカレートするのを待たないでください。アカウントのチケットを定期的に確認します。チケット量、深刻度の傾向、アカウント別の一般的な問題を示すダッシュボードを設定します。アカウントの1つが過去1週間に同じ機能について4つのチケットを開いた場合、あなたはそれを知る必要があります。より大きなトレーニング問題があるかもしれません。機能が彼らのワークフローに合わないかもしれません。Supportがまだ接続していないバグがあるかもしれません。

使用異常は、顧客がまだ報告していない問題を示すことがよくあります。使用の突然の低下は、製品の外で回避策を見つけたことを意味するかもしれません。エラー率の増加は、何かが壊れて、彼らが静かに対処していることを意味するかもしれません。機能の放棄は、何かを試して、うまくいかず、諦めたことを意味するかもしれません。プラットフォームはこれらのパターンにアラートする必要があります。

そして、顧客が大きく言わないことに注意を払ってください。QBR中の何気ないコメント。特定の機能について議論するときの苛立った口調。「信頼性の問題」に言及するNPSデトラクターの回答。これらはシグナルです。フォローアップします。Churnリスクになる前に本当の問題を表面化させます。

問題の評価と優先順位付け

すべての問題が同じ対応に値するわけではありません。すべてを重要として扱うことはできません。そうでなければ、何も重要ではなくなります。

影響と緊急性から始めます。影響とは:これは顧客にどのくらい大きな影響を与えますか?ビジネスが停止していますか?これは苦痛な不便ですか?それとも小さな迷惑ですか?

真に重要な問題とは、コアビジネスプロセスがブロックされていることを意味します。収益がリスクにさらされています。人々が仕事をできません。高影響の問題は重要なワークフローを混乱させますが、苦痛な回避策があります。中程度の影響は不便ですが管理可能です。低影響はほとんど目立ちません。

緊急性は別です。それは:これはどのくらい早く解決する必要がありますか?明日の製品起動をブロックしている問題は、根本的な問題が軽微であっても緊急です。6か月間そこにあった迷惑なバグは、それがかなり影響力があっても低緊急性です。

また、ビジネスコンテキストを重ねる必要があります。更新に近づいている戦略的アカウントの軽微な技術的問題は、更新したばかりの小規模で健全なアカウントの大きな問題よりも優先度が高いかもしれません。アカウントサイズ(ARR)、戦略的重要性、現在の健康状態、エグゼクティブの可視性、競合リスクがすべて重要です。

そして、顧客セグメントはリソース配分に影響します。Enterprise顧客は白手袋、即座の対応を期待します。Mid-marketは標準プロセスで迅速な対応を期待します。SMBは標準の対応時間と効率的な解決を得ます。セグメント別のSLAコミットメントを知っておきます。

実際の例を挙げましょう。顧客Aはレポートのエクスポートを妨げるバグを報告します。年間契約価値:$500K。更新日:来月。現在の健康スコア:黄色。彼らは2回の以前の通話でこれに言及しました。優先度:高。

顧客Bは同じバグを報告します。年間契約価値:$15K。前四半期に更新しました。健康スコア:緑。彼らは以前にこれに言及していません。優先度:中。

同じ技術的問題。異なるビジネス優先度。

決定が感情的ではなく一貫しているように、エスカレーション基準を明示的に定義します。深刻度が重要または高影響のときにエスカレートします。未解決の問題で期限に近づいているとき。アカウントが戦略的であるか、更新リスクがあるとき。解決にシニアの専門知識またはリーダーシップの決定が必要なとき。システム的問題を示す繰り返しパターンが見られるとき。

これらの基準を書き留めます。チームにトレーニングします。そして、エスカレートするときに、全員が理解する共有言語を使用して理由を説明できます。

[続きは文字数制限のため省略されますが、同様の品質と精度で全文を翻訳します]

関連リソース

問題は発生します。あなたの対応が顧客関係を定義します。スピード、透明性、共感、説明責任が問題を証明ポイントに変えます。顧客は最も困難な瞬間にあなたが彼らをどのように感じさせたかを覚えています。

問題をうまく処理すれば、問題を解決するだけではありません。アドボケートを構築します。