Professional Services Growth

ほとんどの企業が問題解決について間違えているものはここにあります：彼らはそれをダメージコントロールとして扱います。最小化し、滑らかにし、できるだけ速く過ぎ去るもの。しかし、クライアントは、物事がスムーズに進むときに物事をスムーズに進めるときの実行方法を覚えるだけではありません。彼らは、物事が横に行ったときにあなたがどのように現れたかを覚えています。

これを支援する研究があります。それはサービス回復パラドックスと呼ばれています。例外的によく解決される問題を経験するクライアントは、問題を持たなかったクライアントよりも忠実になることが多いです。なぜ？誰でも簡単なときに配信できます。難易度を処理する方法は、あなたが本当に誰であるかを明らかにします。優れた問題解決はクライアント関係戦略の中心です。

このガイドは、物事が悪くなったときでも信頼を維持し、解約を防ぎ、クライアント関係を強化する体系的な問題解決プロセスの構築方法を示します。

保持のための問題解決がなぜ重要なのか

プロフェッショナルサービスでは、あなたの評判がすべてです。1つの不利に処理された問題は、数ヶ月の良い仕事を元に戻す可能性があります。そのクライアントだけでなく、彼らの経験について話すすべての見込み客と。

プロフェッショナルサービスでのクライアント解約は費用がかかります。新しいクライアントを獲得することは、既存のクライアントを保持するよりも5～7倍のコストがかかります。そして、クライアントが未解決の問題のために去るとき、彼らはめったに完全な真実をあなたに与えません。彼らは「予算制約」または「優先順位の変更」を引用します。その間、同等にリアルストーリーを伝えます。

しかし、ここに反対側があります。問題を透過的に、迅速に、徹底的に解決すると、スムーズな配信だけでは作成できない何かを構築します。圧力下での信頼。クライアントは、問題が発生したときに、あなたがそれを所有していることを学びます。あなたは明確に通信します。あなたはそれを正しくします。その信頼は長期的なパートナーシップの基盤です。

問題解決を必要な悪ではなく中核コンピテンシーとして扱う企業は、数十年続くクライアント関係を構築します。

問題分類フレームワーク

すべての問題が同じではありません。請求の質問を同じ方法でプロジェクト脅迫の問題のように扱うことは、リソースを浪費し、混乱を作成します。あなたは適切に応答するのに役立つ分類システムが必要です。

カテゴリ別の問題の種類：

配信の問題は、仕事自体の問題です。逃された期限、品質上の懸念、不完全な配信可能物、スコープギャップ。これらはあなたが雇われたことの中核に当たります。

コミュニケーションの問題は、情報フローの破壊です。更新の欠如、不明確な期待、応答のないチームメンバー、ステークホルダーの不整列。これらは、仕事自体が堅い場合でも自信を侵食します。

スコープの問題は、エンゲージメントに何が含まれるかについての不一致です。「I thought that was covered」の紛争、未承認の変更、機能のクリープ期待。これらは多くの場合、より良いアップフロント文書で防止可能です。

チームの問題は人々の問題です。パーソナリティ紛争、スキルの不一致、チームの転換、文化的な不整列。これらは機密的であり、戦術的な問題とは異なる処理が必要です。

請求の問題は請求書、支払い条件、レート変更、費用の不一致についての紛争です。お金と信頼に直接関わるため、これらは慎重な取り扱いが必要です。

重大度レベルと影響：

すべての問題が同じ緊急性を保証するわけではありません。4レベルのシステムを使用して応答をキャリブレートします：

重大な問題は実存的な脅威です。プロジェクトは失敗のリスクにあります。クライアントは終了を脅迫しています。法的公開や重大な財務への影響があります。これらは直後にシニアリーダーシップにエスカレートが必要です。

高い重大度の問題は、配信または関係に大幅に影響します。主要な期限の危機、再作業が必要な品質の問題、経営者レベルの不満。これらは同じ日の応答と毎日の更新が必要です。

中程度の重大度の問題は、パフォーマンスに影響しますが、全体的なエンゲージメントを脅かすことはありません。軽微な遅延、プロセスの欲求不満、個々のステークホルダーの懸念。これらは24時間以内に応答が必要で、定期的なチェックインが必要です。

低い重大度の問題は軽微な不便です。ドキュメンテーション要求、優先度の変更、小さな調整。これらは通常のワークフローで処理できますが、無視されるべきではありません。

重要なのは緊急性の決定です。重大度はあなたに何をするかを伝えます。緊急性はあなたに何をするかを伝えます。既に解決されている重大な問題（ただしドキュメントが必要）は、迅速に急上昇している中程度の問題よりも緊急ではありません。

初期検出と予防

最高の問題解決プロセスは、使用する必要がないプロセスです。問題を早期に捕捉し、フルブロウンの危機になる前に、本当のスキルです。

見張るべき警告兆候：

クライアントの行動の変化は、彼らが明示的に言う前に何かが悪いことを伝えます。彼らは会議を逃すか、意思決定者の代わりに若い人を送ることを始めます。あなたのメールへの応答時間は遅くなります。会話の熱意が低下します。小さなリクエストが簡潔な要求になります。

コミュニケーションパターンシフト。数時間以内に応答するために使用されていたクライアントは、今日数日かかります。または反対のことが起こり、彼らは突然、彼らが以前あなたを処理するために信頼していたことをマイクロ管理しています。両方とも不快さを示しています。

スコープの議論頻度が増加します。クライアントが繰り返し何が含まれているのか、何が追加なのか、何が合意されたのかについて尋ねるとき、それは彼らが価値を疑問に思っているか、小銭を感じていることを意味しています。

支払い行動が変わります。30日以内にお金を得るために使用されていた請求書は、現在60人を取得しています。または、前の支払いが簡単だった場合に、請求書のすべての質問を取得し始めます。これはしばしば不満の最初の有形な兆候です。

チームメンバーは懸念を表現します。あなたの人々は毎日地面にいます。彼らがクライアントが欲求不満に思われたり、ステークホルダーが懸念なコメントを作成したと言及する場合、真摯に取ってください。それがあなたにエスカレートするまで待たないでください。

プロアクティブなモニタリングシステム：

通常の関係健康チェックは、問題が転移する前にそれをキャッチします。クライアント感情を議論するための配信チームとの週に1回の内部チェックイン。「どのように配信しているのか」ではなく「どのように我々が行っているのか」に焦点を当てた月次ステークホルダーコール。

クライアントフィードバックメカニズムは、懸念を提起するための構造化チャネルを与えます。四半期調査、主要なマイルストーン後の遡及、経営者のビジネスレビュー。それがまだ修正可能な場合に、何が機能していないかを伝えることを簡単にしてください。あなたのクライアントフィードバックシステムは、エスカレートする前に問題を表示する必要があります。

プロジェクトの健康ダッシュボードは主要な指標を追跡します。配信可能物はスケジュールに従っていますか？利用はそれであるべきですか？変更命令がたまっていますか？これらのメトリクスはしばしば、クライアントが声を出す前に問題を予測します。

エスカレーションのトリガーと予防措置：

クライアントがあなたにエスカレートする前に、内部的にいつエスカレートするかについての明確な基準を定義します。2つの連続した期限を逃す場合、それは自動的なエスカレーションです。クライアント満足度スコアが閾値を下回る場合、リーダーシップが関わります。スコープ変更要求が元の予算の特定の割合を超える場合は、一時停止して整列します。

予防は治療に勝ります。明確なスコープ文書、定期的なコミュニケーション頻度、積極的なリスク識別、バッファを持つ現実的なタイムライン。ほとんどの問題は、プロジェクトのセットアップまたは管理の予防可能な問題に追跡します。

問題エスカレーションプロトコル

問題が重大度閾値を横切ると、正しい時間に正しい人を関わらせるための定義されたパスが必要です。

レベル別のエスカレーション基準：

低い重大度の問題はプロジェクトチームで留まります。アカウントマネージャーまたはプロジェクトマネージャーがクライアント連絡先と直接対応します。それがパターンになることを除いて、リーダーシップが関わる必要はありません。

中程度の重大度の問題は、24時間以内にエンゲージメントパートナーまたはクライアントサービスリーダーに報告されます。彼らはまだ必ずしも機上にいないが、彼らは認識しており、ガイダンスやリソースを提供することができます。

高い重大度の問題は、アカウントを責任とする実装リーダーまたはパートナーへの直後のエスカレーションをトリガーします。彼らは応答の作成に関わっており、クライアントのリーダーシップと直接関わる可能性があります。

重大な問題は、直後に経営者リーダーシップに行きます。契約終了のリスク、法的問題、または企業評判への脅威がある場合、あなたの管理者パートナーまたはCEOが今知る必要があります。明日ではなく。

エスカレーションパスと応答SLA：

誰もが知っている単純なエスカレーション行列を作成します：

重大度	初期応答	ステータス更新	エスカレート先	タイムライン
重大	1時間	4時間ごと	管理パートナー	直後
高	4時間	毎日	エンゲージメントパートナー	同日
中	24時間	2-3日ごと	クライアントサービスリード	24時間以内
低	48時間	必要に応じて	プロジェクトマネージャー	通常ワークフロー

通知要件：

エスカレートするとき、あなたはドロップを上のチェーンで渡しているだけではありません。次のレベルが効果的に行動できるようにコンテキストを提供しています。

何が起こったか、いつ発見されたか、誰が影響を受けたか、実行された即座のアクション、クライアントが伝えられた内容（またはまだ伝えられなかった）、および次のステップとして推奨している内容を含めます。

スピードは重要ですが、情報品質も同様です。パニックになった「大きな問題があります！」エスカレーション、コンテキストなしは混乱を作成します。15分かけて事実を集め、次に内容を持ってエスカレートします。

ステークホルダー関与の決定：

すべてのエスカレーションは、クライアントが内部的にエスカレートしたことを知る必要があることを意味するわけではありません。シニアリソースを持ち込んで問題を解決するのに役立つなら、それはしばしばクライアントに不可視です。彼らはより速く、より良い解決策を見ます。

しかし、問題がすでにクライアントのレーダーにある場合、伝えてください。「私はこれを私たちの実装リーダーに持ち込みました。彼はこれを解決するために個人的に焦点を当てています。」これはあなたがそれを真摯に受けてていることを示しています。

最悪の動きは、あなたがあなたのリーダーシップに内部的にエスカレートする前に、クライアントがあなたのリーダーシップにエスカレートしたことです。あなたの管理者パートナーが不幸なクライアントから電話を受け、これは彼らが最初に聞く最初の時間で、あなたは2回信頼を失っています。クライアント、および内部的に一度。

初期応答と評価

問題が表面化してから最初の24時間は、全体的な解決がどのように展開するかを決定します。速く移動しますが、スマートに移動します。

確認とタイミング：

問題を直ちに認める。あなたがまだ回答を持っていない場合でも。「私はレポーティング遅延についてのあなたのメールを受けました。私は情報を集めており、1日の終わりまでにあなたに更新があります」は、応答性を示しながら時間を購入します。

クライアントが、あなたが彼らの懸念を受け取ったことを確認するためにフォローアップする必要がある場合、あなたはすでにそれを悪くしました。認める容器についてではありません。それはあなたがそれにいることを示しています。

情報収集方法論：

実質的に応答する前に、実際に何が起こったかを理解してください。関わっていたあなたのチームメンバーに話しかけてください。プロジェクトドキュメント、メール、配信可能物を確認します。コミットメントに対するタイムラインを確認します。物語を形成する前に事実を得てください。

必要に応じてクライアントの説明質問をしてください。「問題を完全に理解していることを確認するために、何を期待した対象とどのようなことを説明してください。」これは防御的ではありません。それは診断的です。

クライアントが最も気にする内容についての仮定を避けてください。戦術的な問題のようなあなたのことは、戦略的な懸念を表します。またはその逆。彼らが自分の視点から影響を伝えさせてください。

根本原因分析：

何が起こったかを理解したら、なぜそれが起こったかを理解してください。表面的な原因はめったに本当の問題ではありません。

レポートは遅かった。なぜ？データ抽出が予想されるよりも長く実行されたため。なぜ？クライアントのシステムはアクセス制限を持っていましたが、私たちはそれについて知りませんでした。私たちはなぜ知りませんでした？スコーププロセスはデータアクセスの技術的デューディリジェンスを含まなかったため。

それが本当の問題です。「レポートが遅かった」ではなく、「私たちのスコーププロセスにギャップがある」。根本原因分析は、症状だけでなく、実際の問題を修正するのに役立ちます。

影響評価とクライアント通信：

正直に影響を評価します。この問題はプロジェクトタイムラインに何を意味していますか？配信可能物に？予算に？クライアントのビジネス目標に？

クライアントと通信するとき、共感と所有権をリードしてください。「これはあなたを実行チームの困難な位置に置くことを理解しています。ここにあなたが起こったことがあり、ここにあなたがそれについてしていることがあります。」

言い訳はない。クライアントまたは外部の要因への指で指さすことはありません。その要因が貢献した場合でも、あなたの仕事はあなたが制御できる部分を所有し、問題を解決することです。

解決計画

問題を理解したら、それを修正する計画が必要です。漠然とした約束ではなく、「より良くする」も、具体的なロードマップも。

ソリューション開発：

良いソリューションは、直後の問題と根本的な原因の両方に対処します。期限が逃された場合、直後の解決策は配信可能物の完成です。根本的なソリューションは、最初の場所で逃したことを引き起こしたワークフローの修正です。

ソリューション開発に正しい人を巻き込みます。技術配信の問題の場合、技術リードが計画の一部である必要があります。コミュニケーション分解の場合、アカウントマネージャーが駆動する必要があります。チームフィットの問題の場合、HRまたは人の操作チームが重量を与える必要がある可能性があります。

可能な場合は複数のオプションを考慮してください。時々急速な解決策があり、不完全で遅い解決策が包括的です。両方をクライアントに提示し、優先順位に基づいて選択させてください。

リソース配分：

問題の解決は、リソースのシフトを必要とすることが多いです。これは、他のプロジェクトから人を引っ張ること、専門家をもたらす、またはシニアの人々が一時的に実行役割に段階化することを意味します。

あなたがそれが何を取るかについて現実的にしてください。2日間で何かを修正することを約束したが、適切に行うのに1週間が必要な場合、そう言ってください。約束の不足と配達の過剰は信頼を再構築します。過度に約束して配達の不足は破壊します。

あなたのチームが必要なものを持っていることを確認してください。既に伸びていて、容量をクリアすることなく問題の解決を一杯にした場合、次の失敗を設定しています。

タイムラインの確立：

チェックポイント付きの明確で具体的なタイムラインを設定します。「できるだけ早くこれを解決します」ではなく、「木曜日の午後5時までにあなたに修正配信物を持ち、火曜日の朝までに草案の準備ができています。」

バッファに構築します。何かが3日かかるのに思うなら、5日をコミットしてください。元の期限の後に新しい期限を逃すよりも早く配達する方が良いです。

計画への客様の整列：

あなたが実行を開始する前に、クライアントがあなたのアプローチに同意していることを確認します。各ステップで何をするつもりなのか、いつそれをするつもりなのか、何を期待できるのかについて話し合います。

明確に尋ねてください：「このプランはあなたの懸念に対応していますか？何かが私たちが見逃していることはありますか？」これは弱いことではありません。それは賢いです。あなたが持っていると思う問題ではなく、彼らが気にする問題を解決していることを確認したいです。

問題が重大な場合、計画の書面による確認を取得します。メールは罰金です。「私たちの電話に従って、ここにあなたが同意したかがあります...」これは明確さを作成し、将来の「I thought you were going to...」会話を防ぎます。

実装コーディネーション：

明確な所有権を割り当てます。1人は計画が実行されていることを確認する責任があります。彼らはすべての仕事をする必要はありませんが、単一の連絡先点とそれが実行を責任とする人です。

内部チェックポイントを設定します。3日間の更新をクライアントに告げたら、1日後にチームをチェックインして、トラック上にいることを確認します。3日目までそこに問題があることを発見するまで待たないでください。

実行と通信

解決計画は、設計よりも実行で失敗することが多いです。問題は多くの場合、コーディネーションが崩壊するか、コミュニケーションが停止することです。

実装の卓越性：

あなたが言ったことを正確に実行し、あなたが言ったことをします。状況が変わり、計画を調整する必要がある場合、直後にそれを通信します。沈黙をしないでください。クライアントがそれに気付かないことを望んでいます。

回復モードにいるときは、品質が速度よりも重要です。修正を急いで、正しくなければ、問題を複合させました。それを正しく行うために時間をかけてください。

進むにつれてドキュメント。何が行われたのか、いつ、誰が、何の結果をしたのかについてメモを保管してください。これは透明性と解決後分析を支援します。

進捗の更新とケーデンス：

クライアントを尋ねる前に何が起こっているのか言ってください。毎日の更新にコミットされた場合、毎日送ってください。「私たちはまだXに取り組んでおり、それは計画通りに進展しており、明日の更新」という更新。

沈黙は不安を作成します。クライアントはあなたが聞かないとき最悪を想定します。定期的な更新。簡潔でさえ、安心感が管理下にあることを提供します。

重大度に基づいて通信頻度を調整します。重大な問題は1日2回の更新が必要な場合があります。中程度の問題は隔日である場合があります。クライアントの不安レベルにケーデンスを合わせます。

期待の管理：

何かが予想より長くかかる場合、早く言ってください。「木曜日までにこれを持っていると思ったが、私たちは追加の複雑さに遭遇しました。新しいターゲットは金曜日です。」それは何も言わないよりも無限に優れており、その後、さらに時間をお願いしています。

コミットできることについて誠実にしてください。不確実性がある場合、それを認める。「木曜日までにこれが解決されると考えていますが、ベンダーの応答に依存があり、制御できません。最悪の場合は月曜日です。」

クライアントは悪いニュースを処理できます。彼らは驚きや壊れた約束を処理することはできません。

ステークホルダー通信戦略：

異なるステークホルダーは異なるレベルの詳細が必要です。経営者スポンサーは「問題があった、影響はここにある、ここに修正する方法がある、ここに解決される」を知る必要があるだけです。日ごとの連絡先は、すべてのステップの顆粒更新が必要な場合があります。

あなたの通信をオーディエンスに適応させます。実装の詳細で経営者を埋めないでください。操作連絡先が実際に起こっていることに疑問を感じているのを残さないでください。

問題はクライアント経営者が関わるレベルに到達した場合、あなたの経営者がそれらと通信していることを確認してください。ピア・ツー・ピアの関係は自信を再構築するために重要です。

ドキュメント化の実装：

すべての通信、決定、実行されたアクションの実行ログを保持します。これは法的に自分を覆うことについてではありません（それはサイドの利益ですが）。「何が起こったときに？」質問に答えることができることについてです。スクランブルなし。

同意と承認を文書化します。クライアントがワークアラウンドを承認した場合、または変更されたタイムラインを受け入れた場合、書面で取得します。「私たちの会話に従って、あなたは確認しました。」

このドキュメンテーションは、解決後レビューの基盤になり、将来の同様の問題を防ぎます。

サービス回復戦略

解決は、直後の問題を修正するだけではありません。関係を修復し、定期的に発生することを防ぎます。

サービス回復パラドックスを理解する：

研究によれば、例外的によく処理されるサービス障害を経験するクライアントは、障害を経験しなかったクライアントよりも満足して忠実になることができます。

なぜ？失敗は文字を明らかにするから。物事がスムーズに進むとき、どんな有能な企業でも配信できます。しかし、物事が悪くなるとき、あなたは誰が現れたか、誰が問題を所有しているか、誰が正直に通信しているか、誰が正しく作るかを学びます。

これは問題を作成して信頼を構築すべきことを意味しません。しかし、問題が必然的に発生するとき、あなたはルーチン配信が示しことができない値を示す機会を持っています。

信頼を再構築する修復アプローチ：

認める容器と謝罪から始めてください。防御的な「間違いが起こります」または「これは私たちの管理外の要因による一部でした」。明確な「私たちはあなたへのコミットメントに短くなりました。申し訳ございません」は重要です。

有形のお詫びをしてください。それは、再び作業する可能性があり、追加のサービスを提供して補う場合があります。料金を調整するか、他の配信可能物を加速します。詳細はジェスチャーをクライアント全体にするよりも少ないです。

直後の問題を修正することを超えてください。それらに何をシステミックに変更したかを示してください。「ここにあります。実装して、これが再度発生しないことを確認しています」は、あなたが何かを学んだことを示しています。

重要なお詫びジェスチャー：

財務的な修復は明確な信号を送ります。料金削減、将来の仕事に対するクレジット、または議論によってできるコストの吸収が、すべてあなたが物を正しくするために打撃を受けることをいとわないことを示しています。

しかし、お金は常に答えではありません。時々クライアントは経営者の注目をより高く評価します。1週間のプロジェクトで個人的に機能する管理パートナーは、割引よりも信頼を再構築する可能性があります。

追加の価値も機能します。余分な分析を投げたり、サポート時間を延長したり、無料の戦略セッションを提供したりすることで、契約を超えて彼らの成功に投資していることを示してください。

重要なのは、ジェスチャーが影響に対して相応に感じられることです。軽微な不便さは大きな譲歩を保証しません。しかし、大幅なねじ込みは大幅な応答を保証します。

プロセスの改善と学習した教訓：

すべての問題は、あなたのプロセスのレビューをトリガーする必要があります。あなたのワークフロー、システム、または慣行に何が許可されましたか？何を変える必要がありますか？

クライアントとそれらの変更を共有してください。「あなたのプロジェクトで起こったことに基づいて、品質レビュープロセスを更新して、追加のチェックポイントを含めました。また、依存関係の新しいコミュニケーションプロトコルを実装しました。」

これはクライアントが彼らのプロジェクトを改善したのではなく、あなたの企業を示しています。それは負性を貢献に変えます。良く文書化された回復は、強力なクライアント証言とケーススタディになることもあります。

体系的に信頼を再構築する：

信頼の修復には時間がかかります。1回の会話または1つのジェスチャーで修正することはできません。週または月の間に一貫した信頼できるパフォーマンスを通じてそれを再構築します。

可視性を一時的に増やします。より頻繁な更新、より多くの経営者の関わり、より多くのプロアクティブなコミュニケーション。あなたが注意を払っていることを示してください。

次の数マイルストーンで完璧に配信します。失敗のメモリを克服するには、コアの仕事での固体実行の文字列が必要です。信頼を再構築するまで危険な新しいイニシアティブを引き受けないでください。

フィードバックを明確に求めてください。「どのように我々が行っているか？コミットして改善を見ていますか？他に何をする必要がありますか？」これは謙虚さと彼らの満足へのコミットメントを示しています。

解決後のフォローアップ

問題の解決は、プロセスの終わりではありません。フォローアップは、実際に関係を復元したかどうかを決定します。

満足度の検証：

解決の1週間以内に、明確にチェックインします。「問題が解決されたと考えています。それが期待通りに機能していることを確認して、あなたの懸念に対処したことを確認できますか？」

沈黙が満足を意味すると仮定しないでください。直接尋ねてください。一部のクライアントは、あなたがオープニングを作成しない限り、懸念がまだあることを自発的に表示しません。

彼らが完全に満足していない場合、これを直ちに知る必要があります。問題がアクティブなままこれに対処することができるように。数週間後に彼らがまだ不幸であることを発見することは、時間と意思を浪費します。

関係の健康評価：

問題をより広い関係のためのチェックポイントとして使用してください。「あなたが経験してきたことを考えると、私は後ろに一歩下がり、期待とコミュニケーションが前に進むことについて整列していることを確認したいです。何が良く機能していますか？何を異なるやるべきか？」

この会話は、直後の問題の一部ではないが、醸造されている問題をしばしば表示します。問題解決モードにいるときに今それらに対処する方が良いです。

関係が完全に修復されているか、残留損傷があるかを評価します。信頼がまだぐらぐらしている場合、あなたのアプローチを調整する必要があるかもしれません。あなたが完全に再構築するまで、より多くのシニアの関わり、より頻繁な経営者のレビュー、より保守的なコミットメント。あなたのクライアント満足度管理メトリクスは回復進行状況を追跡する必要があります。

学習した教訓と文書化：

すべての重大な問題について内部事後分析を実行します。何が起こったのか？なぜそれが起こったのか？何の兆候を逃しましたか？何を異なるやるべきか？その結果として何を変えていますか？

これらの見識が記録されて共有されることを確認してください。教訓がこのプロジェクトに関わった人々の頭にだけ住んでいる場合、別のプロジェクトで間違いを繰り返すでしょう。

学んだ教訓から行動項目を作成します。テンプレート、プロセス、チェックリスト、または訓練への特定の、割り当てられた変更。さもなければ、「学習した教訓」は「議論した教訓と忘れられた教訓」になります。

チームの精神分析とラーニング：

問題を解決した後、あなたのチームをデブリーフしてください。それがどのように処理されたか彼らは何を感じましたか？彼らは異なるやるだろうか？彼らは何のサポートが必要ですか？

これを学習の機会として使用します。チームがよく処理した場合、それを認める。ミステップがあった場合、より良い見た目についてコーチします。問題解決スキルは経験を通じて学ばれ、ブリーフはラーニングが起こる場所です。

チームは結果を理解していることを確認してください。クライアントは解決策を受け入れましたか？関係は無傷です？完全なストーリーを知ることは、彼らがクライアント関係で彼らの仕事の影響を理解するのに役立ちます。

困難なシナリオの処理

すべての問題がストレートフォーワードではありません。一部は挑戦的なダイナミクスのナビゲーションが必要です。

不合理なクライアントの要求への対応：

時々、クライアントは問題をスコープの外、タイムライン、または予算内に何かを要求するレバレッジとして使用します。「期限を逃したので、この追加分析を無料で含める必要があります。」

あなたは正当な修復をスコープクリープ偽装から分ける必要があります。失敗を認め、適切なお詫びをしますが、無制限の負債を受け入れません。

共感で応答しますが明確さ：「あなたが欲求不満であることを理解しており、期限を逃したことについての責任を取ります。遅延コストの信用を与えています。あなたが要求している追加分析は、元のスコープの外ですが、変更命令として追加することに幸せです。」

クライアントフォーカスのままである間、行きます。あなたはあなたの間違いを修正できますが、契約の一部ではなかったもので署名することはできません。

スコープクリープが問題として表示される場合：

クライアントは、スコープの変更を品質の問題として枠付けすることがあります。「このレポートはXを含みません」とXが決して範囲内にあるとき。「I expected Y」を明示的に除外したとき。

スコープドキュメント戻ります。「元の提案をプルさせてください。スコープは同意しました、A、B、C含まれています。あなたが要求しているのはDですが、変更命令を通じてそれを追加することに幸せです。」

スコープドキュメントが曖昧な場合、あなたは小さなレバレッジを持っています。それは、これらのシナリオに対する最良の防御なので、明確なスコープの定義が前に重要な理由です。

主要な失敗後の関係の回復：

問題は時々、あなたがクライアントを失うリスクの本当に危険なほど厳しいです。プロジェクトは失敗しました。配信物は使用できませんでした。チームは何か重要を逃しました。

これらから回復することは、謙虚さと実質的な修復が必要です。シニアリーダーシップは個人的に関わる必要があります。クライアントが正しくすることを作成するために、大幅な財務譲歩またはコミットリソースを提供する必要があるかもしれません。

しかし、明確な回復計画なしにお金を投げます。「このプロジェクトを50％割引」はクライアントがまだあなたの配信能力を信頼しない場合、根本的な問題を修正しません。

能力を示すことに焦点を当ててください：「ここに私たちが持ってきた人です。新しい計画はここにあり、監督構造はここにあり、品質を確保する方法はここにあります。」

いつ歩き去るか知っています：

時々関係は保存するには損傷が多すぎるか、クライアントの期待は現実から非常に離れています。

クライアントがあなたのチームに虐待的である場合、満足する非合理的な要求を作成している場合、または関係が有毒になった場合、優雅に出口を出す必要があるかもしれません。

「前に進むことについて、私たちはあなたが必要なことについて正しいパートナーではないと信じています。現在のフェーズを完了し、別の企業に仕事を移行します。」

これは最後の手段ですが、時々必要です。あなたのチームを保護してください。クライアント関係は良い人を消費するのに価値がありません。

テクノロジーとツール

体系的な問題解決には、問題を追跡、管理、学習するためのシステムが必要です。

問題追跡とチケッティングシステム：

すべてのクライアント問題をログインするためのシステムを使用してください。小さくても。Jira、Asana、Monday、ServiceNow、または構造化スプレッドシートさえ機能します。

問題の詳細、重大度、割り当てられた所有者、ステータス、解決手順、および結果を追跡します。これは可視性と責任を作成します。

利益は個々の問題を追跡していません。パターン認識です。すべてをログインしているなら、同じ種類の問題が何度も表示されるか、特定のクライアントが他よりもより多くの問題を報告するのかに気付くでしょう。

CRM統合は関係コンテキスト用：

問題追跡は、全体的なクライアント関係の文脈で問題履歴を見ることができるようにCRMに接続する必要があります。

問題が来るとき、あなたはしたい知っています：これは初めての問題か、私たちはパターンを見ていますか？このクライアントは一般に満足しているか、複数の最近の問題がありますか？この関係の財務的価値は何ですか？

コンテキストは応答方法を形作ります。初めての問題が長期、高価値クライアントの場合、新しいクライアント患者の3番目の問題とは異なるに処理されます。

Tara Minh

Operation Enthusiast