保険の見積り・資料請求のあとの面談記録と通話メモを要約し、次回のフォロー連絡の案と期日付きのタスクを顧客管理に登録する

処理の起点を決める

募集人が HubSpot に面談または通話のメモを残したことを起点にします。 トリガーは HubSpot の New Engagement です。メモ、通話、面談などの記録が入ったときに動くので、募集人の手順は何も変わりません。 別の入力画面を作ると、そちらに書かない人が必ず出ます。

動かす対象は、新規の見込み客の記録だけに絞ります。 既存の契約者への連絡や、事故の受付の記録にまで動くと、関係のない承認の依頼が募集人に届きます。絞る材料は連絡先の「ライフサイクルステージ」で、見込み客の段階にある連絡先の記録だけを先へ進めます。 判定は次の Get Contact のあとに Paths で行います。

記録の種類も見ます。 メールの自動記録や、営業管理が付けた社内の申し送りのメモでは動かしません。募集人が顧客と話した記録だけが対象です。 種類を見分けられるように、面談と通話のメモの冒頭に「【面談】」「【通話】」と書く決まりを1つだけ足します。

1日1回まとめて動かす形にはしません。 翌朝にまとめて届くと、承認は中身を読まずに通されます。

入力データを集める

質を決めるのは、「経緯の要約」のプロパティです。 過去のメモを毎回すべて読ませるのではなく、前回までの要約と今回のメモだけを渡し、要約を更新させます。 接点が5回、6回と増えても、AIに渡す量は増えません。承認された要約だけが書き戻されるので、要約はいつも人が一度確かめたものです。

データの取得方法を決める

トリガーが返すのは記録そのものなので、連絡先の情報は別に取ります。 記録に関連付いた連絡先のIDで Get Contact を呼び、必要なプロパティを取り出します。関連付けが無い記録（連絡先を選ばずに残したメモ）は、ここで止めて募集人に知らせます。

期日の計算は Formatter の Date / Time で行います。 Add/Subtract Time は、日付に「+3 days」のような式で日数を足せます。AIが返した連絡の種類を Paths で分け、種類ごとに決めた日数を足します。 当日の日付は Zapier の変数で入れられます。

AIへ渡す前に整形する

1. 対象の絞り込み … ライフサイクルステージが見込み客の段階で、メモの冒頭に「【面談】」「【通話】」があるものだけを進めます
2. 連絡停止の確認 … 連絡停止の印があれば、AIに渡さずに終了します
3. 関連付けの確認 … 連絡先が関連付いていない記録は、募集人に「連絡先を選んで記録し直してください」と知らせて止めます
4. 定型文の除去 … メモの末尾に付く署名や、テンプレートの見出しだけの行を落とします
5. 健康状態の記述の扱い … 医療保険の見込み客のメモには、持病や通院の話が書かれることがあります。AIには渡しますが、要約と文案に写さないよう指示で禁じ、言及があったことだけを印で返させます
6. 長さの確認 … 会話の書き起こしを貼った長いメモは、そのまま渡します。分割はしません。 分けると、顧客の言葉と約束が別々の塊に入ります

5番目を軽く見ないでください。 病歴は個人情報のなかでも扱いに特に注意が要る情報です。経緯の要約は連絡先のプロパティとして、ほかの募集人や営業管理の目にも触れます。 告知に関わる話は告知書や申込の手続きで扱うもので、フォローのための要約に残すものではありません。

AIに処理させる

させるのは、今回のメモを読んで経緯の要約を更新し、顧客の言葉と約束を写し出し、次回の連絡の種類を選んで文案を作ることです。

右端の列の「迷ったら true」が、この構成でいちばん大事な扱いです。 断りのサインを見落とすと、断った人に電話をかける準備が整います。逆に、断っていない人を true にしても、募集人が承認の画面で外せば済みます。 誤りの重さが違うので、迷ったほうへ倒す向きを決めておきます。

4行目がいちばん起きやすい失敗です。 メモに「月額4,280円の見積りを説明」と書いてあると、AIは親切に文案に「先日ご案内した月額4,280円のプランについて」と入れます。見積りの条件が変わっていたら、その数字は誤った案内になります。 金額は見積りの書面を見てもらう形にします。

指示内容を固定する

AI by Zapier の指示文の欄に次の内容を書き、入力の項目に今回のメモ・経緯の要約・見積りの対象・連絡の希望を割り当てます。

あなたは保険代理店の営業を補助する立場です。
見込み客との面談・通話のメモと、これまでの経緯の要約を読み、
次の項目を返してください。メモに書かれていることだけを使ってください。

【返す項目】
- summary：これまでの経緯の要約に今回の接点を足した文章（300字以内）
- customer_words：顧客が時期・条件・懸念を述べた一文。メモの文面のまま
- our_promises：募集人が送る・調べると約束したこと。メモの文面のまま
- next_action：次のどれか1つ
  doc_check（資料の到着確認）／quote_explain（見積りの説明）／
  comparison（比較表の送付）／customer_timing（顧客が時期を指定）／
  wait（顧客からの連絡を待つ）／other
- draft：次回の連絡の文案
- decline_signal：true または false
- health_mentioned：true または false
- conflict：前回の要約と今回のメモで食い違う点

【厳守事項】
- customer_words と our_promises は、メモの文面をそのまま写してください。
  要約したり、言い換えたりしないでください。
- 期日や日付を書かないでください。「来月」「車検のあと」を具体的な日付に直さないでください。
- 顧客が時期を口にしていれば next_action を customer_timing にしてください。
- 「結構です」「今回は見送ります」「こちらから連絡します」「家族と相談します」など、
  断りや保留を示す言葉があれば decline_signal を true にしてください。迷ったら true です。
- decline_signal が true のときは draft を空欄にしてください。
- 持病・通院・服薬・健康診断の結果など健康状態の話があれば、health_mentioned を true にし、
  その内容を summary にも draft にも書かないでください。
- 保険料・補償の金額・特約の内容を draft に書かないでください。
  「お送りした見積書をご覧ください」と書いてください。
- どの商品を勧めるかを書かないでください。
- 連絡の希望が email なら draft はメール本文、phone なら電話で話す要点を3つまでの箇条書きにしてください。
- 書かれていない項目は空欄にしてください。「特になし」と書かないでください。

【今回のメモ】{note_body}
【これまでの経緯の要約】{summary_so_far}
【見積り・資料請求の対象】{product_line}
【連絡の希望】{contact_pref}

「日付に直さない」を明記しないと、AIは親切に期日を書きます。 記録日が9月29日で顧客が「来月」と言っていれば、「10月中旬ごろ」と書き添えようとします。禁じるのは、日付を作ることそのものです。

「迷ったら true」を書くのも同じ理由です。 「家族と相談します」は、保留とも前向きな検討とも読めます。何も言わなければAIは前向きに読み、文案を作ります。 募集人に判断させる側へ倒しておきます。

出力形式を固定する

AI by Zapier の出力の項目として、次の形で受け取ります。 出力の項目は名前・型・説明で決めておき、後ろのステップで1つずつ使います。

{
  "summary": "",
  "customer_words": "",
  "our_promises": "",
  "next_action": "doc_check | quote_explain | comparison | customer_timing | wait | other",
  "draft": "",
  "decline_signal": false,
  "health_mentioned": false,
  "conflict": ""
}

1つ目の理由は、next_action を決まった値にできることです。 自由文で「比較表を送る」と返されると、Paths の条件で日数を分けられません。値を6つに固定し、それぞれに日数の表の1行を対応させます。 other は期日の案を空欄にして、募集人に入れてもらいます。

2つ目は、customer_words と summary を別の欄にできることです。 承認の画面で、要約の横に顧客の言葉の原文が並びます。要約が顧客の言葉をねじ曲げていないかを、1行で確かめられます。

3つ目は、decline_signal と health_mentioned を条件に使えることです。

システムへ連携する

タスクは Create Engagement で作ります。 記録の種類を選んで連絡先に関連付けるアクションで、タスクの件名に連絡の種類、本文に文案と顧客の言葉を入れます。 担当者は記録を残した募集人です。

日付の渡し方に注意が要ります。 Zapier のヘルプでは、HubSpot は日付を UNIX タイムスタンプで受け取り、Zapier から送った日付と時刻は UTC の午前0時に切り捨てられるとされています。日本時間の午前0時のつもりで送ると、UTCでは前日の15時になり、切り捨てで期日が1日早まるおそれがあります。 期日に正午を足して送り、テストで画面上の日付を確かめます。

経緯の要約の書き戻しは Update Contact で行います。 書き戻すのは承認の画面で直した後の要約です。AIが最初に返した要約は、ログには残しますが顧客管理には入れません。

人が確認する

承認の依頼は、メモを残した募集人本人に Slack で届けます。 Request Approval は通知の先に Slack を選べ、承認の画面で内容を直せる設定にできます。

1. 顧客の言葉と要約を見比べる … 要約が顧客の言葉と違う意味になっていないかを確かめます
2. 約束を確かめる … our_promises に抜けがないか。自分が言ったことは自分がいちばん覚えています
3. 期日を決める … 案のままでよいか。顧客が時期を言っていれば日付を入れます
4. 文案を直す … そのまま使える形になっているかを見ます。送るのは期日の日です
5. 断りのサインがあれば … 連絡停止の印を付けるかを決めます。付けるのは募集人です

承認されないまま放っておかれたときの扱いを決めます。 Request Approval にはタイムアウトを設定でき、期限が来たら「そのまま続ける」か「実行を終える」かを選べます。この構成では「実行を終える」を選びます。 誰も確かめていないタスクと要約を顧客管理に入れないためです。終わったものは営業管理に一覧で知らせます。

レビュー担当者は Zapier のアカウントを持つ必要があります。 募集人12名それぞれに承認を届けるには、アカウントのメンバーに加える必要があり、Team 以上のプランを前提にします。 Professional のプランでは、承認の依頼を自分自身にしか送れないとされています。

例外に対処する

上から3行目が、いちばん気をつけるところです。 断りのサインがあったのに文案が作られると、担当者は迷わず連絡します。文案を作らないことそのものが、連絡を止める仕組みになります。

記録を残す

• 今回のメモの本文と記録日時、トリガーが拾った日時
• AI by Zapier が最初に返した出力の全項目
• 承認の画面で募集人が直した後の値と、直した項目
• 承認・却下・タイムアウトの結果と、その日時
• 登録したタスクの期日と、書き戻した経緯の要約
• decline_signal が true になった件と、連絡停止の印を付けたかどうか

3つ目は、指示文を直す材料です。 募集人が毎回同じ項目を直しているなら、直すべきは指示文です。

最後の行は、勧誘の運用を確かめる記録になります。 断りのサインを検知したのに連絡停止にしなかった件が続く募集人がいれば、営業管理が理由を聞けます。