AIテレアポのCRM連携方式を比較する方法

AIテレアポのCRM連携は、製品欄に「対応」と書かれているだけでは比較できません。CRMから架電を指示する経路と、通話結果をCRMへ戻す経路は別の仕組みだからです。どちらか一方だけでは、未発信や記録漏れを人が補う運用になります。

比較するときは、APIやCSVという方式名から入らない方が分かりやすくなります。一件の顧客を選び、発信指示から通話と結果保存までを追ってください。最後に次の行動へつながったか確かめます。

途中で失敗した場合は、気づく担当者と再開地点を決めます。ここまで決まれば自社に必要な方式を選べます。

発信指示と結果返却を分けて確認する

最初に、CRMからAI電話へ渡す情報を決めます。最低限必要なのは顧客IDと電話番号です。発信可能な時間帯、会話シナリオ、担当者も渡します。CRM上のステージ変更やフォーム登録を起点にする場合は、同じ更新から二度発信しない識別子も必要です。

通話後は、AI電話からCRMへ結果を戻します。応答の有無とヒアリング結果を分けます。要約に加え、次の行動と停止希望も保存します。録音URLだけを残しても、営業担当が全件を聞き直さなければ次の対応を選べません。

nocall.aiの公式サイトでは、CRMからAPIで架電を指示し、完了結果をWebhookで返す構成が案内されています。このように往路と復路で異なる方式を使う製品もあります。「CRM連携あり」という一項目ではなく、二つの経路を別々に確認してください。

CRMとSFAに残す項目を一通話で決める

架空の営業先A社へ電話し、「資料を見てから検討したい」と回答を得た例を考えます。接続できたことと商談化したことを分け、次のように記録します。項目名は設計例で、すべてのCRMに標準搭載されているという意味ではありません。

HubSpotの通話活動APIでは、通話を顧客などのレコードへ関連付けられます。タスクAPIは担当者と期限を持つ作業を扱います。通話の記録と人が行う作業を分ける参考になります。

日程が確定した場合は予定IDを記録し、同じ面談の予定と折り返しタスクを二重に作りません。不在なら通話結果だけを残すのか、再試行の作業も必要なのかを定義します。要約は経緯を読むために使い、停止や担当者、確定日時の代わりにはしないでください。

録音と文字起こしは原本へ権限付きで参照できれば、CRMへ全文を複製しなくてもよい場合があります。担当者が確定した値には修正者と時刻を残し、後から届いたAIの古い結果より優先させます。

APIは一件ずつ確定させる業務に向く

API連携は、問い合わせ直後の架電や営業担当への即時通知など、結果を早く確定したい業務に向きます。送信した一件に対して成功または失敗の応答を受け取り、CRM側の状態を更新できます。

Salesforceの公式解説では、個別レコードの操作にREST APIを使います。複数レコードの処理はComposite APIです。大量データにはBulk APIを使い分けています。AI電話でも、日々の一件単位の指示と大量リストの初期投入を同じ方式へ寄せる必要はありません。

確認するのは、APIを利用できるかどうかだけではありません。認証方法と利用可能な項目をそろえます。回数制限と応答待ち時間も確認してください。CRMへの保存が失敗したとき、通話自体を未完了に戻すのか、通話済みのまま記録待ちにするのかも決めます。

一件の処理へ会社情報と担当者を含める場合があります。活動履歴まで同時に書くと、途中まで成功する可能性があります。顧客レコードだけ作成され、活動履歴が残らない状態を検知できるか確認してください。再実行時は成功済みの処理を重ねず、足りない記録だけを補える構成が必要です。

Webhookは再送と重複を前提にする

Webhookは、通話完了や商談希望などの出来事を受信側へ通知する方式です。CRMが定期的に結果を取りに行くより早く反映できます。一方で、受信側が停止している時間や応答が遅い場合に備えなければなりません。

再送条件は製品ごとに異なります。HubSpotのエラー処理では、Webhook通知の接続失敗、5秒を超える応答、4xx・5xxが再送対象です。一方、ワークフローの4xxには原則再試行しない例外規則があります。Webhookとワークフローを同じ条件で扱わず、利用する機能の仕様を確認してください。

通話IDまたは連携イベントIDをCRMへ保存し、同じIDを受けたら新規作成ではなく処理済みと判定します。電話番号だけで重複を判断すると、同じ相手へ別日に行った正当な通話まで消してしまいます。

同じIDを検索してから作成するだけでは、二つの通知が同時に処理されると両方が新規作成へ進む場合があります。一意制約や処理の排他など、採用するCRMと連携基盤で使える方法を設計担当へ確認します。

受信に失敗した通知は、一覧で確認できる状態にします。担当者が再送できることに加え、最初の受信時刻と成功時刻を残します。Webhookを受け取った事実と、CRMへの保存が完了した事実を分けると、どこで止まったか追いやすくなります。

CSVは識別子と上書き範囲を先に決める

CSVは、検証用の発信リストや日次の一括更新に使いやすい方式です。連携開発を待たずに始められますが、即時対応には向きません。書き出し、加工、取り込みの間にCRM側の情報が変わることもあります。

HubSpotのインポート仕様では、既存レコードの更新や重複防止に一意の識別子を使います。メールアドレスと会社ドメインに加え、Record IDや重複を許さない独自項目が例です。AI電話のCSVにも、自社CRMの顧客IDと通話IDを入れてください。

初回試験では既存の担当者と商談ステージを上書きしない項目にします。停止希望も固定してください。取り込む列を増やすほど便利になるとは限りません。AI電話が新しく確定した通話結果だけを更新し、人が管理する顧客属性は変更しない方が復旧しやすくなります。

エラー行は修正して再投入します。その際、成功行まで含む元ファイルをそのまま取り込まないようにします。取込日時と元ファイル名を残します。処理結果も記録すれば誤更新が起きた範囲を絞れます。

通知と手動登録は例外処理に限定する

チャットやメールへの通知は、商談希望や苦情をすぐ担当者へ知らせる用途に向きます。ただし、通知を送っただけではCRMの記録は完成しません。担当者が通知を見落とした場合や、別の人が対応した場合に結果が残らないためです。

手動登録を使うなら、対象を例外へ限定します。担当者不在の転送や複雑な相談が候補です。連携エラーも含め、人の判断が必要な通話だけを対象にします。通常の通話結果まで手動にすると、件数が増えたときに記録品質が担当者ごとに変わります。

通知には顧客IDと通話IDを含め、CRMの対象レコードへ移動できるようにします。通知本文へ録音や個人情報を広く載せず、権限を確認できるCRMまたはAI電話側で閲覧します。

個人情報保護委員会のガイドラインは、個人データを委託する場合に委託先の選定と契約を求めています。取扱状況の把握も必要です。AI電話から連携基盤を経てCRMへ渡るデータについて、保存先と再委託先を把握してください。

停止情報の正本と反映範囲を決める

停止希望は会話の要約だけに残しません。対象の会社・担当者・電話番号と希望の範囲、受付日時、経路を保存します。発言が曖昧なら狭く推測せず、その相手への自動発信を保留して確認します。

CRMとAI電話、リストのどれを停止情報の正本にするか決めます。同期に失敗した場合は自動発信へ戻さず、発信直前に最新の正本を照合できることを確認してください。解除は権限のある担当者だけが根拠と履歴を残して行い、CSVの空欄で解除されないようにします。

停止を通知しただけでは反映完了とは数えません。予約済み再試行が取り消されたか、別施策にも適用されたかを記録します。詳しい運用はAIテレアポの停止リスト管理へまとめています。

六つの障害テストで方式を決める

連携方式は、正常に一件通っただけでは決めません。本番と同じ項目構造と権限を持つテスト顧客を使います。実在顧客へ試験発信せず、次の六つを試します。

1. CRMの一件から一度だけ架電され、同じ顧客IDへ結果が戻る
2. 同じ発信指示を再送しても二重に架電されない
3. 同じWebhookを再受信しても活動履歴が増えない
4. CRM保存が途中で失敗し、失敗地点から再開できる
5. CSVのエラー行だけを再投入し、既存の担当者情報を上書きしない
6. 停止希望が次の発信リストを作る前に反映される

各テストでは発信要求IDと通話IDを一つの記録で追います。CRMの顧客IDも同じ記録へ残します。終了状態は成功と再送待ちを分けます。手動確認と処理中止も別にしてください。

さらに代表番号を共有する二つの連絡先、資料希望、日程確定済みの通話を加えます。担当者が録音を開かずに次の行動を選べるかを確認し、不要なタスクや重複予定ができないことを確かめます。

「連携エラー」だけでは、顧客へ電話したのか判断できません。

問い合わせ直後の連絡はAPIとWebhookを中心にし、大量リストの準備はCSVへ分ける方法があります。通知と手動登録は例外処理に残します。方式の多さを競うのではなく、六つの障害テストを最も少ない手戻りで完了できる構成を選んでください。