ooligo
n8n-flow

未割り当て・誤割り当て・SLA 超過のリードをルーティング監視で検知する

Difficulty
上級
Setup time
2-3 hours
For
revops · gtm-engineer
RevOps

Stack

Salesforce のリードルーティングを外側から監視し、営業担当が気づく前に人を呼び出す n8n ワークフローです。1 本の SOQL クエリの上で 3 つのディテクターが 15 分ごとに走ります。滞留キューに留まったままのレコード、無効化されたユーザーが所有者になっているレコード、初回接触 SLA を超過したレコードの 3 種類です。加えて平日の朝にラウンドロビンの偏りを 1 回チェックします。検知結果は重複排除され、条件が解消すれば自動的にクローズされ、ワークフロー自身が明示するルールに従って PagerDuty と Slack に振り分けられます。バンドルは apps/web/public/artifacts/routing-failure-watchdog-n8n/ にあり、20 ノードの完全なエクスポートに加えて、インポート手順、2 つの認証情報、環境変数の一覧表、5 段階の検証手順、運用コストをまとめた _README.md が入っています。

2 つの時計

speed-to-lead のダッシュボードはたいてい 1 つの数字しか出しません。リード作成から初回接触までの時間です。この数字は独立した 2 つの障害の合計であり、合算してしまうことこそが、出てきたアラートが間違った人を起こす原因です。

ルーティング遅延は「作成 → 割り当て」です。割り当てルールが一致しなくなったとき、ルーティンググラフのノードがエラーを投げたとき、キューが詰まったとき、グラフの途中のエンリッチメント処理の背後で認証情報が期限切れになったときに壊れます。これはオペレーション上のインシデントであり、オンコール担当が午前 2 時に直せるものであり、このワークフローでは呼び出しが飛びます。

レスポンス遅延は「割り当て → 最初に記録された接触」です。担当が会議中、休暇中、あるいはキューを無視しているときに壊れます。これはマネジメントの会話であり、午前 2 時に誰かが直せるものではなく、このワークフローでは Slack に投稿されるだけで、決して呼び出しは飛びません。

Parse Routing State は両者を別々に計算し、前者を捏造することを拒みます。ルーティングのタイムスタンプがないレコード、つまり割り当て日時のフィールドも LeanData のログ行も持たないレコードは、CreatedDate にフォールバックさせずに routedAtSource: 'none' と記録します。フォールバックさせれば組織内の全レコードでルーティング遅延が 0 と報告され、ディテクターは永久に沈黙します。

これがなぜ重要かという公開された根拠は、その周りの通説よりも古く、薄いものです。追跡可能な結果は 2007 年の Lead Response Management 研究 (Oldroyd、InsideSales.com との共同) で、約 15,000 件のリードと 100,000 件の架電を分析し、5 分ではなく 30 分後に架電した場合、リードに接触できる確率は約 100 分の 1、商談化できる確率は約 21 分の 1 に下がると報告しています。これは 6 社から得られた 20 年近く前のデータであり、よく引用される「78% は最初に返答した会社から買う」という数字には公開された調査手法が存在しません。自社のファネルを計測できるなら RESPONSE_SLA_MINUTES はそこから決めてください。デフォルトの 5 分は慣習であって法則ではありません。

使うべき場面

ルーティングが自動化されていて、その障害が無音で起きる場合に使ってください。この組み合わせが条件のすべてです。Salesforce のルールベースの割り当て、LeanData のグラフ、ラウンドロビンのプールはいずれも、壊れたときに何もエラーを出さないという性質を共有しています。レコードには所有者が付いたままで、ダッシュボードはすべて描画され続け、最初の兆候は「自分のキューが空になったのはなぜか」と尋ねる担当者か、競合に返信している見込み客です。

1 時間の停止が高くつくだけの流量をすでに扱っているチームに向いています。目安は 1 日あたりインバウンド 100 件以上で、2 時間の停止が 25 件のリードに相当し、滞留キューを目視で見ている人が誰もいない規模です。

レコードの行き先を決めるインバウンドリードのトリアージ、および watchdog が「何かが誤って着地した」と知らせた後にエージェントが「このリードがここに来た理由」に答えられる LeanData ルーティングの MCP サーバーと組み合わせて使います。このワークフローは警報であり、あちらは調査です。

使うべきでない場面

人手でリードを割り当てているなら不要です。手作業の割り当ては目に見えて失敗します。リストが長いことに誰かが気づくからです。このワークフローが捕まえるのは、あくまで自動化が静かに壊れる場合です。

滞留先の所有者を名指しできないなら不要です。未割り当てディテクターは PARKING_OWNER_IDS に対する集合の所属判定であって null 判定ではありません。理由は後述します。どのルールにも一致しなかったレコードがどのキューに入るのかを誰も言えないなら、監視を組む前にその問いに答える必要があります。ワークフローは組織が正常だと報告する代わりに、毎回のスイープでそのことを指摘し続けます。

n8n Cloud の Starter プランを使っているなら 15 分間隔はやめてください。トリガー 1 回につき 1 実行なので 1 日 96 回、月におよそ 2,950 回となり、Starter に含まれる月 2,500 実行を超えます (n8n の価格ページ、2026-08-12 確認、年払いで月 20 ユーロ)。10,000 実行の Pro に上げるか、セルフホストするか、*/30 に落として検知遅延が最大 15 分伸びることを受け入れるかのいずれかです。

未割り当てディテクターが集合判定である理由

Lead.OwnerId は決して null になりません。どの割り当てルールにも一致しない場合、Salesforce は Lead Settings で設定された Default Lead Owner にレコードを渡します。「これはルーティングされていない」を意味するフィールドは存在しません。未割り当てのリードと正しくルーティングされたリードは構造的に同一のレコードであり、所有者が誰かでしか区別できません。

そのため PARKING_OWNER_IDS にはデフォルト所有者と、すべての保留キュー・キャッチオールキューを入れます。ディテクターは、レコードがそのいずれかに営業時間換算で UNROUTED_GRACE_MINUTES を超えて留まっているかを問います。比較は Id の先頭 15 文字で行います。管理者は Salesforce のアドレスバーから 15 桁の Id を貼り付ける一方、REST API は 18 桁を返すためで、この 2 つの形式を直接比較することは、正しく設計されたディテクターが永久に何にも一致しなくなる最も多い原因です。

所有者のチェックにはもう 1 つ SOQL の工夫が要ります。OwnerId はポリモーフィックで User にも Group にも向きうるため、Owner.IsActive は単独では正当なフィールドパスになりません。Build Sweep QueryTYPEOF Owner WHEN User THEN Id, Name, IsActive WHEN Group THEN Id, Name, Type END (SOQL、API バージョン 46.0 以降) を使い、ユーザー所有者の有効状態とキュー所有者のキュー種別を 1 往復で取得します。

セットアップ

  1. インポート。 apps/web/public/artifacts/routing-failure-watchdog-n8n/routing-failure-watchdog-n8n.jsonWorkflows → Import from File から読み込みます。ワークフローのタイムゾーンを設定してください。2 つの cron 式がこれを読みます。

  2. Salesforce の認証情報を接続。 client credentials グラントの Connected App と、読み取り専用の Run As 統合ユーザーを用意します。watchdog は人ではなくジョブであり、エクスポート内の Salesforce 呼び出しはすべて /query/ または /limits に対する GET です。

  3. PARKING_OWNER_IDS を設定。 Id の探し方は _README.md のセクション 4 にあります。セットアップの中でこれ以上に重要な項目はありません。

  4. 2 つの SLA を意図をもって設定。 ROUTING_SLA_MINUTES (デフォルト 2) は呼び出しを飛ばし、RESPONSE_SLA_MINUTES (5) は投稿にとどめます。有効化する前に検証手順 4 でこの分離を確認してください。火曜の午後に PagerDuty へ届くレスポンス超過は、土曜の午前 2 時にも届きます。

  5. 営業時間の時計を設定。 BUSINESS_HOURS_TZ はワークフローのタイムゾーンとは別物です。一方はワークフローがいつ起きるかを決め、もう一方はどの分が SLA に算入されるかを決めます。

  6. 有効化の前に _README.md の 5 段階の検証を実行。 重要なのは手順 1 です。Salesforce の認証情報をわざと壊し、ワークフローが「正常なスイープ」と報告するのではなくアラートを出すことを確認してください。

障害モードとガード

0 件は「異常なし」と読めてしまう。 フィルターの打ち間違い、統合ユーザーの権限変更、期限切れの認証情報は、いずれも空の結果を生み、各ディテクターは何も問題がないと報告します。ガード。Parse Routing State は分母となる sweep_summary アイテムを出力し、営業時間中のスイープが何もサンプリングできなかった場合、Run Detectors は重大度 errorno_denominator を返してディテクターの出力全体を置き換えます。HTTP ノードは neverErrorfullResponse で動くため、401 と 403 は誰も読まない失敗実行ではなくデータとして届きます。

一括インポートはルーティング障害と見分けがつかない。 40,000 件のマーケティングリストは、正当な理由で数分間すべてを滞留させます。絶対件数でアラートを出せば、インポートのたびにインシデントになります。ガード。判別材料はソースの集中度です。本物のルーティング障害は LeadSource の値をまたいで分散しますが、インポートはそうなりません。STAMPEDE_MIN_BATCH (250) を超え、かつ滞留レコードの 90% が単一ソースに集中している場合、検知結果は info に落ち、呼び出しは抑止され、その理由がメッセージに書かれます。

実時間で SLA を計算すると月曜の朝が溢れる。 金曜 18:55 に着いたリードは、月曜 09:00 の時点で 5 分 SLA を破ってはいませんが、素朴な計算は 3,725 分の超過だと言います。ガード。経過時間は BUSINESS_HOURS_TZBUSINESS_DAYSBUSINESS_HOLIDAYS に対する営業時間の分で計算し、ワーカー自身の時計ではなく Intl.DateTimeFormat を使うことで、n8n ホストのタイムゾーンが結果に混入しないようにしています。

原因は 1 つ、アラートは 900 件。 壊れたルーティンググラフは、触れたすべてのレコードで SLA を破ります。ガード。検知結果は原因ごとにまとめられ、正確な件数と MAX_ITEMS_PER_ALERT (25) で上限を切ったサンプルを持ちます。PagerDuty の dedup_key が繰り返しを 1 件のインシデントに畳み込み、RENOTIFY_MINUTES (120) が重大度の上昇がない限り再通知を抑えます。

閉じないインシデント。 明示的な resolve なしに条件が解消すると、誰かが古い呼び出しを確認するまで PagerDuty のインシデントは開いたままになります。チャンネルがミュートされていく典型的な経路です。ガード。Alert Gate + Resolve はキーが発火しなくなった時点で同じ dedup_keyevent_action: 'resolve' を送ります。ただし、そのキーを再検知したはずのスイープが実際に成功した場合に限ります。認証エラーが本物のバックログを沈黙へと解消してしまわないためです。resolve は発生源でも区切られています。15 分のスイープと 08:00 の公平性ジョブが同一の状態オブジェクトを共有しており、区切らなければスイープが公平性アラートを発火の 15 分後に毎回閉じてしまうからです。

watchdog が依存している API 予算を食い潰す。 ガード。API Budget Gate はスイープごとに /limits から DailyApiRequests を読み、SFDC_API_BUDGET_PCT (85) を超えたら退きます。このフロー自身の消費はリスクではありません。スイープあたり 2 呼び出しは 1 日 192 回であり、Enterprise の割り当ては 24 時間のローリング枠で 100,000 リクエストから始まり、ユーザーライセンスごとに 1,000 ずつ増えます。リスクは、すでに逼迫した組織を押し切る最後の 1 呼び出しになることです。

これが置き換えるもの

現状は、誰かが一度作って誰も開かないレポートです。滞留キューは正確に見せますが、キューが伸び始めたその瞬間には何も言いません。そして重要なのはその瞬間だけです。

より近い比較対象は LeanData 自身の Audit Logs で、その土俵ではこのワークフローより優れています。Q2-2026 のリリースで、ノードのパスと評価された条件を引用しながら自然言語でルーティングの質問に答える組み込みアシスタントとともに作り直されました。管理者が 1 件のリードをデバッグするなら、それはすでに支払っている料金に含まれており、ここにあるどれよりも優れています。できないのは、自分から起きることです。あれは質問に答えるものであり、このワークフローが扱う障害は「そもそも問うべき質問があると誰も知らない」ことです。両方を動かしてください。watchdog が何かが壊れたと伝え、Audit Log がその理由を伝えます。

同じものをウェアハウス上のスケジュール SQL として作るのは正当な代替案で、Salesforce のデータが sync ですでにそこへ届いているなら明確に勝ちます。履歴、バックフィル、安価な集計が手に入るからです。n8n 版が勝つのは届いていない場合です。CRM を直接読むので、先に取り込みパイプラインを立てる必要がありません。そして呼び出し、重複排除、自動クローズは、SELECT 文がいくら払っても提供してくれない部分です。

Files in this artifact

Download all (.zip)