賃貸の内見後に申込に至っていない客を毎週洗い出し、申込に近い順と次に出す物件・連絡の案をまとめる

処理の起点を決める

毎週月曜の6時に、社内のサーバーで Python のスクリプトを定時で動かします。 曜日を月曜にするのは、土日の内見の結果が顧客管理に書き終わっていることと、週の初めに連絡の計画を立てられることの両方のためです。

処理は2つに分けます。6時の処理でバッチを投げ、7時半の処理で結果を取りに行きます。 7時半の時点で終わっていなければ、30分おきに取りに行きます。店舗が開く10時までに一覧がそろわない場合は、前週の一覧に「今週分は未作成」と書いて通知します。

繁忙期（1月から3月）は、週2回に増やします。 物件が数日で埋まる時期は、週1回では候補の物件の多くが翌週には無くなっています。月曜と木曜の2回にし、木曜は段階AとBの客だけを見直します。

入力データを集める

質を決めるのは、内見の記録です。 「気に入っていた」だけのメモからは、決め手を欠いた点が取れません。この構成を始める前に、内見のメモに「良かった点」「気になった点」「次に見たい条件」の3つを書くように、店舗でそろえます。書き方をそろえるだけで、AIを使わなくても見直しが速くなります。

名前、電話番号、メールアドレスは渡しません。 段階を付けるのにも、物件を選ぶのにも要らないからです。客は顧客管理のIDで表し、一覧を作る段階で名前に戻します。

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

顧客管理から取れる形は、製品によって違います。 APIがある製品ならAPIで、無ければ画面からCSVを書き出す形になります。CSVの書き出しが手作業なら、月曜の6時の前に担当者の1人が書き出して所定のフォルダに置く運用にし、スクリプトはそのファイルを読みます。この部分は利用している顧客管理に応じた個別対応が必要です。

前週の一覧も入力にします。 先週「段階A」だった客が今週も未申込なら、先週の連絡が届いたか、返事があったかを見て、段階を付け直す必要があります。

AIへ渡す前に整形する

1. 対象から外す … 顧客管理に「断り」「他社で決定」「連絡不要」の印がある客、最後の内見から45日を過ぎた客を外します
2. 連絡の履歴を読んで外す … 客からの返事に「もう探していない」「連絡は結構です」にあたる文があれば、AIに渡さず担当者の確認に回します
3. 記録をまとめる … 1人分の記録を、反響、内見、連絡の順に日付で並べ、1つの文書にします
4. 候補の物件を絞る … 空室の一覧から、エリア、賃料の上限（1万円の幅まで）、間取りで絞り、内見済みと紹介済みの物件を除いて10件までにします
5. 重複をまとめる … 同じ客が別の店舗やポータルから二重に反響していれば、1人にまとめます
6. custom_id を付ける … バッチの要求ごとに、客IDと週の日付から作った識別子を付けます（英数字・ハイフン・アンダースコアで64文字まで）

2番目を、AIより前の段階に置くのは意図してのことです。 断りの意思を示した客にAIが連絡の案を作ると、案が一覧に載った時点で、誰かが送ってしまう危険があります。 宅地建物取引業法施行規則では、相手方が契約を締結しない旨の意思（勧誘を引き続き受けることを希望しない旨の意思を含む）を表示したにもかかわらず勧誘を継続することが禁止されています。案を作らないのが、いちばん確実な止め方です。

4番目で候補を絞るのは、AIに物件を探させないためです。 空室の一覧を丸ごと渡すと、AIは条件から外れた物件を「おすすめ」として出すことがあります。条件に合う物件を選ぶのは Python、その中から決め手を欠いた点に合うものを選ぶのが AI、と分けます。

AIに処理させる

させるのは、記録を読んで段階を付け、その根拠を書き出し、決め手を欠いた点に合う物件を候補の中から選ぶことです。

段階の決め方は、指示文に基準として書きます。

「予測」といっても、確率の数字は出させません。 記録の量が客ごとにばらばらで、数字にしても根拠が説明できないからです。出させるのは、基準に照らした段階と、その根拠の一文です。 段階が申込とどれくらい結びつくかは、第7章の保存・ログで数えます。

3行目は、指示で明示します。 世帯の人数は物件の広さを選ぶために渡していますが、それを「申込に近いかどうか」の材料にさせません。 段階の根拠は、客が内見で言ったことと、連絡への返事だけにします。

指示内容を固定する

あなたは賃貸仲介の店舗で、内見のあと申込に至っていない客の記録を見直す担当です。
下の【記録】だけを根拠にしてください。記録にないことを推測しないでください。

【やること】
1. 段階を A / B / C / D のどれかにしてください。基準は【段階の基準】のとおりです。
2. 段階の根拠にした記録の一文を、evidence にそのまま写してください。
   根拠の一文を写せない場合は、段階を D にしてください。
3. 客が内見した物件で「気になった点」を blocking_factors に並べてください。
   記録に書かれていない点を足さないでください。書かれていなければ空の配列にしてください。
4. 【候補の物件】の中から、気になった点を解消する物件を3件まで選び、
   どの点を解消するかを reason に書いてください。候補に無い物件を出さないでください。
   合う物件が無ければ空の配列にしてください。
5. 連絡の案を作ってください。手段は記録で客が返事をしてきた手段に合わせてください。
   文の最初に、会社名と担当者名を名乗る一文を入れてください。
   1回の連絡で伝えることは1つか2つにしてください。

【厳守事項】
- 段階の根拠に、年齢、性別、家族構成、国籍、職業を使わないでください。
- 客からの返事に、探すのをやめた、連絡は要らない、という趣旨の文があれば、
  stage を D、stop_contact を true にし、連絡の案を作らないでください。
- 賃料の値下げ、初期費用の免除など、物件の条件を変える約束を連絡の案に書かないでください。
- 物件が「まだ空いている」と断定する表現を使わないでください。
- 確率や点数を書かないでください。

【段階の基準】{stage_rules}
【記録】{customer_record}
【候補の物件】{candidate_properties}
【前週の段階と結果】{last_week}

「根拠の一文を写せなければD」が、この指示の要です。 これが無いと、記録が乏しい客にも「内見の反応が良かったため」とそれらしい根拠を作ってAを付けます。写す一文が無いことを、判断できないことの印にします。

「空いていると断定しない」は、空室の一覧の遅れのためです。 他社管理の物件は、一覧にあっても申込が入っていることがあります。連絡の案では「ご案内できるか確認してご連絡します」の形にさせます。

出力形式を固定する

客1人ごとに、次の形のJSONで受け取ります。

{
  "customer_id": "",
  "stage": "A | B | C | D",
  "evidence": [ { "date": "", "source": "viewing_note | contact_log | inquiry", "text": "" } ],
  "blocking_factors": [ "sunlight", "rent", "station_distance" ],
  "recommended_properties": [ { "property_id": "", "reason": "" } ],
  "contact_plan": {
    "channel": "email | sms | phone",
    "timing": "today | this_week | next_week",
    "points": [ "" ],
    "draft": ""
  },
  "stop_contact": false,
  "needs_human_reason": ""
}

1つ目の理由は、evidence を記録の日付と出どころ付きで返させられることです。 担当者は一覧で段階の横に根拠の一文を読み、顧客管理を開かずに段階の妥当性を判断できます。

2つ目は、recommended_properties を Python で検査できることです。 返ってきた property_id が候補の10件にあるかを機械的に照らし、無ければその行を落とします。 自由文で物件名を書かせると、この照合ができません。

3つ目は、stop_contact で一覧から外す処理を決められることです。 true のものは担当者の一覧に「連絡しない理由の確認」として別に出し、連絡の案の欄には何も出しません。

構造化出力には、スキーマに沿わない応答になる場合があります。 安全上の理由で拒否した場合は stop_reason が refusal になり、max_tokens の上限で切れた場合は stop_reason が max_tokens になって、出力が不完全になることがあります。 どちらも例外処理で扱います。また、列挙した値の大文字・小文字は保証されないので、段階の値は大文字にそろえてから比べます。

システムへ連携する

バッチの結果は、投げた順には返りません。 結果の並びは要求の順と一致しないことがあるので、必ず custom_id で客と結び付けます。 結果の種類は succeeded、errored、canceled、expired の4つで、succeeded 以外は課金されません。 errored と expired の客は、次の処理で1人ずつ投げ直します。

一覧の並べ方は、Python が決めます。 段階の順（A→B→C→D）、同じ段階の中では入居の希望時期が近い順、その次に内見からの日数が短い順です。AIに順番そのものを付けさせないのは、客どうしを比べる材料をAIに渡していないからです。 1人ずつ別の要求で見ているので、並べるのは後段の仕事です。

顧客管理には書き込みません。 段階は一覧にだけ載せ、担当者が連絡した結果を顧客管理に書きます。 段階をそのまま顧客管理に書くと、AIの見立てが客の記録として残ってしまいます。

人が確認する

担当者は月曜の朝、自分のシートを上から読みます。 1人15人前後の一覧です。

1. 段階Aの根拠を読む … 根拠の一文が本当にAの基準に当たるかを確かめます。当たらなければ段階を直し、直したことを残します
2. 次の物件を確かめる … 他社管理の物件は、連絡の前に空きを掲載元へ確かめます
3. 連絡の案を直して送る … 手段と時間を決め、文を直してから自分で送ります
4. stop_contact の客を確かめる … 本当に断りの意思なのか、単に忙しいという意味なのかを記録で確かめます。迷ったら連絡しません
5. 結果を顧客管理に書く … 連絡した、返事があった、内見を再設定した、申込に至った

2番目を省かないでください。 空いていない物件を案内すると、客の信頼をいちばん早く失います。 自社管理の物件は一覧で足りますが、他社管理の物件は必ず確かめます。

電話をかけるときは時間帯に気をつけます。 施行規則では、迷惑を覚えさせるような時間の電話又は訪問による勧誘も禁止されています。連絡の案の channel が phone でも、かける時間は担当者が決めます。

目標は、1人3分です。 根拠を読むのに1分、物件と案を直すのに2分という想定で、記録の読み返しと物件探しは、一覧の中で終わっています。

例外に対処する

上から2行目が、実は大事な情報です。 候補が0件の客は、希望条件と空室の実態が合っていない客です。条件を少し広げる相談をすれば、新しい内見につながります。「出す物件が無いから連絡しない」を防ぎます。

6行目の「別の経路で申込」は、店舗をまたぐと起きます。 顧客管理のステータスの反映が1日遅れるだけで、申込済みの客に「ほかの物件もいかがですか」と送ってしまいます。 前処理で外したうえで、担当者の目でも確かめます。

記録を残す

• 週ごとのバッチのID、投げた日時、結果を取った日時、custom_id と客IDの対応
• 客ごとに渡した記録と候補の物件、返ってきたJSONの全文
• Python が落とした行（候補に無い物件、埋まっていた物件）
• 担当者が段階を直した記録 … どの客を、何から何へ、理由
• 連絡したか、何を送ったか（顧客管理の記録から）
• 2週間後の結果 … 内見の再設定、申込、他決、連絡不要

最後の行で、段階が当たっていたかを数えます。 段階ごとに、2週間以内に申込に至った客の割合を出し、AとBで差が無ければ、基準の書き方を直します。 担当者が直した記録も合わせて見ると、どの基準で見立てがずれているかが分かります。

バッチの結果は、29日を過ぎると取れなくなります。 返ってきたJSONは、受け取った時点で自社の保管先に写します。