サポートのシフト引き継ぎ：ノートテンプレート、45分のルーティン、ヘルプデスク設定

サポートのシフト引き継ぎとは？

サポートのシフト引き継ぎとは、あるシフトのエージェントが未解決のキューを次のシフトに渡す瞬間のことです。1日中同じ部屋にいないチームなら、どこでも発生します。1つのオフィスでの2交代制、地域をまたぐフォロー・ザ・サン型、夜間をカバーするオフショアチーム、平日チームから週末チームへの引き継ぎなどです。顧客が午後6時5分に連絡できるなら、設計したかどうかにかかわらず、シフト引き継ぎは存在します。

優れた引き継ぎには2つの層があり、多くのチームはそのうち1つしか作っていません。

チケットノートは、顧客が同じ説明を繰り返さずに済むようにします。これが引き継ぎのコンテキストを渡す本来の目的です。シフトブリーフは、次のシフトが製品の障害を、困惑した問い合わせ1件ずつで気づく事態を防ぎます。チケットノートだけのチームはパターンを見逃します。Slackの要約だけのチームは、次のエージェントがチケットを開いたときに見えない場所に詳細を置いてしまいます。

シフト交代でチケットが漏れる理由

原因は「前のエージェントが怠けていたから」ではほとんどありません。構造的なもので、ヘルプデスクのデフォルトの挙動にそれが表れています。

担当者はオフラインなのに、チケットはそれを知らない。 Zendeskでは、営業時間はエージェントの統合ステータスを設定しません。Zendesk自身のOut of Officeガイドも「agents must remember to update their status」と警告しています。更新しなければ、ルーティングは彼らを対応可能と見なし続け、午後7時の顧客の返信は6時に帰った人のもとに届きます。

動きのないチケットは放置される。 Frontは不在ガイドでこの隙間を明確にしています。不在のチームメイトの会話への返信は割り当て解除されますが、「that do not receive new replies will be unaffected」とのことです。顧客があなたの返信を待っているチケットなら問題ありません。しかし、あなたが午前9時までに折り返すと約束したチケットでは問題です。

コンテキストが誰かの頭の中にある。 退勤するエージェントは、顧客がリセット手順をすでに試したこと、返金がリーダーから口頭で承認されたこと、今週同じアカウントから3件目のチケットであることを知っています。誰かが書き残さない限り、そのどれもチケットには載っていません。

しかも、それは最悪のタイミングで書かれます。あるエンジニアがHacker Newsで、シフト終了時の問題をはっきり語っています。

"I mean in IT i see first hand the notes left by people on pager duty in the middle of the night, and they differ significantly from the same peoples notes after a restful night of sleep."

unprepare, Hacker News

午後5時55分の疲れたエージェントも、同じように薄いノートを書きます。だからこそ、固定のテンプレートが必要で、最初の下書きはソフトウェアに任せるべきなのです。

約束は担当者より長く生き残る。 「エンジニアリングに確認して、明日ご連絡します」は、顧客が覚えていて、次のシフトが一度も聞いていない約束です。顧客から見れば会社が約束を破ったことになるので、CSATスコアを落とす原因はこれです。

引き継ぎは増やすのではなく減らす

最も強く勧めたい発想の転換がこれです。シフト終了時の本能は、何も宙に浮かないよう、すべてを引き継ぐことです。しかしそれは引き継ぎを増やし、引き継ぎのたびにコンテキストが漏れます。Zendesk自身のフォロー・ザ・サン型サポートのガイドも、自チームを「no daily handoffs」で運営していると説明しており、チケットは基本的に最初に拾った人のもとに残ります。

そこで、ノートを1つも書く前に、未解決チケットを3つの山に分けましょう。

1. 保持する。 顧客は今あなたを待っていません（保留中、第三者の返答待ち、あなたが返信済みで顧客がまだ）。あなたのチケットのままです。不在中に顧客が返信しても、後述の再割り当て設定が拾います。
2. 引き継ぐ。 あなたが戻る前にSLA目標の期限が来る、期限付きの約束をした、または顧客がライブチャネルで会話の最中である場合です。これらにはノートと新しい担当者を付けます。
3. AIに任せる。 夜間に届く定型的な質問（注文状況、パスワードリセット、ナレッジベースがすでに答えているハウツー質問）は、AIエージェントがキューを担当していれば、人への引き継ぎは不要です。

「引き継ぐ」山が数件を超えるなら、問題は上流にあります。チケットが長く滞留しているか、シフトが仕事量に対して短すぎるのです。引き継ぎノートではそれは直りません。

引き継ぎノート：5行のテンプレート

実際に担当が変わるチケットでは、ノートが何よりも重要です。書くのに1分未満、読むのに1分未満で済むようにしましょう。

マクロとして保存することを勧めるバージョンはこちらです。

HANDOFF [date, your shift]
Asked: [what the customer wants, in one sentence]
Tried: [what you already did or ruled out]
Promised: [what you told them, and by when]
Next step: [the one action the next person takes]
Owner now: [name or group]

最も効くのがPromisedの行です。1つのフィールドだけ必須にするなら、これにしてください。「顧客が怒っている、確認お願いします」というノートは、テンプレートのどの行も満たしていません。次のエージェントは、前のエージェントがすでに知っていたことを知るために、スレッド全体を読み直す羽目になります。

実際にありそうなチケットでのビフォー・アフターです。

ノートは、Slackだけでなく必ずチケットに内部メモとして残してください。どのヘルプデスクも対応しています。Zendeskのマクロはコメントモードを非公開に設定でき、Help Scoutは内部メモのテンプレートとしてSaved Repliesを推奨し、Gorgiasのマクロは1クリックで内部メモの送信とエージェントの割り当てを行えるため、ノートと再割り当てが同時に済みます。プレースホルダーのテキストを消すのではなく空欄を埋めてほしい場合は、Zendeskのマクロ入力フィールドが各値を入力するよう促します。

シフトブリーフ：キュー全体への1通のメッセージ

シフトブリーフはキュー全体の層で、短いものです。5つの箇条書きを、毎シフト同じチャンネルに同じ時刻に投稿します。

• 障害： 今壊れているものすべて。社内の追跡リンク付き。
• ボリューム： 普段と違うこと（「午後2時のメールキャンペーン後に返金チケットが増加」）。
• リスク： 次のシフト中にSLA違反になるチケット。チケット番号付き。
• 期限の迫る約束： 次の引き継ぎまでに果たすべき折り返しやフォローアップ。
• 注意事項： 対応中のVIPアカウント、誤っているマクロ、今日変わったポリシー。

次のシフトがそうしなければ痛い目に遭って知ることだけに絞りましょう。閉じたチケットをすべて振り返るブリーフは、3週目には誰も読みません。

24時間体制のキューを運営するチームは、ほぼこの形に落ち着きます。24時間365日稼働のネットワーク運用センターで働いていた人の話です。

"Worked for a 24x7 NOCC for a while. We had at a minimum a handoff email that had a break down of active tickets along with their current progress and any tickets that needed immediate attention highlighted, along with alarms, and some other necessary info for the next shift. Since we were all in one room we also had coverage overlap of about 30 minutes and we would use that time as an informal information exchange."

Wamadeus13, Reddit

45分の引き継ぎルーティン

両シフトに分けて、まず始めるならこのルーティンです。時間は調整してかまいませんが、順序は守ってください。

退勤側シフトの最後の30分

1. キューを確認する（10分）。自分に割り当てられた未解決チケットのビューを開き、保持・引き継ぎ・AIに任せるに仕分けます。
2. ノートを書く（15分）。引き継ぐチケットすべてに5行のノートを書き、明日病欠かもしれない特定の個人ではなく、次のシフトのグループに再割り当てします。グループベースのチケットルーティングが残りを処理します。
3. ブリーフを投稿する（5分）。共有チャンネルに5つの箇条書き。

重なりの時間（上記と同じ時間内）

理想は、入るシフトの最初の15分が、出るシフトの最後の15分と重なり、二人ともオンラインのうちにブリーフが届くことです。ここで質問がその場で行われます。たった15分でも、完璧な書面の引き継ぎに勝ります。出る側がまだ覚えているうちに、入る側が「これはどういう意味？」と聞けるからです。

"The reason shift handoffs go bad is it's usually a singular information dump right as the next round is getting into work mode."

cogman10, Hacker News

同じ投稿者の解決策は1時間の重なりです。ほとんどのサポートチームには毎シフトそれだけの余裕はありませんが、引き継ぎチケットに絞った15分でも、効果の大部分は得られます。

入るシフトの最初の15分

4. ブリーフを読む。キューに触れる前に読み、そのあと新着分にいつものチケットトリアージを行います。
5. 期限の迫る約束を確認する。 次のシフト中の時刻が書かれた「Promised」の行は、すべて最優先でリストに載せます。

そのうえで、自分のステータスを両方向で正しく設定してください。退勤したエージェントがヘルプデスク上で「オンライン」のままだと、ルーティンは崩れます。

人が忘れることを拾うようヘルプデスクを設定する

ルーティンは、人が覚えているチケットを扱います。ヘルプデスクの設定は残りを扱います。誰もフラグを立てていないチケットへの午後9時の顧客の返信です。大手5つのヘルプデスクにはそれぞれこれに相当する機能があり、プランの制限が重要です。

Zendesk

ZendeskはOut of Officeアプリを廃止し、その機能をオムニチャネルルーティングに移しました。カスタムの「Out of Office」ステータスを作成し、2つの別々のスイッチをオンにします。再オープンされたチケットの再割り当てと、エージェントがそのステータスに切り替えたときに"the 50 most-recently updated open email and messaging tickets"を拾う「Auto-reassign open tickets」です。

注意点が2つあります。この設定にはProfessional以上が必要で、しかもステータス自体は変更されなければなりません。Zendeskは、長い一日の終わりに誰かがドロップダウンをクリックすることに頼らないよう、"Google Calendar or Outlook"や"WFM schedules"からAPIでステータスを設定することを勧めています。Professional未満の場合の代替策は、Zendeskの手動の一括方式です。"Assignee is (agent)"と"Status less than Solved"で絞り込んだビューを作り、担当者を一括変更します。ルーティング設定の残りは私のZendeskルーティングガイドで扱っています。

Freshdesk

FreshdeskのAgent Shiftsのドキュメントは、引き継ぎの問題をほぼそのまま描写しています。朝シフトのエージェントが返信し、シフトが終わり、顧客が返信してくる、という状況です。チケット更新のたびにエージェントの対応可否を確認するルールを使って、チケットを"re-routed, re-assigned, or have the customer notified to expect a delay in response"にできます。

シフト機能は対応可否を自動で切り替えます。Zendeskがエージェント任せにしている部分です。トレードオフはプランで、Agent ShiftsはEnterpriseにあります。設定する場合は、Freshdeskのエージェントシフトについてさらに書いた記事もあります。よりシンプルな構成なら、ラウンドロビンを扱ったFreshdeskの自動割り当てのガイドをご覧ください。

Help Scout

Help Scoutには、ユーザーごとのConversation Reassignment設定があります。選択した不在期間が過ぎると、"any Active or Pending conversations assigned to an away user will be automatically unassigned"となり、本人がActiveに戻った時点で止まります。これをプレゼンス検出と組み合わせます。Help Scoutのステータスガイドによれば、アプリを閉じると10分以内にAwayになるため、ステータスの問題はほぼ自然に解決します。

調整すべき点が1つあります。不在期間は自分で決められるため、短くすると引き継ぎは早くなりますが、長めの昼休みを取っている人からチケットを取り上げてしまうこともあります。プランに含まれるそのほかの機能は、私のHelp Scout AIの概要をご覧ください。

Gorgias

Gorgiasはシンプルで、すべてのヘルプデスクプランに用意されています。チケット割り当ての設定では、「Unassign on reply」がエージェントのオフライン中に再オープンされたチケットを再割り当てし、別のチェックボックスが、会話の途中でエージェントが対応不可になったライブチャットを扱います。Gorgiasは同じドキュメントでトレードオフについて率直です。1人のエージェントが続けて担当すると"might contribute to a consistent experience"であり、再割り当てすると"might lead to faster resolution times"とのことです。シフト引き継ぎなら、特にキューが主に非同期のメールなら、私は速い方を選びます。ルーティングについては、私のGorgiasの自動割り当てのガイドをどうぞ。

Front

FrontのShifts機能（Enterprise）は、シフト開始時にチームメイトをAvailable、終了時にOut of officeに設定し、"new replies from the customer will also trigger conversations to unassign from any teammates not working on the shift."となります。

Frontにはノート自体にも使える便利な方法があります。ルールの「Add comment」アクションで、@メンション付きの固定された内部コメントを投稿できます。覚えておくべき隙間は先ほどと同じです。動きのない会話は割り当てられたままなので、Frontでも「キューを確認する」ステップは重要です。AIアドオンについては、私のFront AIの解説で扱っています。

シフト引き継ぎのどこにAIが入るか

AIが役立つ場所は3つあり、コストも失敗の仕方も異なるので、分けて考える価値があります。

1. チケットノートを下書きする要約。 現在、ほとんどのヘルプデスクがAIによるチケット要約を提供しています。Help ScoutのAI Summarizeは、"handing off a conversation to another teammate"を用途の1つに挙げています。制限はよく読む価値があります。ZendeskのCopilot要約は2026年5月にProfessionalプランで利用可能になりましたが、Copilotの発表によると、エージェント1人あたり月5回のAI利用枠で、アカウント全体でプールされ、上限は500です。これでは毎日の引き継ぎには足りず、無制限で使うには$50のCopilotアドオンが必要です。Frontの要約にはCopilotアドオン（$20/シート）が必要で、Freddyの要約にはFreddy AI Copilot（$29/エージェント）が必要です。

Zendesk側については、私のZendeskのAI要約のガイドでさらに詳しく解説しています。

要約は下書きであり、引き継ぎそのものではありません。何が起きたかは次のエージェントに伝えますが、スレッドに書かれていない限り、あなたが何を約束したかはほとんど分かりません。Promisedの行は人の手で書き続けてください。

2. スケジュールされたシフトブリーフ。 キュー全体のブリーフは、タイマー付きのAIチームメイトに向いた仕事です。eeselでは、スケジュールジョブが「summary of all support tickets from the last 24 hours」のようなプロンプトを、毎日、毎時、または毎週、選んだタイムゾーンで実行し、次のシフトが見る場所に投稿します。

eesel上のあるサポートチームは、まさにこれを「daily support handoff summary」として運用しています。その設定からの正直な教訓は、ある回にジョブが何も出力せず、朝のシフトが情報なしで始まって初めてチームが気づいた、ということです。ブリーフを書くツールが何であれ、最初の数週間は人が目を通し、「ブリーフが届かない」ことを、静かな日ではなくアラートとして扱ってください。

3. そもそも引き継ぐチケットを減らす。 これが最大のてこです。午前2時に回答された定型チケット1件は、朝のシフトが引き継がずに済むチケット1件です。Anytime Fitnessでは、夜10時に質問した会員は以前は朝まで待つ必要がありました。eeselがよくある質問に回答することで、5,000以上のジムで、どの時間帯でも回答が得られます。これはAIによる24時間365日のサポートと同じ考え方です。

これを安全にするルールは、導入を検討する顧客がほぼすべての通話で求めるものです。AIは確信のあることにだけ答え、残りは残すべきだ、ということです。1日200〜250件のZendeskキューを抱えるサポートマネージャーは、目標を次のようなアプリケーションだと述べました。

"handle 60% of the incoming zendesk tickets and know when to pull a real person in for better analysis and resolution."

これは引き継ぎの縮図です。AIは夜間に定型分を引き受け、答えなかったものにタグを付けて要約し、朝のシフトは人が必要なチケットから始められます。これはAIから人への引き継ぎと同じ原則で、時計が付いているだけです。

シフト引き継ぎのよくある間違い

• グループではなく個人に引き継ぐ。 明日の指名されたエージェントが病欠なら、チケットは止まります。次のシフトのグループかキューに引き継ぎましょう。
• ノートがチケットではなくSlackにある。 次のエージェントが開くのはチケットであって、昨夜のチャンネルではありません。Slackはブリーフ用で、ノートはチケットに残します。
• ステータスの管理を記憶任せにする。 ヘルプデスクがスケジュールやプレゼンス検出でステータスを切り替えられるなら、使いましょう。Zendesk自身も、手動のステータスは"require[s] agent discipline."と述べています。
• SLAタイマーが誤った時計で動く。 引き継いだチケットが退勤側のリージョンの営業時間を保持していると、SLAが変なタイミングで停止または違反になります。SLAポリシーは、今そのチケットを持つグループのスケジュールに合わせてください。
• 引き継ぎ自体の担当者がいない。 各シフトの誰かがブリーフの担当になります。持ち回りでもよいので、必ず名前を決めてください。さもないと、少しずつ行われなくなります。
• 何も測らない。 各シフトの最初の2時間の再オープン率を追跡しましょう。SLA違反も同様に追跡します。方法は私のZendeskのSLA追跡ガイドで紹介しています。両方がシフト交代時に急増するなら、問題は引き継ぎにあります。

サポートのシフト引き継ぎにeesel

eeselのAIヘルプデスクのチームメイトは、すでに運用しているキューに参加します。Zendesk、Freshdesk、Help Scout、Gorgias、Frontのいずれでも構いません。シフト交代時には、人が疲れているときに飛ばしがちな2つの仕事をこなします。スケジュールでシフトブリーフを書き、自分が回答しなかったチケットに内部メモとして要約を残します。夜間は、過去のチケット、ヘルプセンター、マクロから学び、自信のある定型チケットに回答するため、朝のシフトは、コンテキストが付いた短いキューを引き継げます。

ライブのチケットに触れる前に、過去の数百件のチケットに対して実行し、どう回答したかを確認できます。料金に夜間シフト分のシートは加わりません。Teammateプランは月$299で500クレジットから、1チケットまたは1チャットが1クレジットです。

朝がスレッドの読み直しに1時間かかる状態で始まるなら、ご自身のキューでeeselを無料で試し、今夜の引き継ぎを書かせてみてください。