表单后台已经能看到这条询盘，邮箱通知有时也到了，但 CRM 里没有新线索，或线索在了却没有渠道、落地页、关键词，广告和内容的效果就对不上。这和已经写过的「表单显示提交成功但收不到邮件」「询盘箱被秒填垃圾信刷屏」「开了 Cloudflare 后询盘一直转圈或提交失败」不是一类故障。那些专文分别处理发信链路、垃圾提交和安全防护误伤；本文锁定 提交已经进站、却进不了业务系统或来源字段是空的：看起来有询盘，但销售侧看不到，或看到了也无法复盘是哪条渠道来的。
更稳的顺序是：先分清是「接口根本没发出去」「发出去被拒」「字段没映射」还是「被去重/分配规则吃掉」→ 把推送接口、鉴权和隐藏来源字段一次核对通 → 再查去重与分配，并留下抽检记录。别先改表单文案或加更多字段，也别把「后台有记录」当成已经进入 CRM。
先分清：没发出 / 被拒绝 / 字段对不上 / 被去重或分错人
「后台有记录、业务系统没有」至少有四条岔路，混着查会在投放复盘时浪费一整天：
- 推送根本没触发：表单保存了提交，但 Webhook、接口或同步插件未启用，或只在测试表单上配过、正式表单是另一份配置。
- 发出去了但被对端拒绝：地址写错、密钥过期、签名不对、对端要求 HTTPS 或特定 Header，接口日志里是 401、403 或 4xx/5xx，重试队列一直失败。
- 进了系统但字段对不上：姓名、联系方式、需求进了，UTM、来源页、表单名称是空的，或全部挤在备注里。常见原因是隐藏字段没写入、字段名和 CRM 对不上，或页面缓存导致隐藏字段还是旧值。
- 进了又被去重或分错人：对端按联系方式合并到旧线索，把新渠道覆盖掉；或分配规则按旧字段分流，新单进了无人值守的分组。
先记下：最近一条成功提交的时间、表单后台是否有记录、推送日志是成功还是失败状态码、CRM 里能否按提交时间搜到、来源/UTM/落地页是否为空、是否被合并到更早的线索。明确这是 出站同步与归因 问题，不是 SMTP 收不到信，也不是防火墙把表单 POST 拦了。
第一步：定界 ------ 提交在不在、接口有没有出、对端收到了什么
不要先重装表单插件，更不要先把去重规则全部关掉。先把链路看清楚：
- 表单后台有没有这条记录：有记录说明提交本身成功，问题在出站同步；没记录应先回到提交失败、缓存或防护误伤的排查，而不是先改 CRM。
- 推送有没有实际发出：看表单插件或中间件的 Webhook / 接口日志，是「未配置」「未触发」，还是已经 POST 出去。测试表单和正式表单要分开看，避免改错一份配置。
- 对端返回了什么：成功、4xx、5xx、超时还是签名失败。把请求 URL、HTTP 状态和返回摘要留下来，不要只看插件上的绿色勾。
- CRM 侧按时间搜：用提交时间或联系方式搜索，包括回收站、合并记录和未分配队列。有时不是「没进去」，而是进了被合并或进了别人看不到的分组。
- 来源字段是不是空的：若线索在但 UTM、来源页、表单名为空，先进入第二步把隐藏字段和映射修好，再谈报表。
预期：能一句话说清「这条提交在表单后台、推送日志和对端分别处于什么状态」；并确认不是发信失败、垃圾拦截或 Cloudflare 误伤的重复文章。
第二步：把推送接口和隐藏来源字段一次打通
定界之后，先让「下一份提交」能完整进系统，再处理已经丢了的字段：
- 只保留一条出站链路：同一张表单不要同时开多个互相覆盖的 Webhook 或同步插件。目标 URL、密钥、重试次数写在可交接的说明里，测试环境和生产环境分开。
- 用真实提交做一次联调：不要只在插件里点「发送测试」。走一遍正式表单（含广告参数进入的落地页），对照推送日志和对端新建记录。
- 隐藏字段要在提交当下写进去：至少覆盖渠道来源、投放参数、来源页和表单名称。字段名与 CRM 侧一一对应，不要指望对端从整段备注里再拆。
- 提防页面缓存把隐藏字段冻住：表单页若被整页缓存，隐藏的来源值可能是缓存生成时的空值或旧值。表单页应排除页面缓存，或改为提交时由服务端读取实际来源。
- 改完立刻抽检：从带参数的入口再提交一次，确认 CRM 新建记录里来源完整，且不是测试数据覆盖了映射。
涉及把表单线索送进业务系统和补齐来源字段时，可对照 WordPress 表单线索把推送接口、来源字段和 CRM 打通的要点 把「提交可回溯渠道、接口可到达、记录能被负责人看到」从清单里单独勾掉：先保证下一份提交能完整进去，再处理去重与分配------顺序反了会在对端把新线索合并丢来源后再去改字段，现场更难对。
预期：正式表单的下一次提交能在 CRM 新建可见记录；来源、落地页和表单名称不再是空；推送日志与对端状态一致。
第三步：查去重、分配和无人值守队列
接口通了之后，还要防止「进去了但销售看不到，或新渠道被旧线索吃掉」：
- 看合并规则：按邮箱或联系方式自动合并时，要确认新提交的来源、投放参数和表单名称是追加，而不是覆盖成空、或只保留最早一次渠道。
- 看分配规则：按地区、产品线或表单类型分流时，新字段名变了、选项值变了，就会进默认分组或无人负责的队列。用最近一次真实提交核对负责人是否就是规则里的那个人。
- 补齐失败重试，而不是再手工抄一遍：失败队列要能重放，并且以表单后台记录为准，避免人工补录时丢掉来源。已经进系统的旧线索，来源空了就按当时日志补，不要用今天的测试参数去改写。
- 权限要能被实际跟进人看到：记录进了系统但角色看不到该分组，表现也是「CRM 里没有」。核对该条线索的所属分组、跟进人和只读范围。
- 留下抽检样本：保留「带参数进入 → 提交 → 日志成功 → CRM 可见 → 来源完整 → 分配正确」的一组例子，换主机、改表单或改 CRM 字段后按同样路径再走一遍。
预期：新提交不会被旧线索默默合并到丢失来源；负责人能在自己的队列里看到；失败记录可按原单重放。
第四步：验收与回滚
- 表单后台最近一次真实提交，在推送日志里是成功而不是「未触发」。
- CRM 能按提交时间搜到对应新记录，所属分组和跟进人正确。
- 来源、投放参数、来源页、表单名称均有值，且与实际入口一致。
- 用同一邮箱再提交一次（如业务允许），确认是追加来源而不是把旧渠道清空。
- 留下回滚说明：改接口地址、密钥或映射前，先保留旧的成功配置；新链路连续成功后再停用旧链路。不要同时开两条互相覆盖的出站配置。
预期：主路径「后台有记录 → 推送成功 → CRM 可见 → 来源完整 → 分配正确」稳定；与 SMTP 发信、垃圾防护、Cloudflare 误伤备忘分开存档。
验证
- 从一条带投放参数的落地页再提交一次，核对 CRM 里的渠道和来源页不是空，也不是缓存里的旧值。
- 人为让对端返回失败（例如临时错误密钥），确认日志记下失败且表单后台记录仍在，修复后可重放。
- 抽查无人值守分组和已合并线索，确认没有新单静默堆在那里。
- 复查 24h：新提交持续进入，来源字段不再批量空白，生产表单没有被测试配置覆盖。
常见坑
- 只在测试表单上配了推送，正式表单另有一份未启用的配置。
- 插件显示成功，其实对端返回了 401 或字段校验失败。
- 隐藏的来源字段被页面缓存冻成空值，线索在了却无法复盘渠道。
- 按联系方式合并时覆盖了新的来源，投放效果看起来一直是「直接访问」。
- 分配规则还在用旧的表单名称或产品字段，新单全部进了默认分组。
- 同一张表单同时开两条出站同步，互相覆盖或重复建单。
- 把「邮件通知收到了」或「表单后台有记录」当成已经进入 CRM。
- 用手工补录代替失败重放，来源和提交时间对不上原单。
按「定界提交与接口状态 → 打通推送和隐藏来源字段 → 核去重与分配并留下抽检 → 验收回滚」这条线走，大多数「询盘有记录却进不了业务系统、或进去了也丢来源」的问题，能在一个维护窗口内收敛。需要处理发信失败或防护误伤时，应另走对应专文，而不是在同步链路上继续加字段。