客户在表单里填完需求，按下提交按钮。接下来的一分钟，往往是一人公司最容易漏掉的一段：你把信息复制进表格，写一封确认邮件，再去任务清单里加一条待办。单次只花几分钟，但一周十几次，加上漏回、错回、重复回复，损耗就出来了。这篇面向准备开始或已经在做一人公司的创业者，目标很具体：把「表单提交」这一个动作，串成「确认邮件 + 任务创建 + 异常留痕」的基础流程，用 n8n 或 Make 都能搭，重点是配置思路而不是某个版本的界面细节。工具更新较快，下面的节点名称和菜单位置请以你所用版本的官方文档为准。

先看清楚要串起来的三件事

自动化不是把整个业务交给机器，而是把三个固定动作连起来：

1. 捕获：客户提交的表单数据进入自动化工具，成为一次执行里的结构化数据。
2. 分发：根据数据内容决定通知谁、写什么邮件、建什么任务。
3. 留痕：无论成功还是失败，都有一条可回查的记录，而不是静默消失。

一人公司的特殊性在于，你既是配置者也是最终用户。所以流程要满足两个额外要求：出问题时你能在五分钟内看懂哪里断了；不需要为了改一句邮件文案而重新学一遍工具。

触发条件：表单数据怎么进来

三种常见接法，按省事程度排序：

• 原生表单触发器：n8n 内置表单触发器，可以直接生成一个可分享的提交链接，适合内部收集或临时使用。
• Webhook 触发：表单工具（如 Typeform、Tally、金数据等支持 Webhook 的服务）把提交结果 POST 到自动化工具给的 URL。这是最通用的方式，n8n 里叫 Webhook 节点，Make 里叫 Custom Webhook。
• 定时轮询：每隔一段时间去读取表单后台新增记录。前两种能实时触发时就不用这个，只在对方不提供 Webhook 时使用。

配置时先做一件事：触发一次真实提交，把原始数据结构看清楚。字段名、嵌套层级、时间格式（有没有时区偏移）、多选字段是数组还是逗号分隔字符串，这些决定了后面每一处引用怎么写。很多「流程搭好了但不生效」的问题，根因都在这一步没看。

字段映射：把表单字段变成可复用的变量

不要直接在节点里写「表单里的那个邮箱字段」，而是先统一一层命名。下面是一人公司需求表单的常见映射：

表单字段	建议变量名	在流程里的用途
姓名	contact_name	邮件称呼、任务标题
邮箱	contact_email	确认邮件收件人、去重键
需求类型	request_type	分支判断依据
预算区间	budget_range	优先级与分支判断
需求描述	message	任务正文、人工复核材料
提交时间	submitted_at	记录与超时判断

映射时注意三件事：邮箱统一转小写再去重；时间统一转成同一时区再入库，否则会出现「今天提交、显示昨天」；长文本先截断到任务系统能接受的长度，原文另存一处，别让标题变成一整段话。

条件分支：不是所有提交都走同一条路

一条直线流程很快就会失控，因为客户提交的内容质量差别很大。典型做法是分三路：

• 合格需求：发确认邮件、创建任务、写入客户表、在协作频道提醒你。
• 待确认需求：字段不全或描述过于简短，只发一封「收到，我再补两个问题」的邮件，任务标记为低优先级。
• 明显无效：垃圾提交、测试数据、重复提交，直接归档到记录表，不打扰你。

n8n 用 IF 或 Switch 节点，Make 用 Router + Filter，逻辑是一样的。判断条件的写法可以抽象成这样：

条件 A：request_type 属于 ["品牌设计", "网站开发", "咨询"]
条件 B：budget_range 属于 ["3万以上", "5万以上"]
条件 C：contact_email 在最近 7 天内未出现过

A 且 C 且 (B 或 request_type = "咨询") → 合格需求
A 且 C 但不满足 B → 待确认需求
其余 → 归档

判断阈值不要凭感觉定，先用过去一个月的真实提过一遍，看看每一路各有多少条。如果「待确认」占了八成，说明你的判断条件太严，需要放宽，而不是继续加分支。

通知、任务与异常记录

这一层是最容易被写乱的部分，建议把「客户看到的」和「你自己看到的」彻底分开。

发给客户的确认邮件只做一件事：告诉对方收到了、大概什么时候回复、需要补充什么。内容用模板变量填充，不要试图在一封邮件里解决所有问题。建议不要用「no-reply」发件地址，一人公司的信任感往往来自对方能直接回复。

发给你的通知应该是可操作的：包含客户名、需求类型、一句话摘要，以及一个直达任务或记录的链接。纯「有新提交」的提醒看两次就会被忽略。

任务创建要落在你真正每天打开的工具里，而不是再建一个新系统。字段建议固定为：标题（客户名 + 需求类型）、正文（原始描述 + 联系方式）、截止时间、来源链接。

异常记录是整套流程里最值钱的部分。单独建一张表或一个频道，字段固定为：发生时间、触发来源、原始数据、失败节点、错误信息、是否已处理。n8n 的执行列表和 Make 的 History 都能看到失败执行，但那是工具视角的日志，不是业务视角的清单。把失败记录落到你自己的表里，才能回答「上周到底漏了几个客户」。

n8n 和 Make 怎么选

两者都能完成上面的流程，差异主要在使用方式和长期成本结构上：

维度	n8n	Make
上手门槛	概念清晰，但自托管需要一点服务器经验	可视化最直观，拖拽和连线反馈友好
复杂流程可读性	节点图清晰，适合分支较多的流程	场景面板对多分支的表达较紧凑，复杂后需要勤加注释
部署方式	可云端、可自托管，n8n 文档 提供各环境部署说明	以云服务为主，配置入口集中在 Make 帮助中心
成本结构	自托管主要成本在服务器与维护时间，云端按执行量计费	按操作数和套餐档位计费，分支多、循环多时消耗更快
调试体验	可单节点重跑、可查看每一步输入输出	每次执行的历史记录可视化好，便于定位数据在哪一步变形
适合谁	愿意碰一点技术、希望数据留在自己手里的独立开发者	不想管服务器、更看重快速搭起来看到效果的创业者

具体价格和免费额度变动频繁，配置前请直接查看两家官网的定价页，不要依赖二手对比文章里的数字。我的建议是：先用其中一个把上面的流程跑通，遇到明确的瓶颈（比如执行量费用上涨、必须自托管）再考虑迁移，不要一开始就同时学两个。

上线前测试清单

流程搭完不等于能用。下面这份清单建议逐条走一遍，全程用真实但可识别的测试数据：

• 完整填写并提交，确认邮件、任务、记录三处都在预期时间内出现。
• 故意留空一个必填项提交，确认流程不崩溃，并且落到异常记录里。
• 用同一个邮箱连续提交两次，检查去重逻辑是否生效，重复时是否只创建一条任务。
• 测试每个分支的边界值，比如预算刚好等于阈值那一档。
• 填一个格式错误的邮箱地址，看是报错中断还是被分支拦下。
• 提交一段超长描述和附件链接，确认任务标题没有被撑爆。
• 手动重跑一次历史数据，确认重复执行不会产生重复任务。
• 关闭再重新开启流程，确认开关状态和定时设置符合预期。
• 检查一次执行耗时，如果单次超过十几秒，想想是不是有可以合并的步骤。
• 表单里如果收集了个人信息，确认告知文案、存储位置和保留时间是清楚的。

跑完清单后别急着扩大范围，先自己用一到两周。这段时间里每周花十分钟看一次异常记录，把反复出现的问题修掉，比一次加十个新流程更划算。

维护成本和该保留的人工环节

自动化的长期成本不在搭建，而在维护。你要预留的包括：表单或工具的接口变更、邮件发件额度、任务系统的字段调整，以及你自己换工具时的迁移。因此建议把流程控制在「十步以内、分支不超过三条」，并给每个节点起一个一看就懂的名字。

最后一点边界要说明白：这套流程的目标是减少重复录入，不是实现无人值守。确认邮件可以自动发，但报价、承诺时间、方案判断这些环节，仍然应该由你亲手确认。把自动化用在「传递和记录」上，把判断留在自己手里，对一人公司来说才是可持续的用法。