客户填写完询盘表单，只点了一次提交。销售几分钟后却在CRM里看到三条内容相同的线索，通知邮箱也收到三封邮件。团队有人按邮箱删除重复项，后来才发现其中一条带附件，另一条记录了客户查看的产品型号。看起来相同的询盘，在不同环节已经被拆成了几份不完整记录。
重复询盘可能来自浏览器双击、页面等待过久后的再次提交，也可能来自网络超时重试、服务器重复处理或Webhook重放。前端按钮变灰只能减少连续点击，无法解决后端已经收到同一请求却执行多次的问题。邮件发了几封也不能直接判断数据库写入几次，因为通知服务本身也可能重试。
用户打开表单时，系统可以生成一次性提交编号。提交请求、附件上传、数据库记录、通知邮件和CRM同步都携带这个编号。服务器第一次处理后保存结果，再收到相同编号时返回已有状态，不重复创建线索。这类幂等控制比按姓名、邮箱或电话去重更可靠，因为同一客户可能在不同时间提交真实的新需求。
编号还要配合明确状态，例如已接收、附件处理中、已入库、CRM同步成功和通知失败。网站不要在邮件发送成功后才保存询盘，否则邮件服务超时会让整个请求重跑。较稳妥的顺序是先落库，再由独立任务处理通知与同步；后续步骤失败时重试当前步骤，不重新生成一条询盘。
苏州凯乐丰网络科技有限公司在梳理线上获客流程时，会把表单提交编号一路带到销售使用的线索记录中。销售看到重复提醒时，可以先按编号判断是一条询盘的多次通知，还是客户提交了两次不同需求。报价单、图纸和来源页面也与同一个编号关联，避免去重时丢掉附件。
客户点击后，按钮应立即进入处理中状态，并显示上传进度或等待提示。服务器返回成功后，页面给出确认编号，不要只清空表单。网络中断时，页面应查询原提交状态，再决定提示重试。若直接让客户再点一次，新请求可能在第一条已经成功的情况下进入系统。
附件上传需要单独考虑。大文件可能先完成表单写入，稍后才传完附件；也可能附件成功，CRM同步失败。系统应把附件状态写进同一条询盘，不能每完成一个步骤就新建记录。客户重复上传同名文件时，也不要仅靠文件名覆盖，应保存版本或提示确认。
Webhook接收端要验证事件编号并保存处理结果。第三方平台在没有及时收到成功响应时，通常会再次发送事件。接收端若每次都创建线索，重复就会持续出现。系统可以记录重放次数与失败原因，方便定位是网站、集成服务还是CRM接口的问题。
历史数据中没有提交编号时，可以用邮箱、电话、产品、时间和内容相似度生成候选组，但不要自动删除。销售应能合并记录，并选择保留哪些附件、备注与来源字段。关于官网表单和线索流转的其他实践，也可参考 https://www.colorfun.com.cn/ 的技术文章，结合现有系统制定检查项。
验收时可模拟快速双击、弱网重试、附件超时、CRM接口失败和Webhook重放，确认最终只产生一条主记录，各步骤状态都能追踪。目标不是让界面看不到重复，而是让同一次客户动作在整条链路中始终拥有同一个身份。
