卓越したカスタマーサービスの提供
顧客のニーズを理解する
顧客が質問をしてきた場合は、その質問の理由と最終的に求めている結果を完全に理解するようにしましょう。求めている最終結果を達成するには別のより良い方法があるかもしれませんので、いつでも気軽に「なぜ」と尋ねてください。
ビジネスインパクトを理解する
このチケットの解決を待っている間、ユーザーのビジネスは影響を受けていますか？
これがわからない場合は、チケットがエスカレーションになるのを防ぐため、チケットのライフサイクルの早い段階でユーザーに確認してください。ユーザーが取り組んでいる時間軸を理解することで、期待値を設定し、プロジェクトのスケジュールを満たす、または調整する手助けができます。
期待値の管理
ユーザーに更新を送信するとき、通常はチケットステータスを Pending に設定します。これは、ユーザーからの返信を待っている状態を示します。
進捗を継続的に確認するため、適切な時間が経過したら再度連絡することを顧客に期待値として伝えることも検討してください。
また、チケットステータスを On-Hold に設定して、何らかのアクションを実行中で、後ほどユーザーにフォローアップすることを示すこともできます。
チケットを On-Hold にする場合は次のようにしましょう:
- いつフォローアップメッセージを送るかをユーザーに伝える。
- 選択したスケジュールがニーズに合わない場合は知らせるよう促し、必要に応じて計画を調整できるようにする。ビジネスインパクトを理解するも参照してください。
- 毎日、少なくとも 4 日に 1 回（
On-Hold期間の長さ）は更新を提供することを目標にする。
チケットを Pending または On-Hold に設定する際は、コミットメントを果たすために Due Date
や Reminders
アプリの利用を検討してください。
「機能 / 修正 X はいつ期待できますか？」に対して具体的な回答を避ける
チケット作業の過程で、機能リクエストやバグへのリンクを貼ることがあるかもしれません。マイルストーンが割り当てられた Issue は示されたリリースで 配信される可能性 がありますが、必ず配信されると約束しないでください。詳細は ドキュメントスタイルガイド を参照してください。
感情的になっているチケット
顧客が否定的な感情をチケットのコミュニケーションに込めている場合は、ハンドブックの 感情が絡んだチケットを解決に向けて進める方法 を参照して、役立つヒントとガイダンスを得てください。
SLA 違反が近いが、完全な返信にはもっと時間が必要
- アクションプランをユーザーに伝える短いメッセージを送り、明確な期待値を設定してください。これを行うことで SLA 違反を防げるだけでなく、ユーザーに好意的に受け取られる可能性が非常に高いです。完全な回答を持っていなくても、メッセージは役に立つということを覚えておいてください。
- 短い公開返信を送る際は、チケットステータスを
On-holdまたはOpenに設定します。On-holdは別のチームからの情報を待っているときに有用です。Openは他のサポートチームメンバーにチケットを見えるようにしたいときに有用です。 - 上記のアクションを取った後は、コミットメントを守り、次のステップを含む完全な返信で時間通りにユーザーに返信してください。SLA タイマーを止めた以上、時間通りに返信するのはあなたの責任です。自分でフォローアップしないつもりなら、このアクションを取らないでください。
チケットのマージ
警告: マージされるチケットの添付ファイルはチケット間で共有されます。両方のチケットの CC に含まれる全員がファイルを受け取ります。
関連する、または重複するユーザーのチケットを 2 つマージする場合は、何をしたか、なぜそうしたかを伝えるメッセージを必ず送ってください。これを行わないと、混乱を招き、なぜコメントなしでクローズされたのかというフォローアップが頻繁に発生します。なお、Zendesk の署名はこのメッセージに自動的には適用されません。
チケットの分割
ときどき、顧客が複数の独立した問題を 1 つのチケットで扱っていることや、ユーザーが既存のチケットで別の問題について質問することが明らかになります。
チケットはタイトルで明確に説明された 1 つの問題に集中させることをおすすめします。ユーザーの代わりに新しいチケットを作成すること によって、チケットを「分割」することが推奨されます。
新しいチケットは 1 つの Issue に集中させ、元のチケットは元の Issue のままにします。これにより解決までの時間を短縮し、目の前の問題の修正に集中しやすくなります。
新しいチケットを作成する方法の詳細は、顧客のためにサポートをリクエストする のオプション 3 を参照してください。
チケットからの情報の削除
ユーザーが直面している問題の解決に不可欠なログやその他のファイルを送信してもらうようお願いしています。ユーザーがサポートチケットで共有された情報の削除を要求した場合や、機密情報が誤って共有された疑いがある場合、Zendesk の機能を使って情報を削除できます。編集（Redaction）は元に戻せません。
チケットからテキストや添付ファイルを削除するには:
- Zendesk の ドキュメント の手順に従ってください。
- ユーザーに、どんなアクションを取り、なぜそうしたかを伝えてください。共有された可能性のあるシークレットがあればローテーションするようユーザーに依頼してください。
編集オプションが見えない場合は、おそらく承認されたロールのいずれにも割り当てられていません（Zendesk のプロフィールでロールを確認できます）。この場合、Slack の #support_operations または #support_leadership に削除をリクエストしてください。編集にアクセスできる Zendesk ロール:
- Admin
- GitLab Staff
- GitLab Staff - Explore
- Security Staff
- Support Managers
- Support Staff
- Support Staff - CMOC
- Support Staff - Explore
GitLab チームメンバーが作成したチケットの取り扱い
ときどき、GitLab のチームメンバーが顧客、潜在顧客、ユーザーなどからのサポートリクエストを転送することがあります。それらのリクエストは、元のリクエスターからではなくチームメンバーからのチケットとして表示されます。
転送した人を CC に残したまま、常に元のリクエスターに直接返信してください。チケットタイトル内の見かけ上のリクエスターのメールアドレスの横にある「(change)」リンクをクリックして、チケットの「Requester」フィールドを手動で変更する必要があります。
詳細については 顧客のためにサポートをリクエストする を参照してください。
コミュニケーション
作業内容を文書化し、すべてのコンテキストを提供する
チケットに調査ノートを追加してください。チケットのライフサイクルを通して実施したすべての作業を明確に文書化することは重要です。これは長く困難なチケットで自分自身の進捗を追跡する良い方法であるだけでなく、これまでに何が試されたかを同僚が明確に理解でき、チケットを再割り当てする必要があるときにスムーズな引き継ぎを可能にします。
Slack でのディスカッション内容を内部ノートにコピーする
Slack を使ってサポートチケットに関する作業や社内コミュニケーションを行う際は、私たちのチャット保持ポリシー と コミュニケーションガイドライン（特に 9.） を念頭に置いてください。 Zendesk での将来的な検索に備えて、関連するアドバイス、メモ、アイデアなどを Slack から Zendesk の内部ノートにコピーするのが最良です。
クロージャーサマリー
チケットの担当者であり、提供したソリューションが Issue を解決したことを顧客が確認した場合は、チケットのステータスを solved に変更する前に クロージャーサマリー をチケットに追加してください。
クロージャーサマリーは、確認されたソリューションの簡潔な概要を提供すべきです。顧客にソリューションについて明確さを与えること、および同僚が顧客の問題を解決したものを素早く簡単に確認できるようにすることを目標として書く必要があります。
サマリー作成を簡単にするため、General::Closing Summary マクロの使用を検討してください。これは情報がいくつか入力されたテンプレートを内部ノートとして追加します。あとは関連情報で残りの項目を埋めて、完成したメッセージを顧客向けの公開コメントにコピーするだけです。
留意すべき注意事項:
- チケットのライフサイクル中に複数の提案が顧客に提供された長期にわたるチケットの場合は、クロージャーサマリーを追加すべきです。
- クロージャーサマリーのフォーマットを補助する ‘Closure Summary’ マクロテンプレートが Zendesk で利用可能です。テンプレートの内容は必要に応じて修正・削除できます。
- 顧客が応答せずチケットが自動的にクローズされた場合は、クロージャーサマリーを追加する必要を感じる必要はありません。
- ライフスパンが短く、チケット履歴から解決策が容易に特定できるチケットの場合も、クロージャーサマリーを追加する必要を感じる必要はありません。（例: 解決策が単にドキュメントへのリンクだった場合）
bfd74782)