kakinang INSIGHTS · 2026-10-06

営業の交代時、次の担当者が顧客との会話を引き継ぐには?

金曜夕方の問い合わせが一人の担当者の画面にだけ残ると、月曜の担当者は何が回答済みか分かりません。逐語記録をそのまま渡すより、顧客が言ったこと、会社が答えたこと、不明点、次の責任を確認できる形にします。 AI 営業交代時の要約、有人対応、未完了事項を整理したいです。 は公開情報の説明と受付を助けますが、価格や期限の約束は権限のある人が決めます。

二人の営業担当者が問い合わせを引き継ぐイメージ
イメージ図。製品画面や実際の顧客記録ではありません

引き継ぎ概要に残す内容

情報を四つに分けます。顧客が述べたこと、会社が回答したこと、未確認事項、次に誰が何をするかです。品目、利用場所、希望日は原文に近い形で残します。提供済みの公開価格帯やサービス説明は記せますが、AIの推測を会社の約束に変えてはいけません。在庫、割引、仕様、契約など人が調べる項目を列挙し、最後に責任者と連絡方法を付けます。「興味あり、追跡してください」だけでは最初に何を確認するか分かりません。

Zendeskの公式資料はAIから人への引き継ぎを最初の応答者の変更として扱い、AIへ戻す時にも会話状態を区別しています。これは他社製品の例であり、kakinangが同じ状態名を使うという意味ではありません。参考になる問いは、いま誰が返答責任を持ち、何が起きたら責任が変わるかです。会話履歴には出所も必要です。「急いでいる」とだけ書くより、顧客自身が示した希望日と発言を残す方が判断に役立ちます。

短い様式には受信日時と窓口、顧客の目的、確認済み条件、既回答、未確認条件、有人対応の理由、次の責任者、実在する返答期限、最後の連絡状態を入れます。期限は勤務規則が実際にある時だけ書き、なければ調整待ちとします。私的な情報を広い共有メモへ丸ごと写さず、必要な欄だけにします。原会話への経路も残して、要約の言い換えが誤った事実にならないよう確認できます。

Zendesk Help

AI受付、リード、有人対応を区別する

kakinangのサイトAIは承認済みの公開知識から答え、範囲外の要件はリード受付や人へ案内できます。リードには連絡先と要件の要約を残せます。リード用メールは新しい相談、イベント通知メールは引き継ぎなど別用途です。実際に読む担当者へ設定します。権限のある人は会話履歴や顧客タイムラインで経緯を見て、人工メモに次回の行動を記せます。閲覧権限も仕事に必要な範囲にします。

ライブの有人対応は今答える人がいる前提で、勤務中に判断や安心が必要な場合に向いています。非同期の追跡は営業時間外に向きます。AIが公開情報を伝え、使える連絡先を受け取り、残りは後で人が扱うと説明します。「転送済み」を「担当者が入力中」と表現しません。週末の勤務が違うならサイトと助手の文面も変えます。実際の当番がいなければ分単位の約束をしないことが、見栄えのよい転送表示より大切です。

通知だけでは案件の責任者が確定しません。未処理リード、有人待ち、前日の返答約束を一日二回確認する担当を定め、実際の返信後に記録します。サイトかSNSか、受信窓口も記します。窓口をまたぐ本人同一性は信頼できる手掛かりと権限者の確認がある時だけ人が結びます。同名は証拠ではありません。誤った結び付けが判明したら解除し、他人の履歴がメモへ入っていないか調べます。

営業交代で会話と未確認事項を整理するイメージ
イメージ:確認済み事実、不明点、次の責任者を分けます。

Zendesk Help

週末の見積もり相談で練習する

設備販売会社に金曜17時45分「来週火曜の展示で使いたい。間に合いますか」と届いたと仮定します。AIは公開のサービスと連絡先を伝え、型番、数量、会場、返答可能な連絡先を尋ねます。現在の在庫と輸送を確認できないなら「必ず間に合う」と答えません。引き継ぎには火曜までの利用希望、提供された型番、在庫・配送・正式日付の確認待ちを記し、窓口と原文も残します。これは仮の練習であり履行の約束ではありません。

月曜の担当者は元の会話と現在の商品情報を調べます。欠品ならAIが「通常可能」と言っていても確約できません。倉庫と運送を確認し、可能な代替案、残る条件、顧客が決める最終時刻を分けて伝えます。週末にSNSから同名の相談が来ても自動統合せず、電話、メール等の信頼できる根拠を確かめた後でタイムラインを人が結びます。

交代ごとに三点を試します。顧客に回答済み事項を言い直させていないか、実際に約束した期限に責任者がいるか、人が決める事項をAIや要約が完了扱いにしていないかです。変更前後の引き継ぎ項目を比べます。値引きが承認待ちから承認済みに変わるには判断者、権限、顧客への返信が必要で、「対応済み」という記載だけでは完了ではありません。高リスク、週末、繰り返しの案件も抽出します。誰が何を待ち、何が不足し、次にいつ連絡するかを顧客へ伝え、「至急対応中」だけで済ませません。原因ごとに情報、担当、文面を修正します。在庫が欠けているなら指示文を長くしても解決せず、当番がいなければ通知を増やしても代替になりません。未処理、再質問、誤った約束を見る方が単なる「終了」表示より品質を判断できます。

次の担当者が週末の問い合わせを確認するイメージ
イメージ:AIの要約だけでなく原会話と在庫を確かめます。

チームからの質問

「有人へ転送」と出ればすぐ返事がありますか?

必ずしもありません。勤務中の担当者が今受けるライブ対応と、連絡先を残して後で対応する非同期の追跡を分けます。勤務体制がなければ転送するとだけ説明し、誰かがリアルタイムで見ているかのように示しません。

次の担当者は会話の全文を読む必要がありますか?

権限があれば原文を見直せますが、まずは確認済み条件、既に伝えた内容、不明点、次の責任と実際の期限を分けた要約が便利です。争いや機微な判断では原文に戻ります。

別の窓口から戻った人を同一人物として扱えますか?

信頼できる本人確認の手掛かりが必要です。同じ名前や文体だけで統合しません。権限のある人が確かめるまで別に扱い、他人の会話が混ざるのを防ぎます。

通知が送られれば引き継ぎ完了ですか?

いいえ。担当者が受け取り、実際に返答した記録が必要です。送信失敗、休暇、見落としの可能性があるため、管理画面の未対応案件も確認します。通知成功を接客完了と同一視しません。

出典と参考資料

  1. Managing conversation handoff and handback — Zendesk Help
  2. Viewing customer context for user, history, and device information — Zendesk Help