AIコールセンターとCRMを連携する前の設計

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の案内だけで終わった用件なら通話活動だけで構いません。

以下は、電話受付で「請求の内訳を担当者から説明してほしい」と依頼された架空の例です。記号は説明用で、CRM製品が自動的にこの形式を発行するという意味ではありません。

タスクの14時は社内確認期限であり、顧客へ折り返しを約束した時刻ではありません。顧客の希望、実際の約束、社内期限を別項目にします。本人確認が終わっていないため、請求額などを自動で読み上げる処理も含めません。

HubSpotのCalls APIでは通話活動を作り、顧客やチケットへ関連付けられます。Tickets APIは依頼をステータスで追い、Tasks APIは担当者や期限を持つ作業を扱います。この役割分担は実装例であり、前表の業務状態がすべて標準項目として用意されているとは限りません。

代表電話の伝言受付でも同じ分け方を使えます。「電話が終わった」をチケットの完了へ変換せず、誰が伝言を引き受けたかを残してください。通知だけを受け取り、CRMを開かずに作業する運用では、この担当者の記録が抜けやすくなります。

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

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

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

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

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

候補が確定しないときも、未関連の受付を先に保存します。後から担当者が確認できた顧客へ結び付ければよく、聞き取った氏名ごとに正式な顧客レコードを増やす必要はありません。HubSpotの関連付けAPIでは、作成済みレコード同士の関係を後から管理できます。候補を選べないことと、受付を保存できないことを同じエラーにしない設計です。

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

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

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

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

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

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

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

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

要約とは別に処理用の値を持たせます。たとえば「午後希望」は要約に残し、確認できた場合だけ希望時間の開始・終了へ変換します。未確認なら未確認のままとし、AIが勝手に14時を予約しないようにします。値の出所を「本人の発言」「CRMから参照」「担当者が確定」に分けると、上書きしてよい範囲も決められます。

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

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

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

有人転送では、担当者が通話後に分類やメモを修正する時間も必要です。AI要約を使っても、確認や修正の作業がなくなるとは限りません。担当者が確定した用件や期限を、遅れて届いたAIの要約で戻さないようにします。

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

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

通知失敗だけを再処理する

CRMへ保存できたかと、通知が届いたかは別に管理します。先ほどのR-104でチケットK-301まで作成できていれば、通知に失敗してもチケットを新規作成し直しません。

二重作成を防ぐには「同じIDなら検索する」という手順だけでは不十分です。同じイベントを同時に処理する場合もあるため、連携側で受付IDと処理種別を一意に管理し、一件だけが作成へ進む仕組みを用意します。CRMに任意のIDを渡せば自動的に重複が防げるとは限りません。製品ごとのAPIと連携処理の両方で試してください。

業務状態とシステム状態も分けます。「折り返し待ち／CRM保存済み／通知失敗」のように併記すると、通話をやり直さずに通知だけを復旧できます。復旧できない間は、運用担当が保護された未処理一覧を受け持ちます。受付の保存までできないなら、完了を案内せず事前に決めた有人窓口へ切り替える必要があります。

日次確認では、AI側の受付IDとCRM側の受付IDを突き合わせます。100受付のうちCRMに98IDしかなければ差分2IDを調べますが、行数が100でも安心はできません。重複が2行あり別の2IDが欠落している場合があるためです。転送で通話区間が増える分は、受付件数ではなく通話ID単位で別に照合します。

通話と再送を組み合わせて受け入れテストを行う

候補製品のデモでは、同じCRM項目と受付ルールを使います。正常な通話だけでなく、受付が保存できた後の障害も試してください。

1. 既知の顧客が電話し、一件の候補から本人確認後に受付を作る
2. 同じ電話番号に複数候補があり、AIが一人へ決めつけない
3. 未登録の発信者を仮受付として保存し、後から顧客へ関連付ける
4. AIから担当者へ転送し、同じ受付IDで会話を続ける
5. 転送先が応答せず、折り返しタスクと期限を残す
6. 同じ問い合わせレコードを再受信してもCRMの活動が重複しない
7. チケット保存後に通知だけ失敗し、再処理で同じチケットを知らせる
8. 社内期限を過ぎた未受領タスクを、管理者または代替担当が引き受ける
9. 案内だけで終了した電話は活動のみを残し、不要なチケットを作らない

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

確認後は、R-104の例を自社の一件へ置き換えます。担当者がチケットを引き受けるまでの画面と、通知だけを再送した後の件数を確認してください。会話中に何を渡すか迷う場合は、有人転送と引き継ぎの設計の記入例を使えます。CRMの保存成功だけでなく、次の作業を一人の担当者が引き受けるところまでが連携の確認範囲です。