売買仲介で内見を終えた購入検討客の動きを毎日追い、連絡が止まった客に次の物件の提案とフォロー連絡の下書きを作る

処理の起点を決める

毎朝7時に、Schedule by Zapier の daily で動かします。 物件の一覧は毎朝6時台に更新が終わり、顧客管理には前日の連絡の記録が入っています。担当者が出社して最初に一覧を見られる時刻に、下書きがそろっている状態を作ります。

土日も動かし、定休日の水曜だけ止めます。 売買の購入検討客は、平日に勤めていて土日に連絡を返してくることが多く、土日の朝こそ下書きが要ります。 Schedule by Zapier には土日に動かすかどうかの設定（Trigger on weekends?）があるので、これを動かす側にし、水曜はトリガーの直後に置いた Filter で止めます。

時刻は Zapier アカウントのタイムゾーンに従い、指定した分きっかりに動く保証はありません。 指定時刻から数分以内に動く、という仕様です。最終連絡からの日数を「実行した時刻」から数えると、日付をまたいだときに1日ずれます。 判定の基準日をトリガーの日付から作り、以降の計算はすべてその日付で行います。

入力データを集める

質を決めるのは、内見の記録と連絡の履歴の「客側の宿題」です。 「事前審査の結果待ち」「自宅の査定を依頼中」と書かれていれば、AIは待っている客として扱えます。書かれていなければ、関心が離れた客と区別できません。 始める前に、内見のメモの書き方を「良かった点／合わなかった点／客側の宿題」の3行にそろえます。

名前、電話番号、メールアドレス、勤務先、年収は渡しません。 区分を付けるのにも物件を選ぶのにも要らないからです。客は顧客管理のIDで表し、下書きの宛名は後段のステップで差し込みます。

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

追客対象のシートは、顧客管理から毎晩書き出します。 顧客管理の画面から抜き出すのではなく、段階、最終連絡日、次回の連絡予定日の3つの列を毎晩シートに写し、日数の計算はシートの側で行います。 AIに日付の引き算をさせないためです。

顧客管理の記録と物件の一覧は、AIの「道具」として渡します。 AI by Zapier の道具には、Zapier につながるアプリのアクション（CRMの記録を探す、スプレッドシートに行を足す、など）と、ナレッジの2種類があります。この構成で登録するのは、記録を探すアクションと行を検索するアクションだけです。 書き込むアクションは登録しません。

道具ごとに「実行前に承認を求める」設定があります。 作成・更新・削除のような扱いに注意が要る道具はオンにし、読むだけの道具はオフにする、というのが Zapier の案内です。この構成では道具がすべて読むだけなので、承認はオフのまま動かせます。 運用の途中で書き込みの道具を足したくなったら、その道具だけ承認をオンにしてください。オンにすると実行が止まり、メールの通知、Zap の画面の「Delayed」表示、Activity の「1 action needs your approval」で承認を求められます。

ナレッジには、追客のルールを書いた社内の文書を1つだけつなぎます。 Google ドライブや Microsoft SharePoint などをつなげ、同期は96,000語までです。毎日変わる物件や記録は道具で引き、変わらないルールだけをナレッジにします。

AIへ渡す前に整形する

1. 対象の客の抜き出し … 内見済み・未申込で、最終連絡からの日数が段階ごとの基準を超えた客を取ります。基準は「客側の宿題あり」が14日、「条件の見直し中」が10日、「宿題なし」が7日、のように段階で変えます
2. 除外の適用 … 断りの意思を示した客、連絡を望まないと言った客、他社で決めた客、申込済みの客を外します。この除外はAIに任せず、シートの列で機械的に行います
3. 次回の連絡予定日の確認 … 担当者が予定日を入れていて、その日がまだ来ていない客は外します。担当者が自分で決めた予定を、AIが追い越さないためです
4. 基準日の固定 … トリガーの日付から基準日を作り、すべての日数をその日付で数えます

2番目をAIにさせないことが大事です。 「もう連絡しないでください」と言った客を、AIが「関心が離れた客」と読んで物件を出す下書きを作ると、下書きの段階でも事故の元になります。

3番目は、担当者の判断を優先する仕組みです。 「年明けに改めて連絡します」と約束した客に12月に下書きが出ると、毎朝それを消す作業が生まれます。

AIに処理させる

客1人ごとに、次の4つをさせます。

（1）必要な記録を引く

どの記録を引くかはAIが決めますが、引いた記録は必ず根拠として書き出させます。 根拠の無い区分は、担当者が確かめようがありません。

（2）止まっている理由の区分を付ける

waiting_customer_task を区分として置いたことが、この構成のいちばんの工夫です。 事前審査の結果を待っている客に新しい物件を3件送ると、「こちらの事情を分かっていない」と受け取られます。待っている客には、待っていることを踏まえた一言を送ります。

no_reason_recorded には物件を出させません。 理由が分からないまま物件を出すと、第3章の（c）のずれをAIが再現するだけです。

（3）次に出す物件を選ぶ

物件の一覧から、販売中で、内見済み・紹介済みでなく、合わなかった点を満たすものを最大3件選ばせます。物件ごとに、合わなかった点のどれを満たすのかを1文で書かせます。

（4）連絡の下書きと次回の連絡日の案を作る

区分ごとの方向に沿って下書きを作らせます。催促や値引きの約束に読める表現は書かせません。 次回の連絡日は、区分と追客のルールから案を出させ、決めるのは担当者です。

指示内容を固定する

あなたは住宅の売買仲介会社で、内見を終えた購入検討客への
フォロー連絡を準備する担当者の補佐です。
下の客について、使える道具で必要な記録を引き、
止まっている理由の区分、次に出す物件、連絡の下書きを作ってください。

【使える道具】
- 顧客管理の記録を引く（反響、内見、連絡の履歴）
- 物件の一覧を検索する（販売状況、価格、前回の価格、条件）
- 追客のルール（ナレッジ）

【進め方】
1. まず連絡の履歴と内見の記録を引き、客側の宿題と、合わなかった点を確かめる
2. 合わなかった点か価格の記載があるときだけ、物件の一覧を検索する
3. 区分を決め、その根拠にした記録の文をそのまま写す
4. 区分に合う下書きを作る

【区分】次の5つのいずれか。これ以外を作らないでください。
waiting_customer_task / condition_mismatch / price_changed /
no_reason_recorded / undetermined

【厳守事項】
- 記録に書かれていないことを推測で補わないでください。
  「事前審査に通らなかったのだろう」「他社で決めたのだろう」と書かないでください。
  記載がなければ「不明」としてください。
- 最終連絡からの日数を自分で計算しないでください。
  下に与えた日数の値をそのまま使ってください。
- 物件は、物件の一覧で販売状況が「販売中」のものだけを出してください。
  内見済み・紹介済みの物件ID（下に与えます）は出さないでください。
- 物件は最大3件。物件ごとに、合わなかった点のどれを満たすかを1文で書いてください。
  満たす点を書けない物件は出さないでください。
- 区分が no_reason_recorded のときは、物件を出さないでください。
- 根拠を写せない区分は undetermined にしてください。
- 下書きに、値引きの約束、「今だけ」「早く決めないと」のような
  急かす表現、他の客の検討状況を書かないでください。
- 下書きに、客の年収、勤務先、ローンの審査結果の推測を書かないでください。
- 客の名前は書かず、宛名は「{宛名}」のままにしてください。
- 下書きは300字以内、です・ます調にしてください。

【基準日】{base_date}
【客ID】{customer_id}　【担当者】{agent_name}
【段階】{stage}　【最終連絡からの日数】{days_since_contact}
【内見済み・紹介済みの物件ID】{excluded_property_ids}

「日数を自分で計算しない」を必ず入れます。 計算を任せると、定休日や基準日の扱いが客ごとに変わります。数えるのはシート、判断するのがAIという分担を崩さないためです。

「満たす点を書けない物件は出さない」は、第3章の（c）への対策です。 理由を書かせずに選ばせると、価格帯だけで選んだ物件が並びます。

出力形式を固定する

AI by Zapier の出力項目として、次の項目を定義します。

{
  "base_date": "",
  "customer_id": "",
  "category": "waiting_customer_task | condition_mismatch | price_changed | no_reason_recorded | undetermined",
  "evidence": [
    { "source": "contact_log | viewing_note | property_list", "date": "", "quote": "" }
  ],
  "customer_task": { "content": "", "expected_by": "" },
  "proposals": [
    { "property_id": "", "status": "", "price": 0, "previous_price": 0, "reason": "" }
  ],
  "draft_subject": "",
  "draft_body": "",
  "next_contact_suggestion": "",
  "needs_human": { "value": false, "reason": "" }
}

構造化する理由は、後段で決まった手順に分けるからです。 category が文章に埋もれていると、確認一覧で区分ごとに並べられません。proposals が項目として分かれていれば、物件IDが一覧にあって販売中かを Filter で確かめられます。

evidence の quote には、記録の文をそのまま写させます。 担当者は一覧の上でこの1文を読めば、区分が妥当かをすぐ判断できます。根拠がないと、結局顧客管理を開き直すことになり、工数が減りません。

出力項目が定義されていないと、AI by Zapier はまとめた1つの出力を返します。 後段のステップで項目ごとに使うので、出力項目は必ず定義します。 プロンプトから出力項目を自動で作る機能もありますが、名前と種類は手で確かめて固定します。

システムへ連携する

AIのステップのあとに Filter を置き、提案された物件IDを物件の一覧で引き直します。 販売状況が商談中か成約済みなら、その物件を下書きから外して needs_human を立てます。

Gmail には下書きを作るだけで、送信のアクションは置きません。 下書きは担当者の受信箱に入り、担当者が開いて直して送ります。送信のアクションを Zap に入れないことで、設定の誤りで客にメールが飛ぶ経路そのものを無くします。

顧客管理への書き戻しはしません。 区分や下書きの記録は確認一覧に残し、顧客管理には担当者が連絡の結果を書きます。顧客管理にAIの推測が混ざると、次の判定の材料が汚れるからです。

人が確認する

担当者が、その朝の確認一覧を必ず見ます。 下書きは担当者が開かない限り客に届かないので、確認を省くと単に何も起きません。

電話に切り替える判断も、ここで行います。 下書きは「何を尋ねるか」のメモとしても使えます。

一覧は担当者ごとに分け、undetermined と price_changed を上に置きます。 同じ客について前回出した区分と連絡の結果を横に並べると、先週尋ねたことを今週また尋ねる下書きにすぐ気づけます。

例外に対処する

いちばん大事なのは、断りの記録の扱いです。 断りを示した客への下書きは、送らなければ実害は無いように見えますが、担当者が忙しい朝に流れで送ってしまう危険があります。 除外の列は、この構成でいちばん先に整える列です。

失敗した客は確認一覧に「失敗」として1行残し、翌朝の対象に戻します。

記録を残す

• 基準日、対象の客、区分、根拠の1文、提案した物件、下書きの本文（確認一覧）
• 担当者が下書きを送ったか、直したか、送らなかったか、電話に切り替えたか
• 担当者が区分を変えた事例と、その理由
• 提案した物件への客の反応（内見の申込、問い合わせ、反応なし）
• AIのステップがどの道具を何回呼んだか（Zap の実行履歴）
• undetermined の件数と、原因の内訳

AI by Zapier は実行のたびに知識がリセットされ、前回を覚えていません。 前回の区分や連絡の結果を踏まえさせるには、確認一覧の記録を次回の入力として渡します。

3つ目の「担当者が区分を変えた事例」が、いちばん役に立つ記録です。 no_reason_recorded を waiting_customer_task に直したなら、宿題が記録に書かれていなかったということで、内見のメモの書き方を直す材料になります。