Upgrade to Pro — share decks privately, control downloads, hide ads and more …

テクニカルサポートのお仕事

sugitk
May 15, 2023

 テクニカルサポートのお仕事

sugitk

May 15, 2023
Tweet

More Decks by sugitk

Other Decks in Technology

Transcript

  1. 実績 ・統計を取った時期が異なるのでわかりにくいですが、4年半少々でこの実績を積み上げてきました。 - 1件以上コメントした問い合わせの数(オーナーを取ったものを含む)  2,937件 (2018-08 〜 2023-04) - サポートケースへのコメント 

    4,836件 (2021-01 〜 2023-04) - ナレッジベースのドキュメントを執筆  168件 (2018-08 〜 2023-04) - 非公式ブログへの執筆 39件 (2018-08 〜 2023-04) - お客さまからのフィードバックの平均値  4.62 (5.0満点、2022-01 〜 2023-04)
  2. お客さまはなぜ問い合わせをするのか? ・OSS 版を使うのではなくサブスクリプションを契約して製品版を導入しても、思うように使えないという ときに問い合わせをしてきます。その内容はさまざまです。  - 製品知識がない  - 設定が悪い  - 使い方が正しくない

     - 期待する動作をしない  - まだ実装されていない  - など ・製品を動かすことが目的ではなく、製品を使ってビジネスを進めるために買っていただいています。 担当製品は自動化の製品で、手でやるよりもこの製品を使ったほうが圧倒的に費用を削減できること が期待されています。 ・テクニカルサポートへの問い合わせをすることで問題が解決すれば、悩む時間を減らして本来やりた いことに注力することができます。
  3. 問い合わせを受け取ったとき ・カスタマーポータルからWebのフォームで問い合わせが起票されますと、申告された製品の情報に 基づいて専任のチームのキューに入ります。 ・キューの振り分けが正しくない場合には、適切なチームに転送します。契約があるお客さまかどうか も確認します。契約がないときは、原則として定型文でお断りします。 ・担当するリージョンからの問い合わせであれば、オーナーを取ります。  APAC (およそ GMT+8〜 11)

    の時間帯を担当していました。日本からの問い合わせは次第に増えて、退職する前には半分くら いはあったように思います。 ・対応言語は原則として英語ですが、日本からの問い合わせは例外として日本語で対応していまし た。 ・重大度(緊急度ではない)や契約によって、初期応答と継続応答の時間が SLAとして決められていま す。SLA を守れないと、悪いフィードバックを受けてしまうことがあります。 ・土日当番もありました。平日よりも人数が少なく、重大度の高い問い合わせのみを対応していまし た。日曜が平日の国もあり、そのようなお客さまには平日と同様に対応しました。
  4. 初期対応 ・問い合わせの内容をできるだけ正確に捉えます。お客さまは必ずしも製品知識を十分に持っていないこと があります。困っていることを困っていない状況に持っていくことを目的とします。 ・問い合わせの内容がサポート範囲なのかどうかを判断します。範囲外のものとしては例えばこのようなもの があります。  - 契約について → 営業  -

    コードの開発やテスト、作業代行 → プロフェッショナルサービス ・申告された重大度がSLAの定義に合わない場合、下げることを調整することがあります。問い合わせは全 て急ぎなのは理解しますが、人力のリソースに制限があるからです。プロジェクトのスケジュールの都合で急 いでいると言われることもよくありましたが、製品サポートとしては配慮することができません。本来急ぎで対 応すべきお客さまへのリソースを圧迫するからです。 ・問題の事象を理解するために、さまざまな情報収集をお願いしつつ、手元で再現環境を整えます。 OSや製 品のバージョン、インストールされている構成を把握するところから始めます。
  5. 問題解決に向けた対応 ・情報収集して、事象を把握します。何を解決すべきなのかを、およそ3往復以内のやりとりで確定さ せます。 ・問題を再現することができたら、状況によってアクションをします。  - 既知の問題で修正がある → アップグレードをお願いする  - 既知の問題だが修正されていない

    → 回避策があれば提示して、なければ修正が早く進む ように情報を開発チームに提供したりする  - 新しい問題 → 開発チームに問題として起票し、回避策も合わせて検討する ・再現できるかどうかが鍵で、再現できない問題は解決まで長期化する傾向にありました。 ・難問はバックラインのエンジニアや開発チームと協力して進めます。コードを深く追わなければわから ないもの、大規模でパフォーマンスの問題があるもの、想定しない構成で使われていたもの、他社の 製品との組み合わせで問題を生じていたもの、などがありました。
  6. 問い合わせを閉じる ・問題が解決できたり回避策を受け入れてもらえたりなど、その問い合わせについて理解が得られたら閉じ ることになります。問い合わせのやりとりを進める中でさらに問題が増えてしまった場合には、別な問い合わ せを起票してもらいます。 ・閉じるときには事務的に閉じて良いのですが、お互いに人間が仕事としてやっているということをきちんと意 識して、気持ちよく終われるように心がけていました。お客さまは困っているから問い合わせして来ているわ けで、本来は困らなくても使えるようになっているほうが好ましいからです。 ・ドキュメントを読んでもわからなかったから問い合わせをしてきているので、問題が解決できたらまとめのド キュメントを作成してナレッジベースとして参照できるようにすることもよくやっていました。製品ドキュメントへ の反映を進めることもありましたが、動きは遅くなるからです。

    ・好意的なフィードバックをもらうためには、その問い合わせを通して何か価値提供できたかどうか、それが伝 わったかを意識していました。また問い合わせをすると助けてもらえる、サブスクリプションを買ってよかった と感じてもらえるようなファンになってくれるのが理想形でした。
  7. 工夫したこと ・問い合わせの事象を高速に再現することをいつも心がけていました。自動化の製品を扱っているために自分でも 検証環境の構築を自動化し、構成を把握したら同等の構成をすぐに作れるようにしていました。自分自身もユーザと して同じような問題に当たってしまうこともあり、自分をサポートするような動きをするのが役に立つこともよくありまし た。 ・既存の事象であってもできるだけ再現することにして、新しい発見があるかどうか、いまだからその問題に当たるの かということを確認するようにしていました。 OS や製品のアップグレードのタイミングでたまたまその組み合わせで 生じる問題があるからです。

    ・できるだけ早く、かつ具体的に返答するようにしていました。 SLAで8営業時間などと定義されていても、問い合わ せを並列にやっていたり、他のメンバーとの相談に応じたりしているとあっという間に時間はなくなります。早く返答し て手持ちの量を減らすことで、心理的な負荷も軽くなっていました。 ・ただ既存のドキュメントや事例を紹介するというのではなく、実際に再現した結果をもとにして具体的なお客さまの 環境ではどのような操作をしてほしいのかというところまで落とし込んだ回答をするようにしていました。 ・以前法律の勉強をしていたことがあり、論文試験では法的三段論法として規範定立を必ずするわけですが、その 考え方がテクニカルサポートの仕事でもとても役に立ちました。事実関係の把握、論点の抽出、条文のあてはめ、結 論の導出です。