サポートの役割はトラブル解決ではない

「サポートの役割はトラブル解決ではない」というと、「そんなわけはないだろう」という声があちこちから聞こえてきそうだ。ユーザが困っているトラブルを解決する、疑問に答えるのがサポートの役割だと一般に考えられているからだ。

では、自動車のブレーキの役割はなんだろう。真っ先に出てくる答えは、「クルマを止めるためのもの」だ。たしかにそれも正しい。しかし、こうも考えられる。「クルマを速く安全に走らせるためのもの」。いざというときにきちんと停止できる、コーナーで思いのままにスピードをコントロールできる。その安心感があって初めて、クルマを速く走らせることができる。

サポートに話を戻すと、トラブルを解決するのがサポートの役割だという答えは、ブレーキは止まるためのものということに相当する。最終的にサポートが目指すべきは、ユーザがやりたいことを効果的に実現することだ。

たとえば、ユーザがある目的を持ってソフトウェアを購入したとする。ユーザは、Ａという機能を使えば自分の目的が達成できると考えて、ソフトを使いはじめる。が、不幸にして何かトラブルが発生してしまった。そしてサポートに電話をする。サポートは、聞かれたことに対して解決策を提供して機能Ａを使えるようにし、ひとまずユーザは満足する。もし、ユーザの目的を達成するのに別の機能Ｂの方が適しているとしたらどうだろうか。

あるいは、あるトラブルを調べるためにテスト環境を構築して再現テストをはじめたが、別のトラブルが発生してしまったとする。そのトラブルを解決しなければ、再現テストはできない。いつの間にか、本来調べるべきトラブルではなく、テスト環境だけで起きているトラブルの調査に没頭してしまう。こういうことはよくある。

ユーザは本来何をやりたいのか、本当に実現すべきことは何なのかを最初の段階でヒアリングできれば、無駄な労力を費やすことはなくなるし、ユーザの満足度もより高くなるはずだ。サポートのやりとりが長くなったときは、最終目的をときどき振り返って、進んでいる道が間違っていないかを確認することも必要だ。