30年近くにわたり、筆者は事業開発、テクノロジー、市場拡大の分野で、企業が業務を支えるソリューションを導入する支援に携わってきた。その中で、接続デバイス、信頼性の高いネットワーク、迅速なサポートが、事業継続に不可欠になっていることを目の当たりにしてきた。
そこから浮かび上がる教訓がある。テクノロジーがサービス提供に不可欠になると、それを支えることはもはや単なるIT部門の機能ではなく、業務上の責任になるということだ。
それにもかかわらず、多くの企業はいまだにマネージド・テクノロジーサポートをコストセンターとして扱い、クローズしたチケット数、平均対応時間、1件当たりの対応コストでパフォーマンスを測っている。これらの指標は重要だが、ダウンタイムが事業にもたらす影響を捉えるものではない。
テクノロジーに障害が発生したとき、標準的な対応は往々にして変わらない。ユーザーはポータルを開き、フォームに入力し、自動確認を待ち、キューに並ぶ。電話で支援を求めても、実際に対応できる担当者につながる前に、チャットボットや台本通りの質問をくぐり抜けなければならない場合がある。
問題は自動化そのものではない。緊急事態に定型プロセスを当てはめることが問題なのである。
障害を報告する顧客は、多くの場合、その原因を特定できない。接続の問題かもしれず、ハードウェアの不具合やバックエンドの問題かもしれない。それを診断するのはサポートチームの責任だ。最初に問うべきは、「何が影響を受け、誰に影響が及び、どれほど迅速にサービスを復旧しなければならないのか」である。
中小企業や非営利団体にとって、その影響はとりわけ大きくなり得る。接続障害は、配送車両の運行を妨げ、重要な地域サービスを中断させ、在宅医療事業者が患者データにアクセスできなくする可能性がある。大企業と異なり、こうした組織はリソースが限られ、代替手段も少ないことがある。
テクノロジーサポートに必要なのは、911マインドセットである。緊急対応に求められる切迫感、精度、人間の判断を、テクノロジーサポートに適用するという姿勢だ。
迅速に対応し、その後は影響度でトリアージする
全米緊急番号協会（NENA）は、911通報処理基準において、通報の90%を15秒以内、95%を20秒以内に応答するというベンチマークを定めている。
テクノロジーサポートが緊急通報の指令基準を文字通り再現する必要はない。しかしチームは、その根底にある原則を採用すべきだ。すなわち、対応は緊急度を反映しなければならない。
接続型テクノロジーに依存する企業と仕事をしてきた筆者の経験では、1人の従業員に影響する問題と、事業全体を停止させる障害は異なる。サポートチームは、事業への影響、影響を受けるユーザー数、ダウンタイムが続いた場合の結果に基づいてインシデントを分類すべきだ。重大インシデントでは、即時のエスカレーション、自動診断、適切な技術専門家への直接アクセスが発動されるべきである。
目的はトラブルシューティングをなくすことではない。適切なトラブルシューティングが適切なタイミングで行われるようにすることだ。
苦情を受け止めるだけでなく、顧客を安心させる
業務が止まったとき、顧客が必要としているのは通り一遍の謝罪以上のものだ。誰かが影響を理解し、責任を持って対応していると知る必要がある。
『Language & Communication』誌に掲載された「動揺した911通報者を落ち着かせる方法」に関する研究は、緊急通報指令員が的を絞ったコミュニケーションを用いて、動揺した通報者を具体的な行動へと導く方法を検証している。
テクノロジーサポートも同じ原則を適用できる。「ご不便をおかけして申し訳ございません」と言う代わりに、担当者は「貴社のチームが現在、配送処理を行えない状況であることを理解しております。本件を優先課題として対応いたします。接続状況を確認し、進捗を随時ご報告いたします」と伝えることができる。
後者の対応は、影響を認識し、当事者意識を示し、次のステップを明確にしている。
医療提供者とのウェルネスセッションを数分後に控えた高齢者が、デジタルプラットフォームから締め出されたケースを考えてみてほしい。専門用語を使わない、忍耐強い説明は、技術的な修正と同じくらい重要になり得る。
効果的なサポートは、技術的能力と共感を組み合わせる。顧客は、誰かが自分たちの問題を理解し、対応に責任を持ち、次に何が起きるのかを伝えてくれるという確信を必要としている。
最前線のサポートとエンジニアリングをリアルタイムでつなぐ
遅延の大きな要因は、サポート要求を受け取る担当者と、根本的な問題を解決できる専門家との間にあるギャップだ。テクノロジー企業には、システムを監視し、インシデントを管理し、エンジニアにアラートを送るためのツールがある。機会は、チームをサイロ化したままにするのではなく、これらの機能をつなげることにある。
たとえば在宅医療事業者が接続障害を報告した場合、サポート担当者は関連する診断情報にアクセスし、他のユーザーにも影響が出ているかを判断し、適切なエンジニアリングチームへ直ちに通知できるべきだ。SlackやPagerDutyのようなツールを使えば、最前線の担当者が顧客の窓口であり続けながら、インシデントアラートをルーティングできる。顧客が複数のチームに同じ情報を繰り返し伝えたり、誰かが問題に対応しているのか不安に思ったりする必要はない。
これは、成功がデバイスの提供だけにとどまらないマネージド・テクノロジーサービスにおいて、とりわけ重要である。信頼性の高いサービスには、接続性、設定、セキュリティ、監視、保守、サポートのすべてが関与している。
だからこそ筆者は、テクノロジーは販売時点だけでなく、ライフサイクル全体を通じて管理されるべきだと考えている。適切な情報を適切な専門性と結びつけることで、チームは症状に繰り返し対処するのではなく、根本原因を解決できるようになる。
すべての重大インシデントから学ぶ
サービスの復旧は不可欠だが、そこでプロセスを終わらせるべきではない。重大な障害の後、チームは問うべきだ。検知にどれだけ時間がかかったのか。解決を遅らせた要因は何か。監視によって問題をより早く特定できたのか。再発を防ぐために、何を自動化または再設計できるのか。
顧客が同様の接続障害を報告している場合、インシデントをまとめて見直すことで根本原因を明らかにし、再発を防ぐことができる。筆者の経験では、長期的な顧客関係は、問題を解決するだけでなく、そこから学ぶことにかかっている。
ITサポートを超えて広がるマインドセット
911マインドセットは、ITサポートを超え、遅延が深刻な結果をもたらし得る銀行、公益事業、病院、大学にも広げることができる。業界を問わず、原則は同じだ。影響を素早く評価し、明確に伝え、適切な専門家へエスカレーションし、インシデントから学ぶ。小規模な組織にとって、マネージドサービスは、プロアクティブな監視と明確な説明責任を通じて、この水準のサポートを提供できる。
テクノロジーがサービスそのものであるとき、サポートは約束の一部になる
顧客は、テクノロジーが安定して機能しているときにはほとんど気づかない。記憶に残るのは、それが故障したとき、そして対応が切迫感、能力、共感を示していたかどうかである。
911マインドセットとは、すべてのチケットを生命に関わる緊急事態として扱うという意味ではない。同じ技術的障害であっても、誰が影響を受け、何が懸かっているかによって、結果は大きく異なることを認識するという意味である。
ダウンタイムの1分1分が重要なとき、テクニカルサポートの成功はチケットをクローズすることだけではない。混乱を最小限に抑え、業務を守り、長期的な顧客の信頼を築くことにある。
