CTIとCRMを連携するとき、最低限必要な項目は何ですか？

通話を一意に識別するID、発着信日時、相手を特定するキー、担当、要件、対応結果、次回行動、期限、記録や利用に関する同意状態を分けて持つ。録音URLや要約だけでは、案件を次へ進めるデータにならない。

電話番号だけで顧客を特定してよいですか？

電話番号だけを確定キーにすると、代表番号の共有、番号変更、同じ人の複数番号で誤結合や重複が起きる。電話番号は候補検索に使い、会社・担当者・案件のどこへ結ぶかを確認する手順を持つ。

通話要約はCRMのどこへ保存しますか？

全文要約を顧客マスタの固定項目へ上書きせず、通話という活動レコードへ保存する。顧客の要望、案件の決定事項、次回行動は別項目へ転記し、いつの通話を根拠に更新したか追跡できるようにする。

CTIとCRMのデータ連携設計｜通話ID・要件・次回行動をつなぐ項目表

CTIとCRMをつなぐ目的は、録音を保存することではない。電話で分かった要件を担当者と案件へ結び、次にすることと期限を残し、別の人が続きから対応できるようにすることだ。

電話、メール、LINEなどの入口を一つに見る話は反響チャネルの統合管理が扱っている。この記事はチャネル統合ではなく、一回の通話を活動・顧客・案件・次回行動へ分けるデータ辞書に限定する。

通話履歴と顧客マスタを同じ行にしない

顧客マスタは相手の現在情報を持つ。一方、通話履歴は、いつ、誰と、何を話したかという出来事だ。通話メモを顧客の備考欄へ追記すると、新しい内容が上に積まれ、どの案件の話か、次の行動が終わったかを集計できない。

CRM上では、会社、担当者、案件、通話活動、タスクを分ける。通話活動から会社・担当者・案件を参照し、通話から生まれたタスクを別レコードとして持つ。顧客プロパティの名前や定義が揺れている場合は、先にCRMの命名規則を整える。

通話活動のデータ辞書

項目	役割	入力元	更新
通話ID	重複登録を防ぐ一意キー	CTI	変更しない
発着信日時・方向	接触順と入口を示す	CTI	変更しない
電話番号	相手候補を検索	CTI	原値を保持
相手・案件ID	CRMの対象へ関連付け	自動候補＋人の確認	誤結合時のみ訂正
要件・結果	問い合わせ内容と着地	担当者または要約補助	確定後は履歴を残す
次回行動・期限	対応漏れを防ぐ	担当者	完了時に状態更新

項目名だけでなく、意味、入力元、更新できる人、空欄を許す条件まで辞書へ書く。「対応済み」が、電話を切ったことなのか、顧客の要件が解決したことなのかで、未対応件数は変わる。

電話番号は照合候補であり、確定キーではない

代表番号には複数担当者が紐づき、同じ担当者が携帯と会社番号を使う。番号変更や転送もある。着信番号だけで顧客を自動確定すると、別担当者や別案件へ通話が付く。

着信番号を整形し、完全一致する連絡先候補を出す。
候補が一つでも、進行中案件と通話要件を確認する。
複数候補なら、会社・担当者・案件を担当者が選ぶ。
候補がなければ未特定通話として保存し、新規登録とは分ける。
確定後も原番号と候補結果を残し、誤結合を訂正できるようにする。

会社名の表記揺れや同一会社の重複があると、この照合も安定しない。行の名寄せは顧客DBの重複行を直す設計が参考になる。

要件・結果・次回行動を分ける

通話要約だけでは、一覧で何が止まっているか分からない。要件は相手が求めていること、結果は通話中に決まったこと、次回行動は自社または相手が次にすることだ。三つを別項目にする。

要件：見積依頼、納期確認、変更希望、問い合わせなど
結果：回答済み、確認持帰り、担当変更、対応不要など
次回行動：見積送付、社内確認、折返し、資料受領など
期限：次回行動をいつまでに終えるか
担当：通話した人ではなく、次回行動を完了する人

一回の通話から複数の行動が生まれる場合は、通話に複数タスクを結ぶ。次回行動を通話レコードの一つの欄へ上書きすると、先に終えた行動で全体が完了に見える。

同意状態は録音ファイルと分けて持つ

録音、文字起こし、要約、教育利用は同じ処理ではない。自社が採る案内や確認の運用に合わせて、何を案内し、どの利用を認め、いつ確認したかを項目として持つ。法的判断をシステムの真偽値だけに置き換えず、社内の担当部門や専門家が決めたルールをデータへ反映する。

項目	記録する内容	利用時の確認
案内状態	未確認・案内済み・対象外	通話ごとの運用
利用範囲	記録、要約、共有など社内定義	目的外利用をしない
確認時点	日時、担当、根拠となる案内	後から追跡可能にする
保存状態	保存中、削除依頼中、削除済み	録音とCRMを対応させる

連携エラーを未対応通話として見える化する

連携が失敗した通話をログだけへ置くと、顧客対応の漏れになる。通話IDを基準に、CTI受信、CRM活動作成、相手関連付け、次回行動作成の各状態を持ち、途中で止まったものを業務担当が見られるキューへ出す。

重複する通話IDは新規作成せず、既存レコードを確認する
相手未特定でも通話活動自体は失わない
必須項目が不足したら、補完担当と期限を設定する
再実行した日時と結果を履歴に残す
録音がなくても、要件と次回行動は別に処理できるようにする

次回行動の完了条件を行動別に決める

「折返し」「確認」「資料送付」のような行動名だけでは、担当者ごとに完了の意味が変わる。折返しは電話をかけた時点か、相手と話せた時点か。資料送付は送信時点か、相手が受領した時点か。行動種別ごとに完了条件と、未完了時の次の状態を決める。

行動	完了条件	完了できない場合
折返し	会話結果と次の予定を記録	不通理由と再連絡日を設定
社内確認	決定者と回答内容を記録	判断待ちとして決定者へ渡す
資料送付	送付物・宛先・送付日時を記録	不足情報の取得へ戻す
相手回答待ち	回答内容を案件へ反映	確認予定日を再設定

完了条件が決まると、管理者は通話件数ではなく、止まっている次回行動を見られる。担当変更時も、最後の通話メモを読み解くのではなく、未完了タスクから再開できる。

週次のデータ品質レビューを少数項目に絞る

入力率だけを上げるために必須項目を増やすと、仮の値や意味のない選択が増える。週次では業務が止まる欠損を優先し、原因と修正先を見る。

相手・案件が未特定のまま残る通話
要件はあるが次回行動または担当がない通話
期限を過ぎても完了・延期の更新がないタスク
同じ通話IDまたは同じ録音を持つ重複活動
同意状態と録音・要約の利用状態が矛盾する記録

欠損を担当者へ返すだけで終わらせず、連携変換、候補照合、画面入力、運用ルールのどこで発生したかを分類する。同じ欠損が続くなら、個人の注意ではなくデータ辞書か処理を直す。

受入テストは実際の通話シナリオで行う

正常な新規問い合わせだけでテストしない。代表番号、既存顧客の別番号、複数案件を持つ相手、転送、折返し、相手未特定、次回行動が複数ある通話を通す。画面へ記録が出たことではなく、別担当者が一覧から案件を選び、期限内に続きの対応ができるかを確認する。

効果は録音数や要約数では測らない。相手未特定のまま残る通話、次回行動が空欄の通話、期限超過、同一通話の重複、管理職への確認往復が減ったかを見る。CTIとCRMの連携は、電話を保存する機能ではなく、通話後の判断と実行を引き継ぐ仕組みだ。

運用開始後に項目を増やしたくなったら、その項目を見て誰が何を決めるかを先に書く。検索にも集計にも引き継ぎにも使わない項目は、通話メモへ残すだけで足りる。入力欄を増やすより、要件・結果・次回行動の定義をそろえるほうが、対応漏れを減らしやすい。

また、自動要約の内容をそのまま顧客や案件の確定情報へ上書きしない。担当者が通話原文または録音を確認し、確定させた項目と要約原文を分ける。誤りが見つかったとき、どの確定情報を訂正すべきか追える状態を保つ。