AWS テクニカルサポートで得た暗黙知をまとめてみた | DevelopersIO

AWS テクニカルサポートを 5 年経験して アノテーションの荒川です。 クラスメソッドメンバーズをご契約いただいているお客様のテクニカルサポート業務を始めて、早 5 年が経過しました。 私が対応したチケット件数をざっくりと調べたところ、本日時点で 1685 件でした。 最近は私がチケット対応する機会は減りまして、チケット対応メンバーの教育（新入社員から各チームへ所属するまでの育成）やチケット相談に使う時間がメインです。 その中で、今まで何となくこうやって対応すると上手くいくと感じていた暗黙知をメモ書きしていたので、今回ブログとして公開します。 回答者側で意識したいこと 技術的なお問い合わせに関するガイドラインを参考にする AWS サポートのガイドラインは、一般的なカスタマーサポートでも使えます。 一文を短くし、適宜改行を挿入する 例: 一行にぎっしり × お客様環境をお調べしたところ、E

[otituke]

awsの裏仕様を教えてくれるのかと期待したらサポート回答のノウハウ集だった…

[j-u]

タイトルにだまされたけど全社会人が読むべき良記事だった。

[totoronoki]

社会人が持つべき「コミュ力」というものは本来こういう技術じゃないかと思う。

[dot]

AWS全然関係無かった

[ngsw]

この書き方、めちゃくちゃ同意する 読み手に間違った印象を与えない、間違った印象から間違った作業をさせないという強い意思を感じる

[kirarapoo]

AWSでなくクラメソのサポートの話だった

[yutaro1985]

テクニカルサポートの対応の仕方、非技術者の方と一緒に働く時の対応の参考にもなりますね。

[diveintounlimit]

タイトル詐欺まがいだけど良い

[tekitou-manga]

顧客対応マニュアル

[knosa]

“○ 確認にお時間をいただきありがとうございます。” これ今度やってみたい

[hara_boon]

タイトルが良くないな。内容自体は有用だと思う。

[rrringress]

大事や 質問する方もこれに沿って書いてほしい

[fk_2000]

テクニカルじゃなくてサポートの方のノウハウ集

[tetzl]

テクニカルなやり取りにおいて丁寧さはレトリックでなくロジックにあるのよね｜質問者側の書き方は割と内面化してるんだけど、問合せしても1往復で済んだりして割と楽よ

[ene0kcal]

既に身体に入ってるものだったが、良いまとめ。逆にこれを守れていない社会人に違和感を覚えてしまう過学習をなんとかしたいステージにいる。他人は他人だと割り切っていても…。

[saikorohausu]

リモートの仕事増えてるから文章の行き違いなくして共有度上げるの大事　メモしとく

[kura-2]

どこのサポート業務でも使える。すばらし

[Wafer]

■事実でも関係性の薄い文言を入れない　×AWSテクニカルサポートで得た暗黙知をまとめてみた　〇テクニカルサポートで得た暗黙知をまとめてみた

[kanopen]

暗黙知つうか、、

[worpe]

タイトルのawsは、抜いたほうが、、、。ただ良い記事。

[daishi_n]

まあ、ニフティ時代からフォーラムでサポートっぽい活動してると相手の行動が読めるようにはなった。

[hiby]

ドキュメント丸投げは結構な頻度でやられるんだけどハズレサポートに当たったと思って諦めてる。

[manFromTomorrow]

「AWSのサポート」はホント神よ…（ビジネスプランのやつ）

[coluli]

単にドキュメント化されてないノウハウを「暗黙知」と称するのは頭悪すぎる。

[katsusuke]

日本語のテクニック集だった。すごい

[motofu]

サポートに限らず、いろいろな場面で参考になるので、社内共有してみた。

[pastatch]

過去事例を聞いてる時は「1.他環境でも再現性がありそうかの確認」「2.その時の原因と解決方法の開示要求」で、「それがあればこっちで頑張ってみるわ」なので、2だけエスパーして渡してくれたら助かる

[mitsuok-33]

クラスメソッドさんいつもお世話になってます

[razihai]

最近ミドルだったりのメーカーに問い合わせすること多いから助かるな〜

[kazkun]

まあ、ヘルプデスクやってると身につくノウハウかな。でも文章にまとまってるのはありがたい。

[cj3029412]

AWSにほぼ関係ない話(羊頭狗肉に近い)