Make 与 Zapier：我在两者上运行相同的自动化

我在同一周内在这两种工具上构建了相同的三步自动化：观察表单提交，通过 AI 调用丰富它，然后将结果推送到电子表格和 Slack 通道中。扎皮尔版本花了二十分钟。 Make 版本花了三个小时，看起来像意大利面条。有趣的是之后发生的事情，当我同时运行了一个月时。

扎皮尔获胜的关键是先发制人，而且比分并不接近。触发和操作模型意味着您选择一个源应用程序，选择一个目标，映射字段，然后它就可以工作了。 Make 是一种可视化编程工具 - 您可以构建包含模块、分支和转换的画布。这种力量是真实的，这也是为什么我的第一个 Make 自动化有一个映射错误，花了一个下午才找到。

然后账单就到了。 Zapier 按任务收费，任务大致是自动化执行的任何步骤，因此三步流程每次运行都会消耗三个任务。 Make 以更精细的粒度对操作进行计数，但出售慷慨的操作津贴，并且对于超出少数步骤的任何操作，差异并不是微不足道的。通过采用相同的逻辑，我每月的自动化成本下降了约三分之二。

我没想到的是相反的可靠性。 Zapier 的故障消息很明确，它的应用程序连接库非常庞大 - 我找到了我永远不会手动集成的工具的本机连接器。为我的两个应用程序制作所需的网络钩子和格式化程序步骤，这意味着我现在维护 Zapier 用户可以免费获得的代码。

因此，诚实的答案取决于谁在运行它。如果非技术人员拥有工作流程并且它涉及主流应用程序，则 Zapier 值得为连接器库和错误消息付出额外的费用。如果某个技术人员拥有它，工作流程有分支或循环，或者数量使每个任务的定价变得痛苦，那么就可以在成本和功能上取得胜利。重叠区域较小。

没有人写的迁移建议：不要为了使用更便宜的工具而迁移正在运行的 Zapier。当它开始花费真金白银时，或者当流程需要 Zapier 无法表达的逻辑时，请移动它。在那之前，您花费在重建上的时间比您节省的金钱更有价值。

常见问题：

问：Make 真的比 Zapier 便宜吗？

答：对于多步骤自动化，是的，并且差距随着复杂性而扩大。 Zapier 按任务计费，大致意味着按步骤计费，而按操作计费，包含更大的津贴。对于简单的两步流程来说，差异很小；对于分支工作流程则不然。

问：对于非技术用户来说，哪一种更容易？

答：扎皮尔，显然。触发和操作构建器不需要系统的思维模型，并且错误消息会告诉您发生了什么问题。 Make 假设您了解数据映射，并且会让您在晚上 11 点进行调试，而不会抱怨。

问：我可以将 Zapier 迁移到 Make 吗？

答：是的，但这是重建而不是出口。触发器名称映射，字段映射不映射。一次迁移一个工作流程，让旧工作流程并行运行一个月，然后让日志告诉您新工作流程是否实际上等效。