Google Cloud のサポートケースを起票する時に心がけたいこと

こんにちは、京セラコミュニケーションシステム 石関 (@kccs_daisuke-ishizeki）です。

みなさんは何らかのサービスを利用している時、サポート窓口に問い合わせをした経験はありますか？
その際、サポート担当者とのキャッチボールが多くなり、結果的に時間がかかったことはないでしょうか。

この記事ではわたしが Google Cloud サポートにサポートケースを起票する時に、心がけていることをまとめてみました。

## ビジネスインパクトに合わせて優先度を選択する

サポートに問い合わせをする際、起票者としては早く解決したいと言う気持ちが先行して、結果としてサポートで提供されている最大の優先度を選択したくなります。

ですが Google Cloud 等のパブリッククラウドのサポートは、ビジネスへのインパクトの有無や影響の度合いで優先度を選択するようガイドラインが設けられています。
すべての問い合わせに即時対応するなど非現実的ですし、サポート料金に影響してしまいますので理解できるところかなと思います。

Google Cloud サポートでは P1 〜 P4 の優先度が定められており、優先度によって初回応答目標時間（SLO）や[サポート時間](https://cloud.google.com/support/docs/language-working-hours?hl=ja#availability)が異なります。
優先度の定義は以下のとおりです。[（サポートケースの優先度 から引用）](https://cloud.google.com/support/docs/customer-care-procedures?hl=ja#support_case_priority)

| 優先度 |                     優先度の定義                      |                                                                                                                 事例                                                                                                                 |
| :----- | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| P1     | 重大な影響 – 本番環境でサービスを使用できない         | 本番環境でアプリケーションまたはインフラストラクチャが使用できず、ユーザー側でエラーが大量に発生している。<br>ビジネスに与える影響が重大である（収益損失、データの整合性に影響する可能性のある問題など）。                           |
| P2     | 影響が大きい – サービスの使用が大幅に損なわれている   | 本番環境でインフラストラクチャの機能が低下していて、ユーザー側でエラーが非常に高い割合で発生している、あるいは新しい本番環境システムの稼働が難しい。<br>ビジネスに与える影響が中程度である（収益損失や運用性低下などの恐れがある）。 |
| P3     | 中程度の影響 – サービスの使用が部分的に損なわれている | 問題の範囲または重大度は限定的である。この問題によりユーザーの目に見えるような影響は発生していない。<br>ビジネスに与える影響が低い（不便を感じる、ビジネス処理に小さい影響を与える、など）。                                         |
| P4     | 影響が小さい – サービスはすべて使用できる             | ビジネスへの影響や技術的影響は低いか、まったくない。<br>頻繁なやり取りよりも、詳細な分析やトラブルシューティングが必要な場合や、コンサルティングを希望される場合は、コンサルティング チケットをおすすめします。                      |

:::note info 
特に以下を意識しています。
- 優先度の定義に沿って選択する。変な遠慮はしない。
- P1 〜 P3 選択時はビジネスインパクトを記載する。
- 必要に応じて優先度を変更する（適宜優先度の変更が可能です）。
:::

## 適切な情報提供を心がける

適切な情報ってなんでしょうね。

わたしも業務でお問い合わせに対し回答する機会があります。
回答する立場としては、期待に沿う内容をキャッチボールの回数を最小にしてお答えしたいと考えていますが、求めているものや状況にマッチした回答となっているのか不安な時もあります。

そのような時は提供されている情報が不足していることがほとんどです。
不明な点をヒアリングすれば解消できますが、その分時間がかかります。

そんなわけで、質問する立場でも欲しい答えを最短で得るために、はじめから情報提供するよう心がけています。
ポイントとしては以下の 3 点を盛り込むようにしています。（[AWS 技術的なお問い合わせに関するガイドライン](https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/) から引用）

:::note info
- [解決したい課題を明確にする](https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/#issue)
- [状況を正確に共有する](https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/#situation)
- [経緯を共有する](https://aws.amazon.com/jp/premiumsupport/tech-support-guidelines/#progress)
:::

Google Cloud のドキュメントじゃないの？という声が聞こえてきそうですが、気をつけたいポイントが汎用的にわかりやすくまとまっているのでご紹介いたしました。

ちなみに Google Cloud サポートのベストプラクティスは以下ドキュメントにまとめられています。

https://cloud.google.com/support/docs/best-practices

## フィードバックする

:::note info
良くも悪くもフィードバックする！
特に低い評価を付ける場合には具体的にどのような部分が不満だったのか、期待値とどう違っていたのかなどをコメント欄に記載します。
:::

サポートケースがクローズされると、フィードバックリクエストのメールが届きます。
5 段階評価でサポート体験への評価を行います。

日本人的な感覚では、良くも悪くもない印象だと 3 を選ぶことが多いと思いますが、特に不満がなければ **4** を選択します。
なぜなら 3 以下の評価の場合、以下記載のように改善につなげる仕組みになっているためです。

期待値と違ったり、労力が大きいなと思った場合はフィードバックしましょう！

> すべてのフィードバック フォームがカスタマー エクスペリエンス チームによって手動で審査され、今後のアクション向上のために使用されます。
> スコアは 5 点満点となります。スコアが 3 以下であれば、お客様側の労力が大きいと見なし、レスポンスに関するフォローアップを実施します。
> 一方、スコア 4 以上の場合、操作は簡単（容易）で、ポジティブなエクスペリエンスと見なされます。

（[https://cloud.google.com/support/docs/best-practices#ces](https://cloud.google.com/support/docs/best-practices#ces) から引用）

## まとめ

急いでいたり焦っていたりする状況で文章を書くと、必要な情報を省略してしまいがちです。
そのような時にこそ、適切な情報をはじめから提供し早期に解決を図っていきたいものですね！