リフォーム会社が見積を出したあとのお客様とのメール・LINE・電話のやり取りを n8n で集め、検討の段階で分けて、営業のフォローの順を毎週作る

処理の起点を決める

起点は2つです。 LINE のメッセージの受け口と、毎週月曜の定時です。

LINE は、お客様のメッセージが届くたびに Webhook で n8n に送られます。 n8n の Webhook ノードには、エディタで待ち受けている間だけ動くテスト用の URL と、ワークフローを公開（publish）したときに登録される本番の URL があります。LINE Developers コンソールに登録するのは本番の URL です。 テスト用の URL を登録したままにすると、エディタを閉じた後のメッセージが届きません。

LINE の公式ページは、Webhook の再送（既定は無効）を有効にすると同じイベントが複数回届くことがあり、webhookEventId で重複を見分けるよう案内しています。再送を有効にしていなくても、受けた直後に webhookEventId で引いて、あれば止めます。 再送のときは届く順が前後することもあるので、並べるときは timestamp を使います。

毎週の分類は月曜の朝6時です。 n8n の Schedule Trigger は、ワークフローにタイムゾーンが無ければインスタンスの設定を使い、自分で立てた n8n の既定は America/New York です。ワークフローの設定で Asia/Tokyo にしないと、日曜の夕方に動きます。

入力データを集める

質を決めるのは、商談メモです。 電話で聞いた「主人と相談します」「来年の春でいい」は、メモに書かれていなければどこにも残りません。メモが「電話した」だけだと、AIはその週の段階を読めません。 メモには、お客様の言葉を短くそのまま書く決まりにします。

前週の分類を入れるのは、段階の変化を見るためです。 「比較中」から「見送りの兆し」に変わった案件は、金額が小さくても先に連絡します。

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

Gmail ノードの Simplify は既定で有効で、そのままだと件名や差出人などの見出しだけが返ります。 本文で段階を読むので、Simplify を切ります。

LINE は、Webhook を設定した日から後のメッセージしか集まりません。 それより前のトークは、LINE の画面で営業が読むしかありません。始める前に返事待ちだった案件は、最初の数週間、LINE の分が欠けていると考えてください。

LINE の公式ページが1対1のトークで届くとしているのは、お客様がメッセージを送ったとき・取り消したとき・友だち追加したとき・ブロックしたときなどのイベントです。自社から送ったメッセージを受け口で受ける記載は無いので、営業が LINE で答えた内容は商談メモに短く書きます。 そうしないと、AIには「お客様が質問して、返事が無いまま」に見えます。

取り消しの扱いは、LINE の公式ページが求めていることです。 お客様が送信を取り消したメッセージは、今後見られたり使われたりしないよう、管理の画面の表示を取り消し、保存したものを消すよう勧めています。取り消された「他社さんは〇〇円でした」を AIが読んで「比較中」にすれば、お客様の意図に反した使い方になります。

AIへ渡す前に整形する

1. LINE の署名を照らす … Webhook ノードで Raw Body を受け、Crypto ノードの Hmac（SHA256、チャネルシークレット）で計算した値を x-line-signature と比べる。合わなければ記録しない
2. 時刻の順に並べる … メール・LINE・商談メモを1本の時系列にし、行の頭に「お客様」「自社」「電話のメモ」を付ける
3. 反応なしの判定 … 見積の送信日の後に、お客様からのメール・LINE・電話のメモが1件も無ければ「反応なし」にして、AIに回さない
4. 前週からの増分の印 … 前回の分類の後に増えたやり取りに「新」を付ける
5. 長さを絞る … 1案件あたり直近の20件まで。見積の本文や添付は渡さない
6. 個人の情報を伏せる … 電話番号、住所の番地、家族の名前を伏せる

1番目の署名の照らし合わせを省かないでください。 LINE の公式ページは、Webhook の受け口には LINE 以外から悪意のあるリクエストが届きうるので、処理の前に署名を確かめるよう求めています。署名は、Webhook の本文をチャネルシークレットで HMAC-SHA256 にかけたものです。本文を JSON として読み直してから計算すると一致しないので、Raw Body のまま計算します。

3番目は、第1章で書いたとおりです。 お客様の言葉が1つも無い案件を AIに渡すと、自社のメールの文面を読んで段階を決めてしまいます。

AIに処理させる

させるのは2つです。 案件ごとに検討の段階を1つ選ぶことと、その根拠になったお客様の言葉を1つ写し、次の一手の候補を短く書くことです。

1案件に1つだけ選ばせます。 比較中で予算の見直しでもある、という案件はあります。ただ、2つ選ばせると営業の次の一手が決まりません。 指示で「最も新しいお客様の言葉で決める」と順を決めておきます。

指示内容を固定する

Text Classifier の段階の説明と、System Prompt Template に入れる指示です。

あなたはリフォーム会社の営業部で、見積を出したあとのお客様の検討の段階を整理する立場です。
下の【やり取り】は、見積を送った後のメール・LINE・電話のメモを時刻の順に並べたものです。
行の頭の「お客様」「自社」「電話のメモ」で、誰の言葉かが分かります。

【段階】
{categories}

【厳守事項】
- 段階は「お客様」の行と「電話のメモ」に書かれたお客様の言葉だけで決めてください。
  「自社」の行の内容（見積の説明、お礼、日程の提案）を根拠にしないでください。
- お客様の言葉が複数の段階に当てはまるときは、最も新しい言葉で決めてください。
- 「新」の印が付いた行があれば、その行を優先して読んでください。
- やり取りに書かれていない事情を推測しないでください。
  返事が遅いことや、言葉づかいが丁寧なことを、前向き・見送りの根拠にしないでください。
- どの段階にも当てはまると言い切れないときは、無理に選ばないでください。

Basic LLM Chain に渡す、根拠と次の一手の指示です。

【段階】{stage} と分けた案件について、次の2つを書いてください。

1. quote … 段階の根拠にしたお客様の言葉を、【やり取り】からそのまま1つ写してください。
   言い換えたり、まとめたりしないでください。お客様の言葉が見つからなければ空にしてください。
2. next_action … 営業が次にすることの候補を、【段階】の表の候補から1つ選び、
   この案件に合わせて30字以内で書いてください。
   値引きの提案、契約を急がせる言い方は書かないでください。

【やり取り】{timeline}
【工事の種類】{work_type}

「自社の行を根拠にしない」を最初に書くのが要点です。 時系列には自社の丁寧なメールが多く並び、何も言わないとAIはその調子に引っ張られます。根拠をお客様の言葉に限ると、段階の読みが営業の実感に近づきます。

根拠をそのまま写させるのも同じ理由です。 営業は、AIの要約ではなくお客様の言葉を見て、段階が合っているかを判断します。言い換えた根拠は、合っているかを確かめられません。 写したはずの言葉が本当に時系列にあるかは、後段の Code ノードで文字列として照らします（第7章「例外処理」）。指示で「そのまま」と書いても、句読点を足したり語尾を整えたりすることがあるためです。

出力形式を固定する

Text Classifier は段階ごとの出口に案件を流し、Basic LLM Chain は次の JSON を返します。 プログラムが前後の値を足して、1案件1行の形にそろえます。

{
  "estimate_id": "R-2026-0412",
  "owner": "営業担当の名前",
  "stage": "positive | comparing | budget | timing | family | dropping | no_response | other",
  "stage_source": "classifier | rule",
  "previous_stage": "comparing",
  "quote": "",
  "next_action": "",
  "valid_until": "2026-11-10",
  "amount": 1850000,
  "days_since_last_contact": 9,
  "priority": 1
}

1つ目の理由は、stage_source で反応なしを分けられることです。 rule はプログラムが日数で決めたもの、classifier はAIが読んだものです。段階の正しさを見直すときは、classifier だけを見ます。

2つ目は、previous_stage で変化が分かることです。 順の規則は、段階に加えて「前週から悪い方へ変わった」を上に上げます。

3つ目は、priority を規則で付けることです。 規則は次のとおりで、営業部で決め直せます。

システムへ連携する

見積の台帳の既存の行は書き換えません。 分類の結果は「今週のフォロー」という別のシートに足します。案件の状態（返事待ち・契約・失注）を変えるのは営業です。

人が確認する

1. 月曜の朝、一覧の上から見る … 順の1〜3の案件は、quote を読み、段階が合っているかを確かめる
2. 段階を直したら書く … 一覧の「直した段階」の欄に書く。次の週の previous_stage には直した段階が使われる
3. Other の案件を見る … どの段階にも当てはまらなかった案件は、営業が段階を決める
4. 見送りの兆しは上長と見る … 理由を伺うか、閉じるかを決める

2番目を省かないでください。 直した段階が次の週に引き継がれないと、毎週同じ取り違えが一覧に並びます。

目標は、300件をならして1件3分です。 段階が合っている案件は根拠を読んで数十秒、直す案件と Other は数分かかります。

例外に対処する

下の2行で、黙って一覧から落とさないことが大事です。 分類できなかった案件ほど、営業が見るべき案件です。印を付けて載せれば、営業が自分で判断できます。

記録を残す

• LINE の Webhook の受信の記録（webhookEventId、受けた時刻、署名の結果）
• 毎週の分類に渡した時系列（伏せ字にした後のもの）
• 段階・根拠・次の一手と、stage_source
• 営業が直した段階と、直した理由
• 順の規則の版と、変えた日
• その後、契約・失注になった日と、失注の理由

最後の行が、段階の分け方を見直す材料になります。 「比較中」と分けた案件のうち、どれだけが契約になったか、どの段階から失注が多いかが分かれば、段階の説明や順の規則を直せます。