MSP離反神話
MSPオーナーに最近去った顧客がなぜ去ったのかを尋ねてみてほしい。およそこの順番で聞くことになる:
- 「買収された。」
- 「価格ショッピング。」
- 「ITを内製化した。」
- 「わからない — ただ返信が止まった。」
「私たちの技術作業が悪かった」とはほとんど聞かない。
それはMSPの視点からすれば、技術作業は悪くなかったからだ。チケットはクローズ。SLAはほぼ満たされた。パッチは展開。バックアップは確認。オーナーが失ったアカウントのパフォーマンスデータを確認すると、通常は問題なく見える。
しかし去った顧客は?全く別の物語を持っている。
データが本当に言っていること
業界調査は — ConnectWise State of SMB IT、Kaseyaの年次レポート、MSPピアグループベンチマーク — 多くのMSPの自己認識と不快に一致しない数字に収束する:
MSP顧客離反の約60%は、技術品質起因ではなくコミュニケーション起因である。
それは同時にコミュニケーション、ではない。主にコミュニケーションだ。去っていく10人の顧客のうち6人は、何かが壊れたから去ったのではない。何も壊れていない間に、どう感じたかによって去った。
これらの離反イベントが顧客の言葉で実際にどう見えるかがこれだ。
5つのシナリオ
シナリオ1 — 金曜17:30のボイスメール
顧客CFOが金曜日17:28にボイスメールを残す。メールサーバーが遅く感じる — おそらく問題ないが確認したい。ボイスメールは「時間があるときに折り返して、緊急ではない」と言う。MSPチームは忙しく、17:45にログアウト。折り返しなし。月曜朝9時にメールが届く:「こんにちは — 金曜のVMについて。すべて大丈夫ですか?」
問題は何もなかった。メールは問題なかった。だが顧客は今知っている:彼らからの「緊急ではない」は、MSPからの「月曜まで何もない」を意味する。8ヶ月後、彼らは「ただ電話に出る」競合と契約する。
MSPのチケットシステムにはこの離反イベントの記録がない。 P1なし、違反なし、SLAなし。MSPが「価格ショッピング」に帰因させた顧客損失になったボイスメールだけだ。
シナリオ2 — 6時間の更新ギャップ
9:12 AMにヘルプデスクチケットが開く:プリンターが両面印刷できない。P3、ルーチン。技術者が11:30に取り上げ、調査を開始。技術者は11:50にP1障害に引き込まれる。プリンターチケットは置き去り。15:00に顧客がヘルプデスクにメッセージ:「誰かこれを見てますか?」 チケットは最終的に17:45に解決 — 技術的にはSLA以内。
しかし顧客の経験は、催促しなければならないことで句点を打たれた6時間の沈黙だった。チケットログは完全に許容可能な解決時間を示す。顧客の認識は、うるさく言うまで誰も気にしなかったというものだ。
シナリオ3 — エスカレーションのブラックホール
VP of Opsが23:40に電話 — ランサムウェアアラート、おそらく誤検知だが、今すぐ目を光らせる必要がある。オンコール技術者が20分で対応、誤検知を確認し、ベッドに戻る。チケットシステムは翌朝、技術者がそれを書き起こすときにエントリーを得る。
VPの経験:「潜在的なランサムウェアイベントについて真夜中に電話した。話した人は大丈夫だと言った。それについて他に何も聞かなかった。確認メールなし。レポートなし。何もなし。」
MSPは顧客の信頼侵食を一度も記録しなかった。そのシステムの視点では、それは成功した深夜の解決だった。
シナリオ4 — 届かないレポート
顧客が「月次ステータスレポート」を含む契約に署名する。MSPはこれらを生成するつもり。シニア技術者は常に忙しい。最初の3つのレポートは時間通り。4〜5ヶ月目は四半期にスリップ。6〜12ヶ月目、レポートは生成されない。
契約更新時に顧客のCFOがなぜ更新すべきか尋ねると、MSPはアップタイム統計とチケット量を引用する。それらの数字を積極的に見せられたことのないCFOは、価値と感情的に結びつけることができない。
月次レポートを受け取る顧客は、受け取らない顧客の約2倍の率で更新する。
シナリオ5 — 一貫性のないトリアージ
ある顧客のP2がSarahによって45分で解決される。もう一人の顧客の構造的に同一のP2は、Mikeがその日の技術者で、逆優先度で処理するため6時間かかる。両方のSLAは満たされている。
しかし両方の顧客は業界会議で話し、同じ契約で異なるサービスを受けていることを発見する。より遅い経験をした顧客はすぐには去らない — しかしMSPを誰にも推薦しなくなる。
推薦率は応答時間の速度ではなく、応答時間の一貫性の直接的な関数だ。
なぜMSPはこれに盲目なのか
ほとんどのMSPは運用健全性を評価する際に3つの数字を見る:
- 期間ごとの解決チケット数
- 平均SLAコンプライアンス
- 退出調査の顧客満足度スコア
3つすべては、コミュニケーション失敗を体系的に隠す遅行指標だ。
- チケット解決カウントは、失ったアカウントになった金曜のボイスメールを捕捉しない。
- 平均SLAコンプライアンスは97%でありながら、離反を引き起こす3%の経験を生み出せる。
- 退出調査はすでに去る決断をした顧客によって記入される。
修正はより良いチケットシステムではない
MSPが顧客を失って「SLA追跡を引き締める」と決めるたびに、問題ではなく症状を解決している。
問題は、コミュニケーションの一貫性が初回接触層での強制を必要とすることだ — 顧客とのやり取りが発生する瞬間、チケットになる前、記録される前に。
それには以下が必要だ:
- すべての顧客接触が時間帯に関係なく即座の確認を得る
- すべてのAI起草応答が顧客に到達する前に人間の承認キューを通過する
- 顧客が正式なチケットを開いたかどうかに関わらず、すべてのやり取りが記録される
- 各顧客はどの技術者がシフトにいたかに関わらず、一貫したサービス品質を受ける
5分間で自分の離反リスクを確認する
私たちは、MSPの運用上の漏れを明らかにする6問の診断を構築した — PSAレポートに表示されないコミュニケーション起因のリスクを含む。アカウント不要。
出力の一つは、組織がどれだけの顧客コミュニケーションを記録し、頭、Slack、メールに生きさせているかに基づく定性的な離反リスクスコアだ。スコアがHIGHで返ってくる場合、それが通常最大のドルギャップを埋める漏れだ。