IT 製品・サービスを利用する中、サポートへお問い合わせをするものの、サポートエンジニア (以降、エンジニア) からの回答を得るまでに時間がかかることを経験したことはありませんか。
実は、お問い合わせの際に少し工夫するだけで、少しでも早くエンジニアから回答を得る可能性があります。
結論から言いますと、ケースオープンからクローズまでの流れにおいて、時間短縮に繋がる要素を積極的に工夫して、エンジニアより早く回答を得ることとなります。
早速内容の紹介に移りたいですが、その前に本記事の内容は個人の経験をベースとした内容であり、必ず早く回答がえられることをコミットするものではないことをご理解ください。
また、本記事では “外資系 IT 会社のエンジニア (障害窓口) からの回答を、今より少しでも早く得ること” をイメージした内容となっております。
ケースオープンからクローズまでの流れ
サポートへお問い合わせをすると、基本ケースまたはチケット (以降、ケース) 上で、下記の流れでやり取りが発生します。
ここで、ユーザー側で工夫可能なのが、基本 ① と ② となります。
① 工夫可能な要素あり (ケースオープンからの工夫)
＃ いかにエンジニアとのやり取り回数を減らし、エンジニアの調査開始を早めるかがポイントとなります。
1-1. 1 ケース 1 イシュー
一つの事象に対して、一つのケースで対応することで、調査対象および内容がクリアとなり、エンジニアのより早い調査開始が期待できます。
もし、一つのケースにて複数のご質問があった場合、エンジニアからケース分割調整が入り、調査開始が遅れることになると思います。
1-2. 事象の詳細追記
下記の通り、事象の詳細を追記すると、エンジニアが事象の概要を素早く把握でき、早い調査開始が期待できます。
もし、事象に対する情報が不足した場合は、確認のやり取りが追加で発生し、調査開始が遅れることになると思います。
また、予めサポート側で用意しているお問い合わせのテンプレートなどがある場合は、テンプレートを活用した方が効果的だと思います。
・事象の概要
・エラーメッセージ
・発生日時
・お気付きの背景
・業務影響
・環境情報 (製品バージョンなど)
・切り分け内容
(事象発生後、ご自身で確認した内容を共有するとより早く問題箇所の把握に繋がる効果があると思います。// 例.クライアント環境・ユーザーアカウントごとなどの動作確認)
・担当者名、連絡先
(基本ケースベースのやり取りになると思いますが、追記しておくと、緊急度および状況によってエンジニアから電話で連絡する場合があるようです)
1-3. サポートバンドルおよびスクリーンショットの添付
事象が発生している該当製品のサポートバンドル (例.本ブログでよく紹介する vSphere 製品としては、vCenter・ESXi など) および事象の発生状況 (エラーメッセージなどが表示されている画面など) がわかる画面全体のスクリーンショットを取得し、ケースオープンの際に併せてアップロードをすると、エンジニアのより早い調査開始が期待できます。
また、サポートバンドルの場合は、製品によってログが流れてしまうケースもありますので、事象発生直後素早くサポートバンドルを取得しておくことが効果的だと思います。
1-4. 適切な重要度 (Severity) を設定
ご利用製品のサポートに定義されている重要度 (Severity) について事前に把握しておき、ケースオープンの際に適切な重要度を設定することで、エンジニアのより早い調査開始が期待できます。
例として、実際の事象が重要度 4 なのに、重要度 1 でケースをオープンすると、エンジニアからの電話連絡での状況確認や重要度の再調整のやり取りが発生し、調査開始が遅れることになると思います。
また、状況によっては海外のエンジニアと英語でのやり取りが発生する可能性もあると思います。
1-5. 初回からの回答期限設定は非効果的
ケースオープン時に回答の期限を決めたい気持ちはわかりますが、回答までしばらく待つことが効果的だと思います。
エンジニアは基本重要度に合わせて早く回答を提供したいはずですし、回答期限が設定されると、状況によって進捗連絡のやり取りが発生し、調査が遅れる可能性があります。
お急ぎ回答が必要な場合は、適切な重要度設定およびエンジニアへ状況を伝えるのがより効果的だと思います。
② 工夫可能な要素あり (回答確認からの工夫)
＃ 意外と回答を得た後のアクションも、次回のお問い合わせ時などを考慮して重要なポイントとなります。
2-1. 回答の確認
エンジニアからの回答で、事象の改善可否を確認し、改善した場合はクローズの旨を伝えた方が、次回のお問い合わせなどを考慮すると効果的です。
2-2. サーベイへの応答
ケースクローズ後は、第三者調査機関によるサーベイのリクエストメールが届く場合があります。
これは、”サポートに対するサーベイ” であり、減点式となるようなので、サポートに問題がなければ、基本満点 (例.1〜10 で 10 が満点の場合は、10) を付けると効果的だと思います。
日本の文化？的なところで、真ん中の点数をつける傾向があるようですし、原因特定に至らなかったなどで低い点数をつけることもあるようですが、サーベイはあくまでサポートに対するものとご理解の上、エンジニアのモチベーションにも繋がると思いますので、ちゃんと応答した方が、次回のお問い合わせなどを考慮すると効果的です。
勿論、サポートが NG な場合は、その旨フィードバックした方が改善に繋がると思いますので、その際はコメントを残した方が良いと思います。
以上、エンジニアからの回答を、今より少しでも早く得る方法の紹介でした。
繰り返しとなりますが、エンジニアは事象の改善のために調査を行い、より早く回答を提供したいはずです。
また、製品・サービスを利用する中、お問い合わせをすると同じエンジニアに対応してもらうことも結構あると思います。
繰り返し同じ対応となった場合、エンジニアはお客様のこと・環境を覚えている可能性もありますので、意外と上記 ② の対応が重要なポイントとなります。
勿論、エンジニアは基本複数のケースを対応しているはずなので、同じ重要度でも調査に必要な情報が揃ったケースの方が、対応開始しやすいと思いますので、① もご参考の上、今後のケースオープンの際に活用いただければと思います。
本記事が、少しでも早い事象改善に繋がれば嬉しいです。
コメントを残す