代理店に渡した見込み客のフォロー状況を追って、止まっているものを拾う

処理の起点を決める

平日の決まった時刻に、1日1回動かします。 Schedule by Zapier の daily を使い、"Trigger on weekends" を "No" にします。時刻は、担当者が出社して最初に見る時間の少し前に置きます。

毎日動かす理由は、件数を平準化するためです。 週に1回まとめて動かすと、その日だけ数十件が一度に上がってきます。毎日少しずつ上がってくる形にすれば、1日の確認は数件に収まります。

発火が数分ずれることを前提に設計してください。 Zapier は指定した分きっかりの発火を保証せず、指定時刻から数分以内に動きます。経過日数の計算を「実行時刻」から行うと、日付をまたいだときに1日ずれます。 判定の基準日を処理の中で明示的に持ち、その日付から数えてください。

手動で動かせる入口も用意してください。 判定の設定を変えた直後に、その場で流し直したくなります。

入力データを集める

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

配分の記録： CRMから、配分済みで成約にも失注にもなっていない案件を取得します。取得の条件を「更新日」にしないでください。 更新されない案件ほど拾いたいものなので、更新日で絞ると落ちます。配分日を基準に、期間で区切って取得します。

代理店からの報告： ここがこの構成でいちばん手間のかかる部分です。書式をそろえてもらうのは時間がかかるので、まず読み取り側で吸収します。 受け口は2つに絞ってください。

担当者個人のメールに報告が届いている状態では、そもそも材料が集まりません。 受け口を2つに絞るだけで、負担が変わります。

代理店台帳： この構成の精度を決めるのが台帳です。次の列を持たせます。

「営業日」の列が、誤判定をいちばん減らします。 水曜定休の代理店に、水曜を挟んだ経過日数で確認を出すと、相手からは事情を分かっていないように見えます。140社ぶんを一度に埋める必要はなく、配分件数の多い上位30社から埋めれば大半の案件が正しく数えられます。

「報告の頻度」の列も要ります。 月次で報告する代理店に、報告が10日来ていないことを理由に確認を出すのは筋が通りません。停滞と見なす日数は、報告頻度に合わせて変えてください。 週次なら10営業日、月次なら25営業日、といった形です。

自社側の接点の記録： マーケティングツールの記録は、見込み客の個人単位で残ります。CRMの lead_id と突き合わせるキーが要ります。 メールアドレスが共通のキーになりますが、突き合わせは社内で済ませ、AIへはキーと日付だけを渡す形にしてください。

接点は「あったかどうか」だけでなく、「何があったか」を持たせてください。 メールを1通開封しただけと、価格ページを3回見て再度資料請求したのとでは意味が違います。後者は、代理店の手元で動いている可能性が高い案件です。

営業日のカレンダー： 自社の休業日と、代理店ごとの休業日の2段構えで持ちます。経過日数の計算は、この2つを引いた日数で行います。

AIへ渡す前に整形する

1. 対象案件の抽出 … 配分済みで、成約・失注・配分取り消しのいずれにもなっていない案件を取り出します
2. 報告と案件の紐づけ … 報告の顧客名や案件番号を lead_id へ対応づけます。対応づかない報告は捨てずに別枠へ残します
3. 接点と案件の紐づけ … マーケティングツールの記録を lead_id へ対応づけます
4. 経過日数の計算 … 配分日、最終報告日、最終接触日から、基準日までの営業日数を計算します。数えるのは前処理、判断するのがAIです
5. 個人情報の分離 … 見込み客の氏名・連絡先・住所を取り除き、lead_id に置き換えます
6. 除外の適用 … 見込み客本人から連絡を断られている案件、代理店から辞退の申し出があった案件を外します

5の分離が、この構成のセキュリティ設計の核です。 停滞しているかどうかの判断に、見込み客の氏名は要りません。必要なのは、日付と区分と報告の記述だけです。

2で紐づかない報告は必ず出ます。 顧客名の表記ゆれ、社名だけの記載、複数案件をまとめた記述。これを黙って捨てると、報告しているのに停滞扱いされる案件が生まれます。 一覧に出し、人が対応づける導線を用意してください。

AIに処理させる

3つの処理をさせます。

（1）報告の読み取り

代理店ごとにばらばらな書式の報告から、案件ごとの状態を取り出します。

書かれていないことを補わせないでください。 「訪問した」とだけの報告から「提案済みと思われる」と読み取らせると、判定の根拠が崩れます。記載がなければ「不明」としてください。

（2）停滞の区分の判定

no_report_but_active を区分として置いたことが、この構成のいちばんの工夫です。 報告の不足と、営業の停滞を分けられます。報告が来ていないだけで見込み客が自社サイトへ戻ってきているなら、代理店は動いている可能性が高い。ここに「なぜ進んでいないのか」という確認を出すと、動いている代理店を疑ったことになります。

lost_candidate は、判定ではなく候補です。 「見込みなし」と決めるのは両者の話し合いであり、この区分が意味するのは、本部で引き取るかを検討する対象に挙がったということだけです。

（3）確認依頼の文面の下書き

区分ごとに、送る文面の下書きを作らせます。催促に読めない書き方が条件です。代理店は取引先であり、部下ではありません。

指示内容を固定する

あなたはメーカーの営業本部で、販売代理店へ配分した見込み客の
進捗を確認する担当者です。
下の材料をもとに、案件ごとの停滞の区分を判定し、
必要な場合は代理店へ送る確認依頼の下書きを作ってください。

【厳守事項】
- 代理店を評価しないでください。
  書けるのは「報告と接点が◯営業日ありません」という事実までです。
- 報告に書かれていないことを推測で補わないでください。
  「訪問したので提案も済んでいると思われる」と書かないでください。
  記載がなければ「不明」としてください。
- 経過日数を自分で計算しないでください。
  下に与えた営業日数の値をそのまま使ってください。
- 区分は次の5つのいずれかにしてください。それ以外を作らないでください。
  active / no_report_but_active / stalled / lost_candidate / undetermined
- 判断の材料が足りない場合は、無理に区分を決めず undetermined にしてください。
  配分の記録が欠けている、報告の記述が読み取れない、
  どの案件についての報告か分からない場合が該当します。
- すべての判定に、根拠を書いてください。
  報告のどの記述を見たか、どの接点を見たかを示してください。
  根拠を示せない判定は undetermined にしてください。
- 確認依頼の文面は、催促にならないようにしてください。
  「なぜ進んでいないのか」「いつまでに対応してください」と書かないでください。
  「状況を教えてください」「本部で手伝えることはありますか」という
  問いかけの形にしてください。
- 見込み客の氏名・連絡先・住所を文面に書かないでください。
  案件は lead_id で示してください。
- 成約の可能性や受注確度を数値で予測しないでください。

【判定の基準日】
{base_date}

【代理店の情報（営業日、報告の形式と頻度、言い回しの癖）】
{dealer_profile}

【停滞と見なす営業日数（この代理店・この商材の設定）】
{threshold}

【案件の一覧（lead_id、配分日、最終報告日、最終接触日、
 それぞれの経過営業日数）】
{leads}

【代理店からの報告（案件へ紐づけ済みの記述）】
{reports}

【自社側の接点の記録（種類と日付）】
{touches}

【過去にこの案件について送った確認依頼と、その回答】
{past_inquiries}

「経過日数を自分で計算しないでください」の一文を必ず入れてください。 計算を任せると、休業日の扱いが案件ごとに変わります。

「根拠を示せない判定は undetermined にする」も外せません。 根拠のない停滞判定は、代理店への確認依頼にそのまま化けます。間違った確認は、出さなかったことよりも害が大きいと考えてください。

「催促にならないように」の指示は、例文で示すほうが効きます。 禁じたい言い方と、使ってほしい言い方を並べて書いてください。抽象的に「丁寧に」と書くだけでは、丁寧な催促文ができあがります。

出力形式を固定する

{
  "base_date": "",
  "leads": [
    {
      "lead_id": "",
      "dealer": "",
      "assigned_at": "",
      "last_report_at": "",
      "last_touch_at": "",
      "status": "active | no_report_but_active | stalled | lost_candidate | undetermined",
      "days_since": {
        "assigned": 0,
        "last_report": 0,
        "last_touch": 0
      },
      "evidence": {
        "report_quote": "",
        "touch_summary": "",
        "note": ""
      },
      "message_draft": "",
      "needs_human": {
        "value": false,
        "reason": ""
      }
    }
  ],
  "unmatched_reports": [
    { "source": "", "received_at": "", "excerpt": "", "reason": "" }
  ]
}

構造化する理由は、区分ごとに処理の行き先が変わるからです。 status が文章の中に埋もれていると、ワークフロー側で分岐できません。status を固定の5つの値に限った項目として出させることで、Zapier の Paths のカスタムルールで振り分けられます。

days_since を3つに分けていることが重要です。 配分からの日数、最終報告からの日数、最終接触からの日数は、それぞれ意味が違います。報告から30営業日経っていても、接点が3営業日前にあるなら no_report_but_active です。

days_since はすべて営業日で数えます。 代理店の休業日と自社の休業日を引いた日数です。暦日で数えると、連休を挟んだだけで停滞に見えます。 年末年始や夏季休業のあとに確認依頼が一斉に出る事故は、この一点で防げます。

evidence を持たせるのは、担当者が確かめるためです。 「報告のこの一文を見た」「資料請求が2回あった」と示されていれば、数十秒で妥当性を判断できます。根拠がないと、結局4つの画面を開き直すことになり、工数が減りません。

message_draft は下書きであって、完成した文面ではありません。 代理店との関係の濃淡は担当者しか知りません。そのまま送れる形に見えることが、かえって危険です。

unmatched_reports を必ず出させてください。 案件へ紐づかなかった報告の一覧です。ここが空でないうちは、停滞の判定が信用できません。

システムへ連携する

確認依頼の送信は自動化しません。 下書きまでを作り、人が送ります。

区分ごとの振り分けには Zapier の Paths を使います。 1グループ内に最大10個のパスブランチを作れるため、5つの区分は余裕を持って収まります。カスタムルールでは AND / OR で条件を組み合わせられるので、「stalled かつ 配分からの経過が60営業日を超える」といった条件で、別の扱いにすることもできます。各 Zap 内では最大3階層までネストできます。

フォールバックのパスが undetermined を受けます。 active / no_report_but_active / stalled / lost_candidate にカスタムルールを設定し、どれにも当てはまらなかったものをフォールバックが拾う形にします。フォールバックは「グループ内の他のパスブランチが実行されなかった場合に実行される」ものなので、想定していない値が返ってきた場合も、黙って消えずに人の手元へ届きます。

CRMへの書き戻しは、区分と判定日だけにとどめてください。 「要注意」「対応遅延」といったフラグが自動で立つ設計にすると、この仕組みが評価の道具になります。

代理店へ自動で何かを送る連携を作らないでください。 通知先は本部の担当者だけです。ここを一度崩すと、報告が来なくなります。

人が確認する

担当者の確認を必ず残します。

undetermined を放置しないことが、この構成を育てる唯一の方法です。 配分の記録が欠けている、報告の書き方が独特、商材の設定が入っていない、といった原因が並びます。1件ずつ潰していくと、翌月の undetermined が減ります。

確認を速くするための設計が効きます。

• 区分ごとに並べ、stalled と undetermined を上に置く
• 根拠の抜粋を一覧の上で読めるようにする
• 経過営業日数を、配分・報告・接点の3つとも表示する
• 同じ代理店の案件をまとめて表示し、1通で複数案件を尋ねられるようにする
• 過去にその案件で確認を出した履歴を、横に並べる

4つ目が、代理店の負担を大きく変えます。 5通のメールが届くのと、1通で5件を尋ねられるのとでは、受け取る側の印象がまったく違います。

5つ目は、繰り返しの確認を防ぎます。 先月「工事の時期待ち」と回答をもらっているなら、今月また同じことを尋ねる必要はありません。過去の回答を見ずに確認を出すことが、いちばん関係を損ないます。

例外に対処する

unmatched_reports を捨てないことが、いちばん大事な例外処理です。 報告しているのに紐づかない案件へ確認依頼を出すのが、最悪の形です。紐づかない報告が残っているあいだは、その代理店の stalled の判定を保留するという扱いも検討してください。

記録を残す

この記録が、次の判定の材料になります。

• 判定した案件と、区分、判定日、経過営業日数
• 判定の根拠（見た報告の記述、見た接点）
• 担当者が区分を変えた事例と、その理由
• 送った確認依頼の文面と、送信日
• 代理店から返ってきた回答と、その後の進捗
• undetermined の件数と、その原因の内訳
• 紐づかなかった報告の件数と、原因

「担当者が区分を変えた事例」が、いちばん役に立つ記録です。 stalled を担当者が active に直したなら、判定の条件か台帳が合っていません。その理由を残しておけば、停滞と見なす日数の設定を直せます。

代理店ごとの報告の癖も、この記録から拾えます。 ある代理店の「架電済み」が不在も含むと分かったら、台帳の「言い回しの癖」の列に足します。読み取りの精度は、この積み重ねでしか上がりません。