Content last updated 2026-05-18

チケットの転送

チケットの引き継ぎおよび再ホームの方法

はじめに

このページは、サポートエンジニア (SE) がチケットを別の担当者に転送する必要がある場合のガイドです。

チケットの転送

GitLab Support には、2 種類のチケット転送があります: rehomes（再ホーム） と handovers（引き継ぎ） です。以下のセクションでは、これらと、サテライトチケットおよびホット rehome の関連概念を説明します。

  1. Handover（引き継ぎ） 🤝: 有給休暇、専門知識、ワークロード管理などの要因により、チケットがあるエンジニアから別のエンジニアに転送されること。引き継ぎは通常リージョン内で行われますが、リージョンをまたいで発生する場合もあります。
  2. Rehome（再ホーム） 🏠: 初回応答を行った SE のリージョンから、顧客が指定した希望リージョンへチケットを転送すること。担当 SE のシフトが終わるとき、チケットを完了のために適切な（ホーム）リージョンに転送します。これは素早く簡単で、低コストであるべきです。
    • Satellite（サテライト） 🛰️: 指定された「ホームリージョン」の次のシフト中に未割り当てのままで、その後少なくとも一度はグローバルに循環する rehome されたチケット。これは意図しないものであり、サテライトを最小限にすべく取り組むべきです。
    • Hot rehome（ホット rehome） 🔥: 顧客の希望リージョンとは別のリージョンで現在対応されているチケット。顧客の温度感が上がって緊急度が上昇するため、チケットが rehome を必要とします。送信側のリージョンは善意で顧客にコミットしますが、受信側のリージョンに対して位置合わせと合意を取る時間がありません。

このようなチケットの例には次のようなものがあります:

  • 受信リージョンの空き状況を確認せずに、数時間以内にコール（電話）または特別なフォローアップが約束されたチケット。これは、サポートエンジニアが十分な準備なしに対応するうえで課題となります（Direct to Call - DTC）。
  • リージョン外にあって、STAR リクエストにより満たされない顧客の期待値が原因で Hot Rehome プロセスをトリガーするチケット（Falling Star）。
  • rehome されておらず、追加の注意を必要とするチケット（チケットが希望リージョン外に 1 シフトを超えて保持され、リスクが上昇している）。

Hot rehome の防止

顧客の希望リージョン以外にチケットを置く前に、以下のステップを完了してください:

合意: 顧客は、特定のリージョンに対する最初のリクエストが満たされないことを認識し、同意を提供する必要があります。さらに、現在のリージョンにチケットを保持することに伴う付加価値を理解する必要があります。

理解: 顧客は応答に遅延が生じる可能性があることを認識する必要があります。当初要求されたリージョンにチケットを転送する必要が生じた場合、受信エンジニアが十分に準備できるよう移行期間を設けます。

チケットに取り組むときは、他の人を代弁する約束を控えてください。代わりに、顧客の状況を概説し、顧客にとって良好な結果を達成する意図を強調する詳細なメモをチケットに残してください。必要に応じて、受信リージョンのマネージャーに連絡して支援を求めてください。さらに、受信側のサポートエンジニアの時間にも配慮してください。

チケット rehome（希望リージョンへの転送）

GitLab Support では、リージョンに関係なくすべての未割り当てチケットを単一のビューで使用しています。ビュー内のチケットは、最高優先度の Issue を最初に強調するため Ticket Weight でソートされています。サポートエンジニアは、ビューの上から順に作業することが期待されます。このプロセスを考えると、サポートエンジニアは、顧客が自身とは異なる Preferred region を指定したチケットを引き受けることが頻繁にあります。

GitLab Support では、チケットを責任あるリージョンに合わせることを目指しているので、異なるリージョンからのチケットを処理する以下のシンプルなプロセスを使用します。

初回応答

別のリージョンからのチケットに初回応答する際、以下のガイドラインに従います。

  1. rehome を開始するまでは、返信通知を受け取れるようチケットを自分にアサインします
  2. 自己紹介し、顧客の希望リージョンを認識します（Support::Out of Region::Cross-region_Preferred region clarify assignment マクロが良い出発点です）
  3. タイムリーな応答を保証するために、初期支援を提供していることを説明します
  4. 顧客の問題に対処し始めるために、適切なすべての初期ステップを進めます
    • 送信前に初回応答を確認し、もし自分が rehome を受ける側だったら見たい内容になっているかを自問してください。
  5. 業務時間が終わるまでに、顧客が継続を希望しない限り、希望リージョンに継続サポートのためチケットを転送する旨を顧客に伝えます。
    • 注: APAC は、AMER の希望リージョンを持つ低優先度チケットの担当を維持することもあります。背景については 元のポリシー発表 を参照してください。
  6. 業務時間が終わり、顧客がチケットの保持を 要求していない 場合、次のセクションに進んで rehome を開始します。
  7. それ以外の場合は、リージョン外チケットの保持 の手順に従ってください。

チケット rehome の開始

チケット rehome を開始する前に、自分がチケットの担当者になっていることを再確認してください。そうでない場合、自分にアサインして更新を送信してから先に進みます。

チケット rehome を開始するには Support::Rehome::Initiate Rehome マクロを使用します。このマクロは:

  1. rehome_initiated タグを適用します
  2. rehome の対象リージョンを示す内部コメントを適用します

チケットが顧客の返信待ちの場合:

  1. チケットステータスを Pending に設定します
  2. 顧客が応答するまでチケットはあなたに割り当てられたままで、その時点で:
    1. Zendesk がチケットステータスを Open に設定します
    2. トリガーが実行されてチケットの割り当てが解除され、チケットがグローバルビューに表示されるようになります
  3. チケットを送信して rehome を開始します

そうでなく、チケットがサポートエンジニアからの更新を待っている場合:

  1. チケットステータスを Open に設定します
  2. Assignee フィールドで、チケットを自分のリージョンのグループにアサインするオプションを選択します。たとえば Assign to Support AMER オプションを選択
    • これは、Zendesk でエージェントがチケット割り当ての解除を引き起こす方法です
  3. チケットを送信して rehome を開始します

チケット rehome の受け入れ

グローバルビューから未割り当てのチケットを受け取り、Rehome initiated from [assignee's region] to [target region] と記された内部コメントを見つけたら、以下のステップに従って rehome を受け入れます。

  1. リージョンの整合確認: 指定されたターゲットリージョンが自分のリージョンであれば、続行します。そうでなければ、ターゲットリージョンの SE が引き受けられるよう、ビュー内でチケットを未割り当てのままにします。
  2. Support::Rehome::Complete Rehome マクロを使用します。これは:
    1. チケットを自分にアサインします
    2. rehome_received タグを適用します
    3. rehome_initiated タグを削除します
    4. 利用するための初期テキスト付きの公開応答を作成します
  3. 初期テキストを編集して、プレースホルダーの場所に自分の名前を入れます
  4. 顧客の問題に対処し始めるための適切な初期ステップを進め、Next Steps Here プレースホルダーを顧客への完全な更新に置き換えます

リージョン外チケットの保持

顧客がチケットへの初回更新に対し、希望リージョンに転送するのではなく自分が継続することを明示的に求める応答をした場合のみ、以下のステップに従ってください。

  1. Support::Rehome::Do Not Rehome マクロを使用します。これは利用するための初期テキスト付きの公開コメントを作成します
  2. 通常のチケットと同じように進めます

チケット rehome のキャンセル

開始済み（ただしまだ完了していない）の Rehome をキャンセルする必要がある場合は、Support::Rehome::Cancel Rehome マクロを使用してください。

チケット handover（希望リージョンとは無関係の担当者変更）

エンジニアがチケットを別のリージョン、または同じリージョン内（例: 担当者が PTO に入る）で引き継ぐ必要がある場合、以下のワークフローに従う必要があります。

引き継ぎのためのチケットの準備
  1. 顧客に対して適切な期待値を設定します。
    1. 電話や即時応答などの特定の要件は、受信側の人またはリージョンとの調整が必要であることを透明性を持って伝えることが重要です。
    2. 受信チームが、顧客と最終決定する前に任意のタスクおよびタイムラインについて適切に通知され、整合していることを確認してください。
  2. Zendesk Handover Ticket Summary マクロ を使用して、必要な情報がすべて含まれていることを確認し、チケットを未割り当てにします。
  3. Zendesk フォームフィールドの Handover Status を Need Handover に設定します。
  4. 自分をチケットに CC し、Open 状態でチケットを保存します。
PTO による同一リージョン内の引き継ぎチケットの作業
  1. メトリクスの正確な追跡のため、Handover Status を Handover Completed に更新します。
  2. Handover Ticket Summary と Next Response Time (NRT) SLA を確認します。
  3. 進める準備ができている場合:
    • 顧客に自己紹介し、引き継ぎを確認し、次の技術的応答を提供します。
  4. 追加の調査が必要な場合:
    • 自己紹介し、追加の調査が必要であることを顧客に通知し、次のステップに対する期待値を設定します。
別リージョンから引き継いだチケットの作業
  1. メトリクスの正確な追跡のため、Handover Status テキストフィールドを受信リージョンを反映するよう更新します。 たとえば、EMEA リージョンにいる場合は Handed over to EMEA に設定します。
  2. Handover Ticket Summary と Next Response Time (NRT) SLA を確認します。
  3. 進める準備ができている場合:
    • 顧客に自己紹介し、引き継ぎを確認し、次の技術的応答を提供します。
  4. 追加の調査が必要な場合:
    • 自己紹介し、追加の調査が必要であることを顧客に通知し、次のステップに対する期待値を設定します。
最終更新 June 14, 2026: Merge pull request #403 from kyama0/claude/cool-turing-ls6eck (bfd74782)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License