CRM・SFAが定着しない

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

公開 2026年9月11日

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

現場が最初に疑ったのは再登録の設定です。そこはオフでした。

再登録をオフにしても止まらないなら、見ている場所が違う

再登録の設定は「一度通った人をもう一度入れるか」を決めます。ここがオフでも同じ人に複数回届くなら、システムはその人を同じ人として数えていません。別の登録として毎回新しく受け付けています。

このとき起きていたのは、起動条件に「見込み度合い」という項目の更新を置き、そのワークフローの最後で同じ項目を書き換えていたことでした。書き換えた瞬間、その項目は更新されます。更新されたので、条件に合致します。合致したので、また入ります。

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

プロパティの更新で起動する条件は、状態ではなく履歴を見ている

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

CRMの起動条件には二種類あります。「この値になっているレコード」を拾うものと、「この値に変わった瞬間」を拾うものです。前者は状態を見ています。後者は変化、つまり履歴を見ています。画面上はどちらも似た書き方になるので、設計書の上では区別がつきません。

変化を拾う条件は、値が同じでも上書きが起きれば反応します。「Aのまま」でも、Aをもう一度書き込めば、それは更新です。人の目には何も変わっていないのに、システムから見れば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つです。

条件に使う項目と、アクションで書き込む項目を、一覧にして突き合わせます。交差しているものが事故の候補です。交差を消せない場合は、起動を「変化」ではなく「状態」で書きます。値に変わった瞬間ではなく、値になっていて、かつ通知済みのフラグが立っていないレコード。通知したらフラグを立てる。同じ設計でも、二周目は条件に合致しなくなります。

連携側は、書き戻しを差分だけにします。変更がない項目を毎晩上書きしている実装は、自動化がなくてもレコードの更新日時を毎日壊しています。「最終更新から30日動いていない商談」のようなレポートが、静かに空になります。誤配信より見つけにくい壊れ方です。

そして、本番に出す前に1件だけテストします。HubSpotならワークフロー画面のテスト機能、Salesforceならサンドボックスで、1レコードを通します。見るのは結果ではなく履歴です。同じレコードが2回登録されていないか。1回で止まるなら、設計は閉じています。

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

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

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