チケット

このガイドでは、チケットステータス、システム設定、サポートオペレーションの一般的なワークフローを含む、Zendesk のチケット管理について説明します。

チケットを理解する

チケットを作成する

伝統的に、私たちはエンドユーザー自身でチケットを作成してもらいたいと考えています。それが理想的でない状況では、利用可能な定められたオプションがあります。

Zendesk Super App 経由

これは既存ユーザーから新規チケットを作成する必要がある場合に使用すべきです。これには、対応するアプリを使用します。

• Zendesk Global の場合: Zendesk Super App
• Zendesk US Government の場合: Zendesk Super App

送信通信用

詳細はサポートチームの通知の送信ドキュメントを参照してください。

チケットを表示する

チケットの表示については以下を参照してください。

• ビュー
• 検索

ステータス

Zendesk によると、各種ステータスは以下のように定義されています。

• New
  • チケットに対してアクションが取られていないことを示します。一度 New チケットのステータスが変更されると、二度と New に戻すことはできません。
• Open
  • チケットがエージェントによるアクションを待っていることを示します。
• Pending
  • エージェントが依頼者からの追加情報を待っていることを示します。依頼者が応答して新しいコメントが追加されると、チケットステータスは自動的に Open にリセットされます。
• On-hold
  • エージェントが依頼者以外の誰かからの情報またはアクションを待っていることを示します。Pending ステータスと似ていますが、エージェントとして他の誰かからの情報を受け取るまでチケットを解決することはできません。ただし、On-hold は内部ステータスで、チケット依頼者には見えません。チケットが On-hold に設定されている間、依頼者にはステータスが Open として表示されます。
• Solved
  • エージェントが解決策を提示した、またはエンドユーザーがその旨マークしたことを示します。Solved チケットはまだ編集または再度開くことができます。
• Closed
  • チケットが更新を受け付けない状態にあることを示します。クローズされたチケットへの返信はフォローアップチケットを開き、これには以前のすべてのタグと前のチケットへのリンクが含まれます。

GitLab では、これらを少し異なる形で定義します。

• New
  • これは新規チケットです。これは、まだ GitLab で対応していないことを意味します。
• Open
  • チケットが私たちの返信を待っていることを意味します。
• Pending
  • エンドユーザーからの返信を待っていることを意味します。これは特に、ユーザーがチケットに返信する（または自動解決する）場合にのみ使用すべきです。長期間「pending のような」状態にチケットを保持する必要がある場合は On-hold を使用してください。
• On-hold
  • エンドユーザーが私たちを待っているが、私たちは返信を妨げる何かを待っていることを意味します。私たちは、別の部署、時間の経過（例として namesquatting リクエスト）、または同じコンセプトに沿ったその他の基準などの何かを待っている状況でのみこれを使用すべきです。
• Solved
  • チケットが解決されたが、エンドユーザーが私たちに戻ってくる可能性があることを意味します。
• Closed
  • Zendesk が定義するとおりに使用します。

現在のシステムチケット設定

これらの設定はリファレンスとしてここに記載されており、変更されることはまれです。

現在のチケット共有設定

これらの設定はリファレンスとしてここに記載されており、変更されることはまれです。

管理者タスク

クローズチケットを変更する

Zendesk にはクローズチケット内のいくつかの値を更新する機能がありますが、これは私たちが実施するアクションではありません。Zendesk のデータを利用するいくつかのチームとの議論、およびクローズチケットの変更が顧客に与える影響をレビューした結果、以下の理由に基づいて判断しています。

• クローズチケットの更新は顧客に悪影響を与えます（実用的な回避策がない）
• クローズチケットの更新は Zendesk Explore のレポート/ダッシュボードに重大な影響を与え、完全な再構成を要します
• クローズチケットの更新はデータウェアハウス内のレポートに重大な影響を与え、完全な再構成を要します
• クローズチケットの更新は、データウェアハウス内のデータの完全な再インデックスを要します（大量のリソースを消費し、5 日以上を要します）
• データウェアハウス内でカスタムビュー、カスタムテーブル、AI を使用して実行可能な実用的な回避策があり、クローズチケットの更新を実施することの認識される利点を打ち消します

システムチケット設定を変更する

システムチケット設定を変更するには:

1. Zendesk インスタンスの管理ダッシュボードに移動
   • Zendesk Global (production)
   • Zendesk Global (sandbox)
   • Zendesk US Government (production)
   • Zendesk US Government (sandbox)
2. Objects and rules > Tickets > Settings に移動
   • Zendesk Global
   • Zendesk Global (sandbox)
   • Zendesk US Government
   • Zendesk US Government (sandbox)
3. 変更したい設定を修正
4. ページの右下にある Save をクリック

チケット共有設定を変更する

チケット共有設定を変更するには:

1. Zendesk インスタンスの管理ダッシュボードに移動
   • Zendesk Global (production)
   • Zendesk Global (sandbox)
   • Zendesk US Government (production)
   • Zendesk US Government (sandbox)
2. Objects and rules > Tickets > Sharing に移動
   • Zendesk Global
   • Zendesk Global (sandbox)
   • Zendesk US Government
   • Zendesk US Government (sandbox)
3. 変更したい設定を修正
4. ページの右下にある Save tab をクリック

Customer Support Operations のワークフロー

チケットの対応

サポート連絡先の管理

連絡先管理に関する Zendesk Global チケットについては、組織関連付けドキュメントを参照してください。

連絡先管理に関する Zendesk US Government チケットについては、Salesforce アカウントとの同期によって、すべてのサポート連絡先関連付けが行われます。そのため、ここで対応はできません。依頼者には、新しいメールでアカウントマネージャーに連絡するように指示する必要があります。アカウントマネージャーのメールを必ず提供してください。

共有組織リクエスト

Shared Organization セットアップドキュメントを参照してください。

ポータルの問題

これらはサポートポータル内の問題のレポートです。各 Issue は固有のチャレンジを呈する可能性がありますが、ユーザー向けの一般的なトラブルシューティングガイドは以下にあります。

• Zendesk Global
• Zendesk US Government

チケットを受け取った時点で、ユーザーがそれらすべてを実施しているかどうかは不明な場合があります。実施していない場合は、まずすべて試すように案内してください。

実施している場合は、送信された詳細を分析して次のステップを決定する必要があります。

セカンダリメールの追加リクエスト

時々、顧客がサポートポータルアカウントにセカンダリメールを追加したいという問題を提起します。セカンダリメールは、提出されたチケットを特定のアカウントに紐付けるために使用されますが、サブミッターとして使用されるのはプライマリメールアドレスのみです（つまり通知を受け取るのはこちら）。

• GitLab.com ユーザーの場合:
  • 依頼者のメールアドレスに関連付けられた GitLab.com アカウントには、セカンダリメールが verified としてリストされている必要があります。これは User Lookup アプリで確認できます。GitLab.com アカウントにセカンダリメールを追加するには、このドキュメントに従ってください
• セルフマネージドおよび GitLab Dedicated ユーザーの場合:
  • チケットは、既存のプロファイルに追加したいメールアドレスから提出される必要があります
  • 顧客はこのセカンダリメールアドレス経由でサポートエンタイトルメントの証明を再度提供する必要があります
  • 顧客はサポートポータルアカウントのプライマリメールアドレスを CC し、そのメールでチケットに返信し、セカンダリメールアドレスをサポートポータルアカウントに追加する依頼を確認する必要があります
• パートナーの場合:
  • セルフマネージドおよび GitLab Dedicated ユーザーと同じ手順を使用

不正なフォームのチケット

チケットが不正なフォームを使用している場合、エージェントは General::Forms::Incorrect form used マクロを使用します。これによりフォームが Support Ops に変更され、チケットがタグ付けされ、内部ノートが残されます。そこから、私たちはチケットをレビューして次のステップを決定することが期待されます。

ここでの最終目標は、正しいフォームに移動することです。そのパスは多くの要因によって異なりますが、一般的には:

• 「有償のみ」のフォームに移動し、ユーザーが未関連付けの場合:
  • 組織関連付けのプロセスに従ってユーザーを関連付け
    • 関連付けできない場合、チケットは移動できない
  • チケットの Assignee の値を Support Ops（グループ）に設定
    • これによりチケットの割り当てが解除されます。送信時に追加された内部ノートで別途指示されない限り、常にこれを行う必要があります
  • チケットの Form の値を新しいフォームに変更
  • 新しいフォームの可能なすべてのチケットメタデータを記入
    • チケット上に存在する場合、Ticket Stage フィールドを FRT に設定
  • 以下のタグを削除:
    • base_weight_set
  • チケットを送信時と 同じ状態 で送信することを確認
• 「有償のみ」のフォームに移動し、ユーザーが関連付け済みの場合:
  • チケットの Assignee の値を Support Ops（グループ）に設定
    • これによりチケットの割り当てが解除されます。送信時に追加された内部ノートで別途指示されない限り、常にこれを行う必要があります
  • チケットの Form の値を新しいフォームに変更
  • 新しいフォームの可能なすべてのチケットメタデータを記入
    • チケット上に存在する場合、Ticket Stage フィールドを FRT に設定
  • チケットを送信時と 同じ状態 で送信することを確認
• 誰でも利用可能なフォームに移動する場合:
  • チケットの Assignee の値を Support Ops（グループ）に設定
    • これによりチケットの割り当てが解除されます。送信時に追加された内部ノートで別途指示されない限り、常にこれを行う必要があります
  • チケットの Form の値を新しいフォームに変更
  • 新しいフォームの可能なすべてのチケットメタデータを記入
    • チケット上に存在する場合、Ticket Stage フィールドを FRT に設定
  • チケットを送信時と 同じ状態 で送信することを確認

特殊フォームの注意事項

• チケットを 2FA Removal フォームに移動する場合
  • 削除リクエストが依頼者と異なるユーザーのものである場合、依頼者は対象ユーザーのメールアドレスを 必ず 提供する必要があります。提供していない場合、依頼者がその情報を提供する必要がある旨の内部ノートを残してください。その後、代わりにチケットを SaaS Accounts フォームに移動します。
• チケットを L&R フォームに移動する場合
  • L&R フォームにチケットを移動する際、最初から正しいサブチームに振り分けられるようにする必要があります。これを行うには、BPO Ticket チェックボックス（チケットメタデータの最下部）がチェックされていることを確認します。これを行わないと、チケットルーティングで問題が発生する可能性があります。
• チケットを Billing フォームに移動する場合
  • チケットの Billing/AR Team 属性が入力されていることを確認する必要があります。使用する値が不明な場合は、Billing に設定してください

悪意のあるユーザーへの対処

潜在的に悪意のあるアクション（ハッキング、フィッシング、不正使用など）を含むチケットが発生した場合、常に真剣に扱う必要があります。

徹底的な調査の結果、悪意があると判断された場合は、ユーザーを BAN します。

疑わしい場合は、自分のマネージャー、Customer Support Operations Fullstack Engineer、および/または GitLab セキュリティチームに問題をエスカレーションしてください。

よくある問題とトラブルシューティング

これは必要に応じて項目が追加されていく、生きたセクションです。

ページのソースコードを見る - ページの編集 - please contribute.