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

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

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

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

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

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

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

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

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

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

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

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

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

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

再送条件は製品ごとに異なります。HubSpotのエラー処理では、接続失敗と5秒を超える応答が再送対象です。4xxまたは5xxを受けたWebhookも最大10回再送します。この仕様を使う場合、同じ通知が複数回来ても活動履歴を一件に保つ処理が必要です。

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

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

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

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

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

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

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

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

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

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

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

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

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

連携方式は、正常に一件通っただけでは決めません。本番と同じ顧客IDと項目を使います。同じ権限も設定し、次の六つを試します。

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

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

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

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