「件名に『緊急』と記載されても緊急度は上がりません」 AWSへの問い合わせガイドラインが話題に 「新人研修に使える」「苦労が垣間見える」
コメント
注目のコメント
数年前、Amazon Fire TV 提供のゲームにはまって頑張ってた。久しぶりに課金アイテムにも手を出したが、とにかく時間をかけて愛車を育てていった。
で、ある日そのデータが全部消えちゃった (ﾟдﾟ)！
数十台の愛車も数千円分のコインも。
ゲーム会社に言ってもらちあかず、でもゲームデータはAmazonのシステムに残っているはず、そう書いてあるよねAmazonに連絡したがこれがまぁ、会話1回に数ヶ月かかる始末。一年かかっての返事が「AmazonのID PW教えて」。そんなのメールで教えられるか！
でも、冷静にそこで諦めた。そしてAmazonでゲームをやること自体を止めた。
あ、AWS の話か。働き方改革って組織内部の課題ばかりが注目されがちですが、内部と同等むしろそれ以上に組織外部との付き合い方がキーとなるのではないでしょうか。
あまりにパワーバランスが顧客優位に傾きすぎではと心配になる組織をよく見かけます。
できることとできないことをはっきりさせる。
断るところは断る。
それで顧客が離れていくのであれば仕方ない。
それくらいのマインドセットで顧客と対等な関係を築いていくべきと思いますし、顧客に何から何までひれ伏さないと継続できないような組織はブラックへの入口でもあり、そもそも必要なのかとさえ考えることもあります。
個人間だけでなく、組織間のアサーティブが今後はより必要になってくると感じています。
その点、素晴らしい取組ですね。技術的な問い合わせをするときに個人的に気を付けていること。
①エラーコードやエラーメッセージは一言一句正確に伝えるためにコピペする。(サポートセンターの人が、その文字列を社内システムで検索したりするため) 「よくわからないメッセージが出て」では、サポートセンターの人も良く分からないので。
②できればエラー画面のスクショを添付する。百聞は一見に如かず。たまにアクティブウィンドウの裏にある何かから原因特定することも。
③どういう操作をして、どのボタンを押したらそれが表示されたのかを明記する。
④再現性があるか、問題の切り分けができないかを試してから問い合わせをし、再現性があるかないか、切り分けられた事象を明確にする。たとえばChromeでもFireFoxでもうまくいかないのか、Chromeだけダメなのか。自分のパソコンではダメでも、同僚のパソコンならエラーにならないとか。
⑤「いつもどおりやったんですけど」とは思わずに、何か見落としたいつもと違うことがないか考える。結構、原因はそこにあったりする。
⑥OSのバージョンやシステムのバージョン、使っているブラウザのバージョンなどは最初のやり取りで明記しておく。大体、聞かれるので。
⑦いつまでに解決しないとクリティカルなのかという期限があれば、書く。急ぎ、とかではなく。
