如果一个外部事件应该立刻启动流程，优先考虑 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，失败后都要知道谁收到提醒、是否重试、是否需要人工介入。
相关 Make 文档
第一版先从 帮助文档 入口继续查阅相关主题：
- Webhook
- 定时运行场景
- Operations 和 Credits
- Error Handling
下一步
如果你的场景是事件发生就处理，可以继续看表单线索自动化工作流。
如果你的场景是固定时间检查、汇总或报告，先从 schedule 设计开始，并估算运行频率和操作数。
如果你还不确定，先写下输入、输出、触发来源和错误处理规则，再决定触发器。
部分链接可能包含联盟推广链接。选择 webhook 或 schedule 应该基于场景，而不是为了使用某个功能。