Webhook 和定时触发，Make 场景应该怎么选？

如果一个外部事件应该立刻启动流程，优先考虑 webhook。

如果流程只需要每天、每小时或按固定周期检查一次，定时触发通常更简单。

这不是哪个更高级的问题，而是谁应该启动这个流程的问题。

Webhook 适合什么场景

Webhook 适合由外部事件主动触发的流程。

典型情况包括：

表单提交后立刻处理线索。
支付、订单、注册、预约等事件发生后触发流程。
上游系统能把数据主动发送到 Make。
团队希望接近实时地收到通知或处理数据。

Webhook 的优势是事件来了再运行，不需要 Make 一直定期检查。它适合有事发生就处理的场景。

但它也有前提：上游系统要能发送 webhook，或者至少能通过某种方式把事件数据送出来。

定时触发适合什么场景

定时触发适合按时间运行的流程。

典型情况包括：

每天早上生成日报。
每小时检查一次表格或系统里的新数据。
每周同步一次数据。
定期清理、汇总、提醒或发送报告。
上游系统没有 webhook，只能定期拉取。

定时触发的优势是容易理解，也更适合批处理。但如果你把运行频率设得太高，或者每次检查都要跑很多模块，就需要考虑操作数和成本。

不要急着选触发器的情况

如果你还说不清楚这个流程的输入、输出和下一步动作，不要先纠结 webhook 还是 schedule。

先问：

谁产生输入？
输入是什么格式？
结果要写到哪里？
出错后谁负责？
这个流程是否真的重复发生？

如果这些问题都不清楚，触发器选得再漂亮也没有意义。

决策树

是否有明确的外部事件？
否 -> 看是否适合定时触发。
是 -> 上游系统能否主动发送数据？
否 -> 可能需要定时检查或使用其他集成方式。
是 -> 是否需要接近实时处理？
是 -> 优先考虑 webhook。
否 -> 定时批处理也可能足够。

再检查一次成本和稳定性：

定时检查会不会运行太频繁？
是 -> 评估操作数，考虑 webhook 或降低频率。
否 -> schedule 可能更简单。

三个典型场景

场景 1：官网表单提交后通知销售

用户提交表单后，团队希望立刻收到 Slack 通知，并把线索写入表格。

这类场景更适合 webhook。因为触发点是表单提交，不是每天固定时间。

场景 2：每天早上生成运营日报

团队只需要每天早上汇总昨天的数据，并发送到 Slack 或邮件。

这类场景更适合定时触发。它不需要外部事件实时启动，只需要按固定时间运行。

场景 3：每 5 分钟检查一次订单异常

如果上游系统不能主动发送事件，你可能会用 schedule 定期检查。

但这里要小心：检查频率越高，流程运行次数越多，操作数和错误处理压力也会增加。如果异常不需要实时响应，可以降低频率；如果确实需要实时，应该重新评估 webhook 或系统集成能力。

常见错误

第一个错误，是把 webhook 当成更高级的默认选项。Webhook 适合外部事件触发，但不是所有流程都需要实时。

第二个错误，是用高频 schedule 模拟实时 webhook。这样可能增加操作数，也更容易产生无意义运行。

第三个错误，是忽略上游系统能力。如果对方系统不能发送 webhook，你需要选择可行的替代方式。

第四个错误，是没有错误处理。无论 webhook 还是 schedule，失败后都要知道谁收到提醒、是否重试、是否需要人工介入。

下一步

如果你的场景是事件发生就处理，可以继续看表单线索自动化工作流。

如果你的场景是固定时间检查、汇总或报告，先从 schedule 设计开始，并估算运行频率和操作数。

如果你还不确定，先写下输入、输出、触发来源和错误处理规则，再决定触发器。

部分链接可能包含联盟推广链接。选择 webhook 或 schedule 应该基于场景，而不是为了使用某个功能。