n8n每天自动筛查B2B流失风险订单并告警

原文要点

原文描述的免费n8n模板：每天凌晨2:00定时运行，读取Google Sheets的Orders_Ingest页签中未处理订单（须有order_id），从Account_Baselines按account_id关联客户基线并忽略Tier-3客户；计算订货量、下单节奏、核心SKU占比三类异常信号，命中至少一条才继续；客户上次告警日在冷却窗口内则抑制重复告警；其余订单连同基线上下文交Google Gemini，输出风险分级、主要假设、两条销售话术的结构化JSON；随后发Slack告警、Gmail通知对应销售、向Alert_Audit_Log写审计、更新Account_Baselines的last_alert_date、把订单标记为已处理。需建Google服务账号并共享表格、Gemini(Google PaLM)凭据、Slack OAuth、Gmail OAuth2，配置表格ID与cooldown_days。

这次做成什么

搭建“每日读新订单→对基线算三类异常→冷却去重→Gemini风险评估→Slack+邮件+回写”的流失预警流程，并用合成订单验证命中、未命中、冷却三种路径。

准备什么

• Google Sheets服务账号凭据，且表格已共享给服务账号邮箱
• Google Gemini (Google PaLM) API凭据、Slack OAuth凭据、Gmail OAuth2凭据
• 一张含Orders_Ingest、Account_Baselines、Alert_Audit_Log三页签的表格，列含processed、account_id、last_alert_date等
• 持续运行的n8n实例（每日定时触发）

具体怎么做

1. 建三张页签

   Orders_Ingest列建议：order_id、account_id、rep_email、order_qty、order_date、core_sku_units、total_units、processed；Account_Baselines列：account_id、tier、avg_qty、avg_interval_days、core_sku_ratio、last_alert_date；Alert_Audit_Log列：audit_id、account_id、order_id、signals、risk_level、hypothesis、alerted_at。把表格共享给服务账号邮箱。

2. 接凭据与配置

   在n8n建Google服务账号、Gemini、Slack OAuth、Gmail OAuth2四组凭据；在工作流配置区填表格ID和cooldown_days（本站练习设14）。

3. 读单与关联

   定时节点每日2:00触发，读Orders_Ingest中processed为空的行，过滤无order_id的行；按account_id关联Account_Baselines，tier为Tier-3的账号直接忽略。

4. 计算三类异常信号

   用代码节点对每条订单计算：量异常（本次数量低于基线avg_qty的一定比例，练习设<60%）、节奏异常（距上次下单间隔超过avg_interval_days的1.5倍）、核心SKU占比异常（core_sku_units/total_units低于基线core_sku_ratio的70%）。只保留命中至少一条的订单。阈值为本站练习设定，原文未给具体数值。

5. 冷却与Gemini评估

   查该账号last_alert_date，距今小于cooldown_days则跳过。其余订单把订单字段加基线字段组成上下文送Gemini，用下方提示词要求返回结构化JSON。

6. 告警与回写

   向Slack频道发告警（账号、命中信号、风险级、假设、两条话术），用Gmail给该单rep_email发简报；向Alert_Audit_Log追加审计行；更新Account_Baselines的last_alert_date；把Orders_Ingest该行processed置为TRUE。

可直接复制的材料

你是B2B客户流失风险分析师。根据给定的新订单数据与该客户的历史基线（平均订货量、平均下单间隔、核心SKU占比）以及命中的异常信号，评估流失风险。只返回JSON：{"risk_level":"high|medium|low","primary_hypothesis":"一句最可能的原因假设","talking_points":["给销售的第一条沟通话术","第二条话术"]}。假设必须能从数据中找到依据，不要编造客户未提供的事实。

{"volume_drop_threshold":0.6,"cadence_stretch_factor":1.5,"core_sku_ratio_floor":0.7,"cooldown_days":14,"ignore_tiers":["Tier-3"]}

Orders_Ingest: {"order_id":"SO-9001","account_id":"AC-101","rep_email":"rep-li@example.com","order_qty":20,"order_date":"2026-10-08","core_sku_units":4,"total_units":20,"processed":""}
Account_Baselines: {"account_id":"AC-101","tier":"Tier-1","avg_qty":80,"avg_interval_days":30,"core_sku_ratio":0.75,"last_alert_date":""}

输入与输出示例

本站虚构演示，未实际调用Gemini、Slack或Gmail；节奏判定边界值是否算命中取决于比较符实现。

输入

上方合成订单SO-9001：数量20（基线avg_qty 80）、间隔45天（基线30天）、核心SKU占比0.20（基线0.75），last_alert_date为空

对应输出

命中信号：volume_drop(20<80×0.6)、core_sku_drop(0.20<0.75×0.7)；节奏45<30×1.5=45未命中。Gemini返回示意{"risk_level":"high","primary_hypothesis":"核心品类采购占比骤降，可能转向竞品","talking_points":["询问核心SKU补货计划是否延后","提供核心SKU组合优惠并约拜访"]}；Slack与Gmail各发一条，Alert_Audit_Log新增一行，last_alert_date更新为当日，processed置TRUE。

做完检查这些

• 未命中任何信号的订单不触发Gemini调用，仅被跳过或标记处理
• last_alert_date在14天内的账号即使命中信号也不重复告警
• Tier-3账号的订单被忽略且不写审计日志
• 每条告警订单在Alert_Audit_Log恰好一行，且Orders_Ingest对应行processed为TRUE

容易卡住的地方

• 原文说明表格需共享给服务账号邮箱，漏做会在读表时报权限错误
• 三类信号的具体阈值原文未给出，本页数值是本站练习设定，须自行校准
• 订单缺order_id的行会被过滤，数据源接入时先保证该列完整
• Gemini的假设只是基于数值上下文的推测，销售行动前需人工判断
• 每日2:00定时依赖n8n持续运行，实例停机当天无筛查