顧客フォローを仕組みにする──LINE×Make.comで「要フォロー」アラートをゼロ工数で届ける設計

執筆 on the edge 編集部

「フォローしようと思っていたのに、気づけば2週間が経っていた。」

これは意志の問題ではない。人が頭の中でタスクを管理する限り、他の業務に追われれば押し出される。フォロー漏れを「気をつけよう」で解決しようとしている組織は、毎月同じことを繰り返す。

解決の方向は一つだ。フォローが必要なタイミングを人が判断するのではなく、仕組みが検知して担当者に届ける設計に変える。

顧客管理（CRM）入門では見込み客の状態管理を、顧客離反防止入門では早期シグナルの検知設計を整理した。今回はその「検知後の通知」を自動化する。私たちが自社cockpitで運用している「要フォロー」フラグの設計を起点に、LINE×Make.comで構築するアラートフローの手順を示す。

※本記事の情報は2026年10月時点のものです。cockpit実例は自社内部の運用に基づきます。Make.comの仕様・料金は変更されることがあるため、実装前に公式サイトで確認してください。

この記事でわかること

1. フォロー漏れは「気をつけ不足」ではなく設計の問題

顧客フォローが抜ける原因は、ほぼ共通している。

• フォロー予定を頭の中やメモ帳で管理している
• 「いつまでにフォローする」というトリガーが人の記憶に依存している
• 商談や対応が増えるほど、古い案件が視野から押し出される

担当者が悪いのではなく、人間の注意資源が有限だという前提を無視した設計が問題だ。

解決の方向性は「フォロー判断を人から仕組みに移す」こと。誰かが「そろそろフォローしよう」と思うのを待つのではなく、条件を満たした顧客情報が自動的にアラートとして届く状態を作る。

2. cockpit「要フォロー」フラグ設計の概念

私たちが自社で運用しているcockpit（営業管理・顧客管理の統合ダッシュボード）では、顧客の状態に「要フォロー」フラグを立て、それをトリガーとして担当者へ通知する仕組みを組み込んでいる。

設計の核心は「フラグを立てる条件の明示化」だ。

これらの条件はスプレッドシートの関数か、Make.comのスケジュール実行で評価できる。評価結果をLINEやSlackに通知することで、担当者は「毎日リストを確認する」という行動をしなくても、アラートが届いたときだけ動けばよい状態になる。

cockpitではLINEから受け取った情報（音声メモ・テキスト）を文字起こし→部長AIが判断→承認キューへ、というフローが動いている。「要フォロー」フラグはその承認キュー内で立ち上がり、Slack通知で担当者に届く設計だ。同様の構造をスプレッドシート＋Make.comで再現するのが今回の目的になる。

3. LINE×Make.comで作るアラートフロー

Make.comは複数のサービスを「トリガー→アクション」で繋ぐ自動化ツールだ。スプレッドシートのデータを読み取り、条件に合致した行に対してLINE通知を送るフローは、コードなしで構築できる。

Make.com×AI活用入門で基本フローの設計手順を整理しているが、顧客フォローアラートの場合、以下の構成が最小単位になる。

[Make.com スケジュール実行（毎朝9時）]
  ↓
[Google Sheets：「要フォロー」対象行を検索]
  ↓
[条件分岐：対象行が存在するか？]
  ↓（Yes）
[LINE Messaging API：担当者に通知]

通知メッセージの例：

【要フォロー】田中様（株式会社○○）
最終連絡: 10/3（14日経過）
ステータス: 提案済み・返答待ち
→ 本日中に確認してください

4. 3つの自動化パターン

パターン1：新規問い合わせ後フォロー

問い合わせ受付日から X 日後に「フォロー確認」アラートを送る。

• 適用場面： 一次返信後、商談日程が決まっていない段階
• トリガー： 問い合わせ登録日＋X日（例：3日後・7日後）
• 通知内容： 相手の名前・会社名・問い合わせ内容・経過日数

パターン2：ステータス停滞フォロー

「提案済み」「見積もり送付済み」などの特定ステータスが一定期間変化しない場合にアラートを送る。

• 適用場面： 商談が止まっている案件の掘り起こし
• トリガー： ステータス更新日から Y 日経過（例：7日・14日）
• 通知内容： 担当者名・商談名・ステータス・停滞日数

パターン3：定期接触フォロー

既存顧客に対し、最終連絡日から Z 日経過した場合にアラートを送る。

• 適用場面： 継続取引先・月額サービス顧客の関係維持
• トリガー： 最終連絡日から Z 日経過（スプレッドシートに記録）
• 通知内容： 顧客名・最終連絡日・経過日数

3つのパターンを同時に走らせる必要はない。最初は自社にとって最も損失が大きいフォロー漏れを1つ選んで、そこから始める。

5. スプレッドシートから始める最小実装手順

Step 1 — データ構造を決める

Google Sheetsに以下の列を用意する。

Step 2 — Make.comのシナリオを作る

1. トリガー：「Schedule」モジュール（毎朝9時実行）
2. アクション：「Google Sheets - Search Rows」で「要フォロー = Yes」を絞り込む
3. アクション：「Iterator」で対象行を1件ずつ処理
4. アクション：「LINE Messaging API」で通知文を送信

LINE公式アカウントとの連携設計はLINE公式アカウント×AI活用ガイドも参照。

Step 3 — テスト実行と調整

最初の2週間は「要フォロー」の条件（日数）を厳しめに設定して通知量を確認する。通知が多すぎればX日を延ばし、見逃しが多ければ縮める。

Step 4 — 対応記録を必ず残す

フォロー実施後は「最終連絡日」を更新する運用ルールをセットで決める。更新しなければ翌日もアラートが出続ける。これが属人化を防ぐ仕組みの核だ。

6. よくある落とし穴3つ

落とし穴①：対応後に最終連絡日を更新しない

アラートが来ても対応後にスプレッドシートを更新しないと、同じ顧客に毎日通知が届く。通知文に「対応後は最終連絡日を更新してください」と記載するか、対応ログ列を設けて対応済みフラグを立てるルールを最初に決める。

落とし穴②：通知先が個人のLINEに紐付きすぎる

担当者が変わったとき、通知が前任者のLINEに届き続ける。通知先はチャンネル（Slackや法人LINE）に集約し、担当者割り当ては別の列で管理するのが安全だ。

落とし穴③：条件を増やしすぎて通知が無視されるようになる

アラートが多すぎると「また来た」と流されるようになる。最初はパターンを1つに絞り、対応率が安定してから追加する。通知の精度（本当にフォローが必要な案件だけが来る）を維持することが、システム継続の前提だ。

90日アクションプラン

よくある質問

Q: Make.comは有料ですか？

無料プランでも月1,000オペレーションまで利用できる。毎朝1回スプレッドシートを読み取り10件以下の通知を送る程度であれば、無料枠に収まるケースが多い。用途が広がれば月額9ドル（Coreプラン）が現実的な選択肢になる。

Q: LINE NotifyはサービスTerminated対応済みですか？

LINE Notifyは2025年4月にサービス終了。代替は「LINE Messaging API」（個人LINE宛）または「LINE WORKS Bot」（法人向け）。Make.comにはどちらのモジュールも用意されているため、送り先に合わせて選ぶ。

Q: CRMツールを導入した方が早くないですか？

SalesforceやHubSpotはフォローアラート機能を内包しているが、月額コストと導入工数が発生する。スプレッドシート＋Make.comのアプローチは、顧客数が20件以下・担当が1〜2人の規模では十分機能する。顧客数が増えてからCRM移行の判断をすればよい。

まとめ

フォロー漏れは、担当者の意識ではなく設計で防ぐ。cockpitで私たちが実運用している「要フォロー」フラグの設計は、条件の明示化とアラートの自動送信という2つの要素で成立している。

スプレッドシートにデータが揃っていれば、Make.comのシナリオは1〜2時間で構築できる。まず1つのパターン（新規問い合わせ後フォロー）だけ動かして、フォロー対応率が変わるかを確認する。仕組みが機能することを確認してから、パターンを増やす。

自社業務への適用を一緒に設計したい場合は、サービス一覧から支援内容を確認するか、お問い合わせ（初回相談・無料）からご相談ください。

著者: on the edge 編集部