CRM・SFA

同じ人に3回メールが飛んだ原因は、再登録の設定ではありません

用語

CRM（顧客管理システム）
SFA（営業支援システム）
MA（マーケティング自動化ツール）

公開 2026年9月11日更新 2026年10月17日

同じ相手に、同じ通知メールが3回届きました。配信は夜中の1時台に3日連続で走っていました。

現場が最初に疑ったのは再登録の設定です。たしかにオンでした。見込み度合いが一度下がって、また上がった相手には、もう一度知らせたい。そのための正しい設定です。

オフにすれば配信は止まりますが、本当に知らせるべき2回目も止まります。

再登録を切れば止まる。でも、それは原因を消していない

再登録の設定は「条件にもう一度合致した人を、もう一度入れるか」を決めます。オンなら、条件に合う状態に戻るたびに入り直します。問題は、なぜ毎晩「戻って」いたかです。

このとき起きていたのは、起動条件に「見込み度合いが高い」を置き、そのワークフローの最後で同じ項目を「通知済み」に書き換えていたことでした。

自分で条件から外れる値に書き換えても、次に誰かが元の値に戻せば、また条件に合致します。合致したので、また入ります。

一周して戻ってくる自動化は、設定画面のどこにもループとして表示されません。1本のワークフローとしては、上から下まで正しく動いています。

状態を書いたつもりでも、再登録をオンにすると機械は変化を数える

ここを取り違えると、設計は毎回同じ壊れ方をします。

起動条件は「見込み度合いが高いレコード」のように、状態として書けます。ところが再登録をオンにすると、実際の動きは「見込み度合いが高いに戻るたびに拾う」になります。設計書の上では状態を書いたつもりでも、運用では変化を数えています。

人の目には「ずっと見込み度合いが高い相手」でも、項目の履歴には「高い→通知済み→高い」と毎晩の変化が残ります。システムが反応しているのは、この履歴のほうです。

自動化が自分の書き込みをきっかけに再起動するのは、この非対称のせいです。人は状態を設計したつもりで、機械は変化を数えている。

一度の事故で終わらないのは、毎晩元の値を書き戻す経路があるから

止まらなかった本当の理由は、外にありました。

この案件では基幹側とCRM（顧客管理システム）を夜間に同期していて、変更の有無にかかわらず、基幹側の値で対象レコードの全項目を上書きする実装でした。

基幹側の見込み度合いは「高い」のままです。CRMで「通知済み」に書き換えても、毎晩、基幹側の「高い」に戻されます。

起動条件に置いていた項目が、たまたまその同期の対象に入っていました。だから3日連続で1時台だったわけです。ワークフローは暴走していません。条件に戻されたから、入り直しただけです。

ワークフローが書く項目（②）を起動条件（①）に使い、その項目を夜間同期（③）が戻している。

連携を入れた時点で、CRMの中の項目は「人が触ったときだけ変わるもの」ではなくなります。どのシステムが、どの項目を、どの頻度で書くのか。これを決めずに自動化を載せると、起動条件の意味が後から変わります。

CRM連携が止まる原因は、機能ではなく照合キーの設計でしたで書いた照合キーの話と、根は同じです。どの値を誰が持つかを決めていないだけです。

現場が自動化に一番期待している場所だから、事故のコストが高い

マツリカが2024年11月25日から28日に実施した調査（IDEATECHの調査企画によるインターネット調査、SFA・CRMを利用しているB2B企業の営業部門の管理職・主任101名）では、SFA（営業支援システム）に求める機能の1位が「入力の自動化・項目の簡略化」47.5%、2位が「AIによる入力サポート」45.5%でした。

n=101と小さく、SFAを販売している会社の調査です。桁感として読んでください。

期待の方向は、はっきりしています。現場は自動化を嫌っていません。むしろ、そこに最も助けを求めています。

一方で、Innovation & Co.が2022年10月に実施した調査（n=438、MAツール導入企業）では、導入検討時には各機能を8割以上が重視していたのに、導入後は51%以上が「活用していない」と答えています。理由の上位は、使う場面がなかった、リソースが足りない、難しくて使えなかった。こちらもMA（マーケティング自動化ツール）ツールを提供している会社の調査です。

誤配信が1回起きると、この二つの数字が同じ場所でぶつかります。期待していた機能が、顧客に見える形で失敗した。次に提案する自動化は、機能の議論ではなく信頼の議論になります。復旧に時間がかかるのは設定ではなく、そこです。

起動条件に置いてよいのは、その自動化が書き換えない事実だけ

判定は1行で済みます。「この起動条件の項目を、このワークフローは書き換えるか」。書き換えるなら、そのままでは置けません。

やることは3つです。

条件に使う項目と、アクションで書き込む項目を、一覧にして突き合わせます。交差しているものが事故の候補です。

交差を消せない場合は、起動を「変化」ではなく「状態」で書きます。値に変わった瞬間ではなく、値になっていて、かつ通知済みのフラグが立っていないレコード。通知したらフラグを立てる。フラグは連携の対象外の項目に置きます。

同期で消されるフラグでは、同じことが起きます。これで二周目は条件に合致しなくなります。

ただし、立てたフラグを下ろす条件も要ります。下ろさなければ、冒頭で守りたかった「下がって、また上がった相手への2回目」まで止まります。

見込み度合いが「高い」と「通知済み」以外の値に変わったら、別のワークフローでフラグを下ろします。このワークフロー自身が書く「通知済み」と、同期が「高い」を書き戻しただけの変化では、フラグを下ろしません。

連携側は、書き戻しを差分だけにし、CRM側で持つ項目は同期の対象から外します。変更がない項目を毎晩上書きしている実装は、ツールと書き込み方によっては、自動化がなくてもレコードの最終更新日時を毎日書き換えます。

「最終更新から30日動いていない商談」のようなレポートが、静かに空になります。誤配信より見つけにくい壊れ方です。

そして、本番に出す前に1件だけテストします。ワークフロー画面のテスト機能が、起動条件や再登録の判定まで再現するかは、ツールと設定によって違います。

確実なのは、テスト用のレコードを基幹側とCRMの両方に1件用意し、そのレコードだけが起動条件に合う絞り込みをかけたうえで、本番のワークフローを実際に通すことです。絞り込みは、テストが終わってから外します。見るのは結果ではなく登録の履歴です。

確かめることは3つあります。通したあとに連携の書き戻しを1回流し、同じレコードがもう一度登録されないこと。その書き戻しで、フラグが下りないこと。基幹側で見込み度合いを一度下げてから「高い」に戻すと、フラグが下りて、もう1回だけ登録されること。

3つとも想定どおりなら、設計は閉じています。

顧客の社内工程まで含めて収益の設計を組み直す考え方は、レベニューアーキテクチャとはに置いています。

自動化の起動条件には、その自動化自身が書き換える項目を使わないでください。使った瞬間、ワークフローは自分の出力を入力として読み直し、止める方法が設定画面の外に出ます。

今週、稼働中のワークフローを一覧で出してください。起動条件の項目と、アクションで書き込む項目を並べる。同じ項目が両側にあるものが1本でもあれば、それは今夜動く可能性があります。