AIコールセンターとCRMを連携するときは、電話番号を顧客へひも付けるだけでは足りません。一回の問い合わせを表す受付ID、顧客を表すCRM ID、転送で分かれる通話区間を区別する必要があります。三つを混ぜると、別人の履歴を開いたり、転送後の対応を別件として保存したりします。

設計は、既知の顧客が一度電話してAIから人へ転送される流れから始めます。顧客特定からAIとの会話、転送後の担当者処理までを一つの受付として追ってください。その後に未知の発信者や転送失敗を加えると、必要な項目と例外が見えます。

受付IDと顧客IDを分ける

CRMの顧客IDは、人や企業を継続して識別する値です。受付IDは今回の問い合わせだけを識別します。同じ顧客が料金の質問と解約の相談で二度電話した場合、顧客IDは同じでも受付IDは二つ必要です。

電話基盤が発行する通話IDも保存します。Amazon Connect Customerの問い合わせレコードでは、最初の問い合わせを示すInitialContactIdと各区間のContactIdが分かれています。転送やコールバックでレコードが増えても、最初の問い合わせとの関係を追える構成です。

CRMには受付IDを中心に、顧客IDと各通話IDを関連付けます。録音や要約を顧客レコードへ直接追加し続けるより、一回の受付を表すケースまたは活動へまとめた方が経緯を確認しやすくなります。

受付IDはAI応対の開始時に発行し、通話が切れても変えません。転送先の担当者や後日のコールバックも同じ受付へ関連付けます。別の用件として扱う場合だけ新しい受付を作るルールにします。

顧客特定の状態を三段階で残す

着信した電話番号は検索条件に使えますが、本人確認の完了を意味しません。家族や代表番号を共有している場合があります。番号が一致しただけの段階と、本人確認後の段階を分けてください。

顧客特定の状態は「候補なし」「候補あり」「確認済み」の三つにします。候補が複数ある場合はAIが推測で一人を選ばず、追加情報を確認するか人へ渡します。候補なしでも問い合わせを拒否せず、仮受付として用件を残せる設計が必要です。

Amazon Connect Customerの顧客プロファイルは、音声通話で電話番号を検索に使います。複数のプロファイルが一致した場合は担当者が選ぶ仕様です。これは、番号一致と顧客確定を分ける実装例になります。

CRMからAIへ返す情報も、確認状態に応じて制限します。候補ありの段階で契約内容や住所を読み上げないようにします。本人確認で使った値は必要な結果だけを残し、認証に不要な入力を会話要約へ含めない方が安全です。

転送前後の情報を同じ受付へつなぐ

AIから人へ転送すると通話区間が増えます。最初のAI応対と転送後の有人応対には別の通話IDを付けます。一方で、用件と確認済みの顧客IDは同じ受付へ引き継ぎます。

転送先へ渡す情報は用件と本人確認の状態です。AIが確認した項目と未確認の項目も分けます。転送理由と緊急度も必要です。担当者が同じ質問を繰り返さず、次の対応を選べる情報へ絞ります。

問い合わせ属性の公式説明では、同じInitialContactIdを持つ区間で共有する属性と、区間ごとに保持する属性を分けています。共有属性は転送中の更新で過去区間にも反映されるため、区間固有の値には別の属性が必要です。

CRMでも同じ考え方を使えます。顧客IDと受付理由は受付全体の項目です。転送先、接続時刻、担当者の処理結果は区間ごとの項目にします。転送前の値を上書きせず、誰がどの区間で変更したか残してください。

会話履歴と要約の役割を分ける

録音、文字起こし、要約は同じ情報ではありません。録音は会話を確認する原本です。文字起こしは検索や確認に使います。要約は担当者が次の行動を選ぶための短い記録です。

CRMへは受付IDと通話IDに加え、録音・文字起こしの参照先を保存します。要約本文には用件と確認済み事項を入れます。約束と次の行動も分けてください。AIが生成したままか、担当者が確認または修正したかも状態として残します。

HubSpotのCRM解説では、電話を活動として顧客レコードへ関連付けられます。関連付けの公式説明は、担当者と会社など異なるレコード間の関係を別に扱います。CRMは異なっても、通話記録と顧客本体を分けて関連付ける参考になります。

録音や全文を複数のシステムへ複製する必要はありません。CRMで確認に必要な参照先と権限を渡し、原本の保存先を一つに決めます。個人情報保護委員会のガイドラインが示す委託先の監督も踏まえ、保存先と再委託先を把握してください。

後処理が終わるまで受付を完了にしない

AIとの会話が終了しても、CRM上の受付が完了したとは限りません。担当者への折り返し、予約変更、本人確認書類の受領などが残る場合があります。通話終了と業務完了を別の時刻で記録します。

有人転送では、担当者が通話後に分類やメモを修正する時間も必要です。Amazon Connect Customerの指標定義は、通話後の作業をAfter Contact Workとして通話時間と分けています。AI要約を使っても、確認や修正の作業がなくなるとは限りません。

CRMの終了状態は「AIで完了」「有人対応で完了」「折り返し待ち」「追加情報待ち」「未解決」に分けます。転送先を呼び出しただけで有人対応完了にしません。担当者が応答しなければ折り返し待ちへ変え、担当者と期限を入れます。

書き込みに失敗した場合は、通話済みかどうかを残したまま記録待ちにします。通話そのものを未実施へ戻すと、復旧処理で同じ顧客へ再び電話するおそれがあります。

六つの通話で受け入れテストを行う

候補製品のデモでは、同じCRM項目と受付ルールを使います。正常な一通話だけでなく、次の六つを試してください。

  1. 既知の顧客が電話し、一件の候補から本人確認後に受付を作る
  2. 同じ電話番号に複数候補があり、AIが一人へ決めつけない
  3. 未登録の発信者を仮受付として保存し、後から顧客へ関連付ける
  4. AIから担当者へ転送し、同じ受付IDで会話を続ける
  5. 転送先が応答せず、折り返しタスクと期限を残す
  6. 同じ問い合わせレコードを再受信してもCRMの活動が重複しない

六つ目は連携の再送を想定した試験です。Amazon Connect Customerの問い合わせレコードは少なくとも一回配信され、同じContactIdの更新版が届く場合があります。公式資料はContactIdで重複を判定し、LastUpdateTimestampで新しい内容か確認するよう案内しています。

確認後は三つのIDの対応表を一枚にします。顧客特定の三状態と五つの終了状態も加えてください。この設計を候補各社へ渡し、六通話を同じ条件で完了できるか比較します。