テクニカルサポートに的確に問い合わせる技術

テクニカルサポートを活用するために はじめまして、ひよこ大佐と申します。Red Hatという会社でAnsibleのテクニカルサポートエンジニアをしています。 我々テクニカルサポートエンジニアがどのようなことをしているのかは、以下の登壇資料にまとめていますので、一読いただければ幸いです。 何かサービスや製品を使用していると、問題に遭遇することがあります。設定方法が不明だったり、思ったような挙動にならなかったり、サービスが停止してしまうケースもあります。そのような場合に一生懸命がんばって自己解決しようとしても、運用担当者だけではうまくいかないことも多々あります。 そのような場合でも、テクニカルサポート窓口に相談し、サポートスコープの範囲内で支援を受けることができます。しかし、適切な問い合わせ方を知らないと問題解決まで時間がかかってしまったり、支援を断られたり、うまくコミュニケーションが取れずに

[decobisu]

“仕様の確認や「好奇心を満たすため」だけの質問をしない”

[netcraft3]

ユーザーサポートやってるとたまにめっちゃ敵意丸出しだったり傲慢な態度を取る人がいるけど友好的な態度を取って情報提供した方が問題解決に繋がることを知らない人が多いんだなと思う

[tech0403]

毎回イラッとするのは、専用の窓口なのか、総合窓口なのか分からない、具体的な現象を説明しても途中で「担当者に変わります」と言われ同じ説明をさせられる等。まずは自分たちが適切に誘導できてるか見直して欲しい

[rgfx]

（まぁ、「丸め込まれる」と思っちゃうんだろうなあ＞敵意

[yogasa]

メーカー側の言い分

[migimigi]

よくサポートに問合せします。記事の「適切な重大度」や「事実を明確に伝える」ことを心がけていますが、仕様で曖昧な部分を確認することが「好奇心を満たすため」と思われているのでしょうか？次善策の為に必要では

[marmot1123]

当たり前のことだった。しかしできてないケースが多いんだろうなあ。

[khtno73]

裏返しがサポート時のtodoになる。傾聴と共感で怒れる顧客を味方にし、緊急度重大度+デッドラインを最優先で確認、事実と定量的な指標を把握、ドキュメントを確認して回答、対応するのが良いエンジニア

[hiroomi]

“事実を明確に伝える”再現手順が書かれてれば問題なし。電話欲しい、電話でのお問い合わせは問題が整理されてないから、ガイダンスが必要？、よくあるお問い合わせでサンプルでも提示かね。

[mana-cat]

基本的な事だけど、これほんと大事“まず一度ドキュメントに目を通してみてください”

[cubick]

「急ぎです！」と言うなら、希望の期限を提示して欲しいなといつも思う。

[sugimo2]

“「どうしてこういう仕様なのか」や問題の本質と関係のない質問を連投するようになると、お客様が解決したい実際の問題から遠ざかってしまうケースがあります”

[daishi_n]

サポートに問い合わせる時は意識してやってるけど、精神的に追い込まれた時は問い合わせ文を書くだけで頭痛だらけだったな

[thekoruku]

テクニカルサポートに問い合わせるときって緊急の時多かったりもするから焦るのは分かるんだけど、問い合わせ先は人間だってことを忘れないで欲しい