会話から拾うのは、要望・次の約束・未確認
商談例:Meetでの発言
新築注文住宅の集客を強化したいです。見積もりは社内で検討し、次回の打ち合わせでレビューしましょう。
議事録から拾う情報 | 更新案 |
|---|---|
顧客の要望 | 新築注文住宅の集客を強化したい |
次のアクション | 次回の打ち合わせで見積もりをレビュー |
未確認の情報 | 予算と決裁者 |
会話にない予算や決裁者は、推測で埋めず「未確認」に分けます。担当者は議事録を読み直して入力する代わりに、この案を確認します。
Difyで「生成」と「反映」を分ける
更新案の生成とSalesforceへの反映を人の承認で分ける。差し戻した案は送信しない。
接続図を読み込み中です。
- 文字起こしを渡す
対象の商談IDと一緒に入力
次へ:更新案をつくる
- 更新案をつくる
要望・約束・未確認を分ける
次へ:担当者が承認
- 担当者が承認
更新先の商談、変更前後の値、根拠の発言を担当者が確認する。差し戻し時は反映しない。
次へ:Salesforceを更新(承認した場合のみ)
- Salesforceを更新
承認済みの項目だけ反映
商談IDは入力時に指定し、承認した案を同じレコードに反映します。生成した文章が正しくても、更新先を誤れば意味がないためです。
承認画面には変更前の値と更新案を並べ、各案から根拠の発言へ戻れるようにします。担当者は商談IDと内容を確認し、修正・差し戻し・承認を選びます。差し戻した案はSalesforceへ送らず、承認した項目だけを反映します。
自社で試す前に確認する3点
最初は商談を1件に絞り、次の条件をそろえます。
- Meetの文字起こしを取得できる設定と権限
- Salesforceの対象商談ID、更新項目、API権限
- 商談データをAIで扱う際の社内ルール
更新案の修正量とSalesforceへの反映結果を見れば、次に広げる範囲を決められます。
判定は二つです。指定した商談の対象項目だけが更新されたか、担当者が根拠を見て承認できたか。誤更新や根拠不明の修正が起きたら、連携範囲を広げずに入力と抽出ルールを見直します。




