SaaS 的推送通知自动化：5 个工作流蓝图

激活率的下滑在周一的增长评审会上被首次提出。百分之二十八。和上个季度一样。和再上个季度也一样。你的试用到付费转化率为 14%。你十二个月前的 NRR 是 108%，现在是 102%。董事会想知道发生了什么变化。什么都没变。这就是问题所在。

生命周期堆栈仍然运行着你去年构建的四条自动化推送通知。欢迎推送在注册时触发。产品导览推送在三天后触发。试用到期推送在第 12 天触发。流失预警推送在日活跃用户减半时触发。四个触发器，每个都在不同的冲刺中由不同的营销活动负责人设置，每个都指向同一个订阅者列表，没有一个知道其他触发器的存在。激活推送发送给已经激活的用户。试用到期推送发送给已经升级的用户。流失预警推送发送给实际上没有流失的用户——他们只是在度假。

这就是大多数中型 PLG 团队的 SaaS 推送通知自动化：四到六个断开连接的触发器，被包装成自动化，被当作营销活动列表而不是工作流图来处理。在过去十年里，PLG 剧本在产品方面的激活工作方面做得很好，而且大部分的轻松收益都来自于产品变更——入职流程重新设计、示例数据启动器、嵌入式清单。下一个十个百分点的激活提升和下一个五个百分点的 NRR 不在产品中。它们存在于生命周期团队本应拥有但从未完成构建的自动化层中。

本文将介绍该自动化层实际上应该是什么样子——工作流架构，而不是触发器列表——并提供五个 SaaS 工作流蓝图，包含时间、退出条件以及将每个蓝图转化为可辩护的条目的计算方法。

为什么您的 SaaS“自动推送通知”正在拖累 NRR

自动化这个词在 SaaS 领域所做的无功劳工作，与它在电子商务领域所做的相同。当大多数 SaaS 生命周期团队说“SaaS 的自动推送通知”时，他们的意思是指触发式推送通知：在事件发生时触发的单个通知，没有状态、没有等待、没有分支、没有退出条件。用户注册，欢迎推送触发。用户进入第三天，产品导览推送触发。用户试用期即将到期，试用期结束推送触发。每个触发器都是自己的管道，对其他任何触发器一无所知，也不知道用户在其生命周期中的实际位置。

工作流则不同。工作流是具有状态的多步旅程。它知道用户何时进入，他们目前在哪里，自进入以来他们做了什么，以及哪些条件会取消旅程。从试用到付费的工作流不仅仅是在试用期结束前三天发送一个通知。它在试用期结束前 3 天发送，等待一天，检查订户是否已升级，发送第二个案例研究触达，再等待一天，发送最后一个限时优惠触达，并在订户升级的瞬间退出工作流，无论他们处于哪个阶段。

最后一句是关键区别。触发器没有记忆。工作流有。如果您的升级提醒自动化在客户已经升级后仍然发送提醒，那么您就没有自动化。您只是有一个没有人告诉它停止的触发器。

对于一个中型市场的 SaaS 生命周期团队来说，这种区别决定了 NRR 是在增长还是在下滑。六个并行运行的触发器会产生六个相互干扰的渠道。五个协调运行的工作流为每个订户的每个生命周期阶段产生一次旅程，并进行分支和限制。关于这个关键词的首页搜索结果将问题框定为“发送哪种推送通知”，并以工具或模板列表的形式给出答案。这并不是生命周期经理在周一增长审查会议上提出的问题。问题是如何构建旅程。

SaaS 推送通知工作流的解剖

在蓝图之前，是词汇。SaaS 推送通知工作流由六种节点类型构建而成。一旦您了解了每种节点的作用，本文中的每个蓝图都将像图表一样易于理解，而不是描述。

开始。 入口点。START 节点定义了工作流如何被触发，可以通过订户事件（trial_signed_up、aha_moment_reached、usage_hit_80pct_of_plan_limit、dau_dropped_50pct）或通过在预定时间选择符合特定标准的订户的受众过滤器来触发。一个工作流只有一个 START。

等待。 延迟。等待节点会将订阅者在此点暂停指定的时间：几小时用于 aha-moment 恢复，几天用于试用到付费时机，几周用于扩展提醒。或者直到特定的日历时间。等待是工作流学会不进行一次性广播的方式。

决策。 双向分支。决策节点检查一个条件——订阅者是否已升级，他们是否邀请了队友，他们是否在过去 24 小时内触发了 aha-moment 事件，他们的 MRR 等级是否高于 99 美元——然后将他们路由到是路径或否路径。决策是工作流停止以相同方式对待每个试用用户的方式。

路径拆分。 基于百分比的分叉。路径拆分节点根据配置的百分比将订阅者路由到多个路径：试用到付费文案的 A/B 测试为 50/50，激活提醒的三向发送时间测试为 33/33/34。一旦您有了赢家，就将获胜路径提升到 100%，工作流将继续在已验证的变体上运行。

操作。 实际工作。操作节点发送推送通知，将订阅者添加到细分，更新他们的自定义属性，向您的 CRM 发送 HTTP 请求，启动另一个工作流，或停止一个。PushEngage Workflows 支持十一种操作类型。SaaS 中最常见的是 SendPushNotification、UpdateAttribute、HttpRequest（用于 CRM 和 Slack 升级）以及 Workflow.Start（用于链接生命周期阶段）。

结束 / 退出。 终点。结束和退出节点标记工作流完成并更新分析。结束是自然结论。退出通常用于在决策节点的否路径上提前终止，当订阅者不再符合条件时，或在目标达成时提前结束——订阅已升级，DAU 恢复到基线，aha-moment 已达到。

下面的每个蓝图都由这六个部分组成。

SaaS 的五个工作流蓝图

这些不是“剧本”。它们是可用的蓝图。每个蓝图都列出了其触发器、运行类型、节点序列、退出条件以及它旨在改进的 SaaS 留存指标。您可以直接将每个蓝图复制到 PushEngage Workflows 构建器 中，并在不到一小时的时间内发布第一个版本。有关每个蓝图的文案模式，旧的 SaaS 推送通知示例目录包含具体的消息格式；下面的蓝图是这些消息串联成序列的旅程架构。

蓝图 1 — 激活系列（SaaS 入职推送通知自动化）

• 触发器 (开始)： 自定义事件 trial_signed_up
• 运行类型： 单次（每个订阅者每 90 天窗口一次激活旅程）
• 流程：立即发送欢迎推送（价值陈述，而非功能罗列）→ 等待 1 小时 → 发送以一个具体的第一步功能为重点的产品介绍推送 → 等待 24 小时 → 决策：订阅者是否已达到“啊哈时刻”事件（first_invoice_sent、first_dashboard_created、first_teammate_invited — 取决于您的产品定义的第一价值）？→ 是：发送祝贺推送并附带软升级提示，添加到 activated 分段，结束 → 否：操作 Workflow.Start 链接到蓝图 2（啊哈时刻恢复），结束
• 退出标准：目标 subscription_upgraded（一旦付费，不再发送激活消息）
• SaaS 指标：第 7 天的激活率。24 小时决策门是试用期中最具杠杆作用的时刻 — 在此门之前用户在探索，在此门之后他们要么已接受要么在流失。对于前两次触达的文案，入门推送通知模板目录中包含了那些持续有效的模板。

蓝图 2 — 顿悟时刻恢复

• 触发器（开始）：来自蓝图 1 的 Workflow.Start，或受众筛选器 trial_signed_up_more_than_24h_ago AND aha_moment_not_reached
• 运行类型：单次
• 流程：定向推送，指出订阅者卡住的确切步骤（“看起来您还没有创建第一个仪表板 — 这里有一个 60 秒的演练”）→ 等待 12 小时 → 决策：是否已达到啊哈时刻？→ 是：操作 Workflow.Start 返回蓝图 1 的祝贺分支，结束 → 否：发送“需要演练吗？”推送并附带日历链接 → 等待 24 小时 → 决策 → 如果仍然没有，操作 HttpRequest 到客户成功 Slack 频道，标记用户以便人工跟进，结束
• 退出标准：目标 aha_moment_reached 或 subscription_cancelled
• SaaS 指标：首次价值实现时间。对于 PLG 产品，7 天内的 TTFV 是试用到付费转化率最强的单一预测指标。啊哈时刻恢复工作流是将 TTFV 从“用户自行达到的任何地方”拉到“引导性提示可以带到的地方”的杠杆。

蓝图 3 — 试用到付费转化（试用到付费推送通知序列）

• 触发器（开始）：自定义事件 trial_ends_in_3_days
• 运行类型：单次
• 流程：试用即将结束推送（价值回顾，无折扣）→ 等待 1 天 → 决策：是否已升级订阅？→ 是：退出 → 否：试用到期前一天推送，附带客户案例研究链接 → 等待 1 天 → 决策 → 是：退出 → 否：最后一天推送，附带限时年付折扣 → 结束
• 退出标准：目标 subscription_upgraded，与触发事件上的 trial_id 匹配。订阅者升级的那一刻 — 在工作流的第 6 小时、第 30 小时或第 70 小时 — 该工作流将为该订阅者取消，剩余的触达将永不发出。
• SaaS 指标：试用到付费转化率。这是收入线最可辩护的工作流。数学计算在下面的留存部分进行，但作为方向性参考：在每月 99 美元的套餐中，每月 2,000 次试用，试用到付费转化率每提高 1%，大约可增加 237,000 美元的 ARR。

蓝图 4 — 扩展/升级提示

• 触发器（开始）：自定义事件 usage_hit_80pct_of_plan_limit（订阅者、席位、API 调用、项目 — 取决于您的套餐计量方式）
• 运行类型：多个顺序（每个账户一次一个扩展旅程；如果他们再次达到阈值，下个季度将触发新的实例）
• 流程：等待 1 天（不要在阈值触发的瞬间触发；让用户完成他们正在做的事情）→ 显示使用情况预览的软性推送 → 等待 5 天 → 决策：是否仍为 80% 以上？→ 是路径：在下一个套餐级别提供以 ROI 为锚的推送和客户案例研究 → 等待 7 天 → 决策：订阅是否已升级？→ 是：退出 → 否路径：操作 HttpRequest，为客户成功外展在账户负责人处创建 CRM 任务 → 结束
• 退出标准：目标 subscription_upgraded。在 subscription_cancelled 时也退出（这会成为蓝图 5 处理的流失信号）。
• SaaS 指标：NRR 贡献。扩展收入是定义 SaaS 估值的指标；升级提醒工作流是将计量使用情况信号转化为扩展 ARR 的自动化杠杆，然后账户才不得不在续订时做出决定。

蓝图 5 — 流失预防

• 触发器（开始）：受众过滤器 dau_dropped_50pct_over_14d AND subscription_active
• 运行类型：单个（每个订阅者每 90 天窗口一次防流失尝试）
• 流程：重新参与推送，显示订阅者从未使用的功能 → 等待 5 天 → 决策：DAU 是否已恢复到基线水平？→ 是路径：添加到 re-engaged 分段，退出 → 否路径：操作 HttpRequest，为 CS 负责人创建 CRM 任务 + 发送“我们能做得更好吗？”反馈推送，包含一个问题的调查 → 结束
• 退出标准：dau_returned_to_baseline 受众条件。在 subscription_cancelled 时也退出 — 无论哪种情况，工作流的任务都已完成。
• SaaS 指标：净流失率。HttpRequest 到 CRM 的升级是 SaaS 特有的元素：当算法恢复失败时，工作流不会放弃。它会将账户交给人工 CS 代表，并预先填充相关信息。

关于 Blueprint 5 的触发器，有一点需要注意。这是此处唯一一个使用基于受众的触发器而非基于事件的触发器的蓝图。基于受众的触发器仅在工作流开始时批处理匹配的订阅者集。工作流开始运行后变得不活跃的订阅者不会自动包含在活动实例中，并且编辑活动工作流上的受众过滤器不会添加新订阅者。如果您想要一个持续的客户挽留计划，请每周或每月安排复制工作流，而不是期望一个长期运行的受众工作流持续摄取新的风险订阅者。

生命周期阶段细分、A/B 测试和退出条件存在于工作流内部

这三个概念中占主导地位的 SaaS 营销模式是将它们列为“最佳实践”——文章末尾的通用要点，脱离了使用它们的工作流。这是错误的框架。它们不是与工作流并列的最佳实践。它们就是工作流。

概念	最佳实践框架（错误）	工作流节点框架（正确）
生命周期阶段细分	“按试用/激活/付费/有风险细分”	一个 DECISION 节点，用于检查 lifecycle_stage（或根据 MRR + DAU + last-active 计算得出），并将付费用户路由到扩展，将有风险用户路由到客户挽留，将试用用户路由到试用到付费
A/B 测试	“始终对试用结束的文案进行 A/B 测试”	一个 SPLIT_PATH 节点，具有 50/50 的分配比例，每个路径的负载均衡订阅者，以及一个 winner_edge_id 字段，一旦测试达到显著性，就会将获胜者提升到 100%
静默时段	“不要在凌晨 3 点发送”	一个工作流级别的选项，包含 start_at、end_at、timezone 和一个 fallback 设置，该设置可以 skip 发送或将其 reschedule 到安静时段结束后一分钟——这对于全球 B2B 团队至关重要，因为在同一个计划中，首席财务官可能在伦敦，而开发负责人可能在新加坡
退出条件	“停止向已升级的用户发送消息”	一个工作流级别的规则，在每个节点之前检查订阅者是否符合受众过滤器或触发目标，并在匹配时取消工作流

区别很重要，因为最佳实践要点很容易被认可但难以执行。工作流节点由引擎本身强制执行。DECISION 每次都会运行。SPLIT_PATH 会平衡每个订阅者。静默时段回退会在没有人记得检查时间的情况下进行。退出规则会在营销活动所有者是否留意的情况下取消工作流。

对于上面的试用到付费蓝图，这意味着在订阅者升级的那一刻——在工作流的第 6 小时、第 30 小时或第 70 小时——退出规则就会触发，工作流就会为该订阅者取消，并且剩余的触达将永远不会发出。不会向昨天已经升级的人发送“您还有一天时间升级”的推送。也不会让首席财务官在 Slack 上询问账单是否已成功处理。

SaaS 的多渠道推送通知：Web 推送、App 推送、应用内消息、电子邮件和 Slack/CRM

对于SaaS而言，渠道广度问题有不同的呈现方式，而对于电子商务而言则不然。B2B PLG团队关注的渠道不仅仅是推送和电子邮件。它们包括：Web推送（用于Web应用程序）、应用内推送（用于移动应用程序SaaS）、应用内消息（用于产品界面内部）、电子邮件（作为未订阅推送时的备用选项），以及当需要人工介入时，通过HTTP请求升级到Slack或HubSpot/Salesforce。五种升级渠道，如果工作流引擎支持，都可以在一个工作流中组合。

一个组合的“啊哈时刻”恢复流程是这样的：

• 开始： trial_signed_up 事件
• 等待 24 小时
• 决策： 订阅者是否已达到“啊哈时刻”事件？
  • 是：退出（激活成功，路由到蓝图 1 的祝贺分支）
  • 否：继续
• 决策： 订阅者当前是否登录了Web应用程序？
  • 是：操作 — 发送应用内消息（摩擦最小的渠道，尚不需要升级）
  • 否：继续
• 决策： 订阅者是否已订阅Web推送？
  • 是：操作 — 向遗留步骤发送Web推送
  • 否：操作 — 发送相同内容的电子邮件
• 等待 12 小时
• 决策： 现在是否已达到“啊哈时刻”？
  • 是：退出
  • 否：操作 — 向客户成功Slack频道发送HTTP请求，并将该账户分配给一位CS代表
• 结束

一个订阅者身份，一个工作流，五种升级渠道。成本最低的可行渠道优先：应用内消息（在产品内部时），然后是推送（如果已订阅），然后是电子邮件（如果未订阅）。成本最高的人工客服时间放在最后，仅当算法恢复明显失败时才使用。有关渠道权衡的更深入讨论，请参阅推送与应用内通知的比较，其中详细介绍了每种渠道的成本和个性化计算。

使用单独的工具执行相同操作意味着平台之间有六次同步，两个细分引擎对“风险用户”的定义不一致，并且由于每个工具都报告自己的转化次数，因此无法进行单一的收入归因。在单个工作流引擎中执行此操作意味着一个订阅者身份，一套决策逻辑，以及一个显示旅程实际中断位置的漏斗报告。应用内通知示例目录涵盖了在此编排模型中效果最佳的应用内界面。

这是与此关键词的页面搜索结果中没有可比性的差异化因素。所有排名靠前的结果都将推送视为一个渠道，并将电子邮件作为比较对象。没有一个描述了SaaS工作流的真正多渠道推送通知，其中单个触发器可以像一个具有共享退出标准的旅程一样，跨Web推送、应用内消息、电子邮件和人工客服升级进行路由。

NRR 计算：每个工作流、每个渠道、每个生命周期阶段的收入

无法在下次 QBR（季度业务回顾）中证明其价值的工作流将被淘汰。生命周期管理者的职责是展示每次自动化产生了多少美元收入或 NRR（净收入保留率）点数。大多数关于 SaaS 自动推送通知的文章都止于打开率。这还不够。正确的指标是每个工作流增加的 MRR（月度经常性收入）、每个季度的 NRR 变化以及每个用户群的净客户流失减少量。

PushEngage 工作流在每个节点跟踪三个数字：

• 排队用户：目前在此节点等待的订阅者（通常是等待或静默时段重新安排）
• 已完成用户：已通过此节点的订阅者
• 已退出用户：在此节点离开工作流的订阅者，原因可能是满足退出条件或取消了订阅

以下是一个针对活跃试用到付费的推送通知工作流的节点级分析示例，该工作流适用于每月 2,000 次试用的 PLG SaaS 公司，月度套餐为 99 美元（示意性数字）：

节点	排队中	已完成	已退出	备注
开始（试用到期前 3 天）	0	2,000	0	所有匹配的试用用户进入
操作：试用到期前推送	0	2,000	0	已发送通知
等待 1 天	38	1,710	252	252 名订阅者在第一次触达后升级（仅触达转化率为 12.6%）
决策：订阅已升级	0	1,710	0	1,710 人未转化
操作：明天到期 + 限时折扣	0	1,710	0	已发送通知
等待 1 天	24	1,510	200	另外 200 人升级（额外转化 10%）
操作：最后一天 + 限时折扣	0	1,510	0	最后触达
结束	不适用	1,510	不适用	1,510 人未升级

在此用户群中，有 452 个试用用户在工作流中转化为付费用户（共 2,000 个），转化率为 22.6%，这是由工作流的三次触达驱动的。按每月 99 美元的套餐计算，每个用户群增加了 44,748 美元的 MRR，如果用户群规模保持不变，则每年约增加 537,000 美元的 ARR。两次等待（第一次触达和第二次触达）是漏斗中退出率最高的节点，这符合预期模式：升级决策落在等待窗口内，而不是操作窗口内。如果您的工作流显示相反的情况——操作节点退出率高，等待节点退出率低——则您的触达发送得太晚了，应该缩短等待时间。

成本计算方式与电子商务类似，只是增加了特定于 SaaS 的渠道。网页推送和应用内消息在用户选择加入后免费发送。电子邮件的成本取决于您的 ESP 合同（Customer.io、Iterable、Klaviyo）——对于一个拥有 50,000 名订阅者的 SaaS 列表，单次试用到期发送的每次触达成本通常在几百美元以内。另一方面，人工客户成功服务需要真金白银：一名客户成功代表处理一次 10 分钟的 Slack 升级请求，其年薪（包括所有福利）为 90,000 美元，则每次升级成本约为 7.50 美元。工作流的职责是首先使用最便宜的可行渠道，仅在情况需要时才升级。当明细项目显示“试用到付费工作流在上一个用户群中以每用户群 312 美元的总成本挽回了 44,748 美元的 MRR”时，QBR 的讨论将非常简短。

在 PushEngage 工作流中为您的 SaaS 构建它

五个 SaaS 蓝图中的每一个都直接映射到 PushEngage 工作流组件。映射表：

蓝图	使用的节点类型	使用的操作类型	工作流选项
激活系列	开始、等待、决策、操作、结束	SendPushNotification, AddSegment, Workflow.Start	运行类型：单次
惊喜时刻恢复	开始、等待、决策、操作、结束	SendPushNotification, HttpRequest, Workflow.Start	运行类型：单次
试用到付费转化	开始、等待、决策、操作、结束	发送推送通知	运行类型：单次；在目标 subscription_upgraded 处退出
扩展/升级提醒	开始、等待、决策、操作、结束	SendPushNotification, HttpRequest	运行类型：多次顺序
防止客户流失	开始、等待、决策、操作、结束	SendPushNotification, HttpRequest, AddSegment	运行类型：单次；基于受众的触发器

工作流引擎附带 60 多个现成模板，涵盖了所有这些流程。电子商务模板（欢迎、购物车放弃、挽回客户）可以通过交换触发事件和退出条件目标，清晰地转化为 SaaS。欢迎模板成为 SaaS 入门推送通知自动化的基础 — 激活系列、惊喜时刻恢复以及 Blueprint 1 的其余下游链。购物车放弃模板逻辑通过将 cart_abandoned 替换为 trial_ends_in_3_days，并将 purchase 替换为 subscription_upgraded，成为试用到付费逻辑。该架构是垂直无关的；改变的是词汇。

要更全面地了解 PushEngage 如何适应 SaaS 用例 — 定价、集成、客户示例 — SaaS 版 PushEngage 是标准登陆页面。对于即时试用路径：免费套餐为您提供 200 个订阅者，所有渠道（网页推送、应用推送、WhatsApp、实时聊天），以及第一天即可使用的完整工作流引擎。这足以在您的下一个用户群上发布试用到付费蓝图，并在下一个 QBR 中获得可观的月度经常性收入数字。

这改变了什么

如果您从本文中只记住一件事，那就是：SaaS 的推送通知自动化是工作流架构，而不是营销活动列表。以升级为退出的试用到付费旅程、链接到惊喜时刻恢复的激活系列，以及仅在算法恢复失败时才升级到人工客服的跨渠道编排，都具有相同的形状。一个开始、一些等待、一些决策、一些操作、一个退出。四个独立的触发器无法做到这一点。一个工作流引擎可以。净收入数学将从那里开始复利。

从免费套餐开始，在您的下一个试用用户群上发布第一个蓝图。