管理職サラリーマン。

様々な職種を経験してきた中途半端な管理職サラリーマンが贈るブログ

サブスク時代に超大事なテクニカルサポートのおしごと

テクニカルサポートっていうと、なんだか花がないようなイメージを持っている人がいますよね、、

でも、サブスク時代には花形じゃないといけない職種です!

余談になりますが、花形っぽく見せるために、カスタマーサクセスなんてキラキラネームっぽい名前に変更するケースも最近は多いですよね。 ちゃんとカスタマーサクセスやっていれば問題ありませんが。

困った時に困り事を解決してくれる存在がしっかりしてないと、間違いなくユーザは継続利用してくれないですよね。

だから、サブスク時代にはテクニカルサポートが重要なんです。

あとは、ユーザの声を製品に活かすことも、サブスク製品では結構大事だったりします。

そのフィードバックを担うのもテクニカルサポートだったりします。

ということで、今回はテクニカルサポートの仕事についてです!

1. 大きな企業でよくあるのは階層性のサポート

1.1 Tier 1サポート(受付窓口)はスピードと数が勝負

Tier 1サポートは、コールセンターみたいなイメージを持ってもらえると分かりやすいです。

とにかくFAQを早く探して数をこなせることと、効率よくTier 2サポートにエスカレーションできる力が大事になってきます。

テクニカルな事というよりも、広く浅く色々とこなせる力が必要になってきます。

サポート対象の製品は、複数あるのがよくあるパターンです。

よくある目標設定は、対応満足度です。Tier 1サポートは、会社の顔になるため、丁寧で好感度の高い対応が求められますからね。

1.2 Tier 2サポート(プチテクサポ)はTier 3サポートの登竜門

基本的には、Tier 1サポートからエスカレーションされたチケットを対応します。

サポート対象の製品は、こちらも複数あるのがよくあるパターン。

FAQレベルではなく、製品仕様やTier 3が用意した簡単なトラブルシューティングなどを行います。

目標設定でよくあるのは、Tier 1サポートへのドキュメント作成で、Tier 1からTier 2サポートへのエスカレーション数を減らしていくます。

また、Tier 3サポートへのエスカレーション数を減らすことも目標設定ではよくあります。

1.3 Tier 3サポート(最後の砦)は開発者に次ぐテクニカルスキルが必要

Tier 3サポートは、製品開発者と密に連携を取ることが重要です。

最後の砦として、高いテクニカルスキルが必要となり、ここがぐらついていると開発者へのエスカレーションだらけになります。

こうなると悲惨で、開発者が製品開発するのが、チケット対応でストップしてしまいます。

不具合修正も開発者で気付く前に、ユーザ申告で知ることも増えるかもしれません。

常に、ユーザ申告対応に追われてしまいます。

よくある目標設定は、開発者へのエスカレーション 数を下げ、自己解決率を上げること。 そして、Tier 2サポートで完結できるようにTier 2へのドキュメント作成になってきます。

ちなみに、Tier 3サポートまでなると、担当する製品はせいぜい1〜2くらいの製品ですが、その製品については世界で開発者の次に詳しいレベルが求められます。

2. 小さい規模だとTier1〜Tier3サポートをまるっと1つのサポート組織で担う

2.1 Tier3サポートもやるからテクニカルスキルが必要

小さい規模の会社やサービスだと、こんな階層性にはできません。

そのため、サポートが1つの組織でやることになります。

こうなると、Tier 3サポートもやる必要があるため、電話受付をやったり、FAQに答えるだけではなく、高度なトラブルシューティング能力も必要になります。

2.2 テクニカルスキルだけではなく丁寧で好感度の高い対応力も必要

小さい規模の会社やサービスのサポートでは、高度なトラブルシューティングだけではなく、電話受付やユーザとの感情面や期待値をコントロールする細かいやり取りが発生します。

つまり、会社の顔となります。

そのため、テクニカルスキルだけあってもダメです。

2.3 落とし穴となるのはドキュメントを残さない

階層性のサポート体制を敷いていると、間違いなくドキュメントは細かく準備しないと回らないので、意識しなくてもドキュメントは定常的に作成します。

ただし、1階層のサポートだと全てを1つのチームで業務を行うため、人の入れ替わりがないと、俗人化してドキュメントを残さなくなってきます。

ヤバい!と気付くのは、サポートのエースが辞めるタイミングです。

落とし穴にハマらないようにちゃんとドキュメントは残すチーム文化にするのが大事です。

3. テクニカルサポートに必要な能力

3.1 テクニカルスキルが高い

テクニカルスキルがないと、製品理解もあやふやになる上に、キャッチアップも遅くなります。

また、確かなテクニカルスキルがあれび、製品の裏の動作を理解できます。そうなると、分かりやすいユーザ説明ができるようになります。

トラブルシューティングも早く正確になるのでテクニカルスキルは必須ですね。

3.2 ヒアリング能力

基本的にはテクニカルサポートには、困った人が問い合わせしてきます。

温度感は様々ですが、早くなんとかしてくれ!と言われるでしょう。

そんな時でも、ちゃんとヒアリングするのが重要です。

そのヒアリングが十分ではないと、解決するためのベクトルが大きく異なってしまいます。

ただし、ユーザによってはヒアリングできないほど温度感が高くなってしまったり、この情報で十分だろ!となって、全然情報共有してくれないことも多々ありますよね。

そんな時にも、仕事なのできちんとユーザに向き合いましょう!

3.3 問題洞察能力

問い合わせがユーザからあった時点で、ユーザは困っています。

ただし、ユーザも賢いユーザと賢くないユーザがいます。

ユーザは本来はこれを聞きたいけど、聞き方が分からない、時間がなくテキトーに問い合わせしてくる場合もあります。

もしかしたら、Aという問い合わせが入っているが、ユーザはAの解決を望んでいるのではなく、実はBという問題の解決を望んでいるかもしれません。

よくあるダメなパターンは、問い合わせ時の表面的なところしかみないテクニカルサポートです。

とにかく、ユーザにヒアリングしながら、問題をユーザと共有していく能力が必要となります。

3.4 高い言語能力

これは日本語や英語ができるという意味ではなく、高い読解能力と高い説明能力が必要ということです。

温度感の高いユーザであればあるほど、少しの情報しか与えてくれなかったりします。

そこを限りなく咀嚼しながら何が起こっているのか、何が問題なのかを読解していく能力が必要です。

また、説明能力も非常に重要です。

分かりにくい事象もユーザ目線でわかりやすく説明できるのは当たり前のことで、メールであれば、読みやすい構成にすることや読み手のことを考えて説明できる能力が必要となります。

時には、正確ではないですが、例え話などで説明すると、ユーザはすんなりと理解してくれることもあるはずです。

3.5 エスカレーション能力

当たり前ですので、説明は省略。

3.6 ドキュメント作成能力

ユーザ向けドキュメントだけではなく、サポート内のドキュメント作成を指します。

時には、報告書を作成する必要があります。

3.7 スピード対応(大正義!)

テクニカルサポートの品質で超大事なことは、解決までの時間です。

これは大正義です。

どんなに正確でも、トラブルシューティングできても、FAQ対応できても、スピードが遅ければ価値がありません。

テクニカルスキルが高い人によくありがちなので、問題の解決よりも、原因究明を優先してしまうケースです。

ユーザの期待値にもよりますが、問題の解決優先が定石です。

3.8 問題解決能力

テクニカルサポートは、テクニカルスキルを武器にしてユーザの困り事を解決しますが、時にはテクニカルな側面では解決しない問い合わせもあります。

使える武器は、とにかく使うことが重要です。

例えば、人見知りなテクニカルサポートがいて、そんなこと開発者にすぐにエスカレしろ!という案件も、自分で持ち続けちゃったりはダメですね。

あとは、ここは上司を使ったほうがいいとか、品質部門や営業部門にバトンタッチした方がいいなどの判断も問題解決能力としては必要になってきます。

とにかく使える武器(人)を使うというのが大事です。

3.9 打たれ強いメンタル

テクニカルサポートは基本はマイナスからスタートします。

顧客には急かされ、怒られながら、業務遂行することになります。

とにかく打たれ強いメンタリティが重要になります!

4. 残念なユーザたち(ダメ顧客)

4.1 高圧的で怒るユーザ

怒られても問題解決が早まる訳ではないのに、怒ればなんとかなると思っているユーザ。

しかも、かなり高圧的にくるユーザがいますよね。

問題解決したいのか、ただクレームを言いたいだけなのか謎ですが、ちゃんとユーザの言っていることは聞かないといけないので、テクニカルサポートの辛いところですね。

4.2 ほしい情報をくれないユーザ(非協力的)

温度感の高いユーザは、非協力的になる傾向が強いかなと思います。

でもそれは問題解決までは遠のくだけなので、ちゃんとトラブルシューティングに必要な情報がほしい!、けどくれない。。。

という押し問答で時間が経過するという負のスパイラルになります。

4.3 途中登板してくる偉い立場の人間ですアピールのユーザ

最初は担当者レベルが問い合わせしてきたのに、

途中から、私は上長/課長/部長/部門長の〜ですと名乗って途中登板してきて、大きな問題と捉えていますとか言って急いでくださいと迫ってくるユーザ。

温度感高いことや優先度高いことは初めから分かってて、もともと全力で対応してるから、指しゃぶって待ってろ!と言いたくなりますよね。

4.4 契約にないことを要求するユーザ

これは日本のIT業界全般がそうだと思いますが、なんでも言えばやってくれると思っているユーザがいます。

御用聞きじゃないから、お前でやれよ!とはっきり伝えたいけど、強めには対応できないのがテクニカルサポートの辛いところですよね。

4.5 ちょっとしたミスですぐに報告書出せというユーザ

これも日本の商習慣なのか、すぐに報告書出せとなりますよね。

しかも、メール本文に書くではNGで、メールの内容を社内報告用にユーザ側で仕立てて、社内報告すればいいのに、無駄に体裁にこだわる。

日本のこの悪しき商習慣は、企業同士で足の引っ張り合いしてるだけですからね。

しかも、年間1000万円の製品ならまだしも、年間10万円とかの製品でも、同じ対応レベルを求めるからおかしい。

4.6 ユーザ企業の担当者が変わると0リセット

ユーザから同じ問い合わせを何度も受けることがあります。

それくらいは、オンラインドキュメントみてくれよと思ったりもしますが、ギリギリ問題ない範疇です。

問題なのは、ユーザ側で担当者が変わった場合には、その担当者が引き継ぎも一切されておらず、0から製品に関する問い合わせをしてくるケースも多々あります。

こういう時はかなり問い合わせも増えて大変になります。

5. ユーザの声はとても大事

残念なユーザたちもいますが、サブスクモデルでは、継続利用してもらうことが非常に重要です。

残念なユーザも含めて、ユーザ申告は製品の品質向上には欠かせないものだ!という意識が必須となります。

特に、プロダクトアウトでは製品開発が止まってしまう時には、マーケットインとして利用ユーザの声を無料で聞けるチャンス(有料モニター不要)というポジ変がいいかもしれません。

事実、私が関わった製品は、こういったユーザ申告やクレームの中でも、多くのユーザでも不満を抱えているだろう共通問題を探し出して、機能アップデートやテクニカルサポートのオペレーション改善をしました。

売り切り製品のテクニカルサポートにはない、サブスク製品のテクニカルサポートの魅力はたくさんあります。