客户说发了询盘却没收到？从表单记录查到邮件和负责人

先查后台有没有这条询盘

客户说已经填过表单，先给他一个可用的备用联系方式，再请他提供大致提交时间和产品页面。自己同时查后台记录、发信日志和收件箱。没有证据时，不先认定是客户没点成功，也不要让对方反复上传同一份资料。

后台有记录，重点查后续通知与跟进；后台没有记录，再看表单请求、保存过程或记录归属。页面显示“成功”只是一个提示，不能单独证明整条流程都完成了。

用一次标明测试的提交找到断点

打开正式产品页，用允许使用的测试资料发起询盘，留言注明“内部测试，请勿当作客户需求”。记录提交时间、页面反馈、后台出现时间和邮件状态。不要为了测试发送真实客户图纸或私人信息。

表单有反馈，但后台没有记录

在浏览器网络面板中看实际提交请求。HTTP 200也要结合返回内容判断；前端不能在接口拒绝或超时后仍显示成功。检查必填项是否清楚、手机号和邮箱规则是否误伤，以及人机验证或限流是否给正常访客留下恢复办法。

后台查询还要确认项目、时间范围和状态筛选。能看到另一条测试询盘，不代表客户那条也保存过。若原系统只发送邮件而不留可追溯记录，就缺少这一步证据，应先补可靠的接收记录或等效机制。

后台有记录，但没有通知邮件

查通知使用的收件地址、发信配置和发送结果。服务商接受了发送请求，后续仍可能延迟、退信或进入隔离。保留消息标识、时间和错误类别，交给负责该链路的人追查；日志中不要传播完整客户留言、令牌或附件。

另外分清两个地址：通知的From是发件身份，Reply-To决定销售点“回复”时发给谁。不要把客户填写的任意邮箱直接当成自己有权使用的From；回复目标也应经过输入校验，避免业务员回复到无人值守地址。

发信记录正常，再查邮箱认证与收件策略

查看实际邮件的Authentication-Results，核对SPF、DKIM和DMARC结果及所用域。DMARC关注可见From与通过认证的域是否对齐，不要求通知的收信邮箱必须和公司网站同域。个人邮箱能接收通知，也不能据此判断发信认证已经正确。

SPF、DKIM和DMARC配置应按发信服务与DNS的实际设置处理，具体步骤见询盘邮件认证配置说明。不要因为一封邮件漏收，就未经盘点替换所有DNS记录。

Gmail发信人要求分别列出所有发信方和批量发信方的条件。发送量小也有基础认证等要求；不能把Google、Yahoo和Outlook的阈值与退订规则合并成一套，更不能从“工厂站”推断发送量必然低于门槛。根据实际收件平台、域名总量和邮件类型核对。

邮件到了，也要确认有人接手

检查通知是否进入离职人员邮箱、无人查看的文件夹，或被自动转发到不再使用的地址。安排主要负责人和替补，并让后台记录能够看出处理状态，避免几个人都以为对方已经回复。

如果使用NeoGress，先按真实产品和时间核对后台询盘，再测试通知接收。网站生成、表单可见、询盘保存和销售回复是不同环节，不能只验收页面上的按钮。上线时就走完这条路径，后续漏收更容易找到具体问题。

修复后再走一次相同路径

用同一产品、同类资料重新提交，确认保存、通知、收件与跟进都能完成。再覆盖一次失败情况，例如必填信息缺失时能否改正、邮件延迟时是否仍能找到记录。跨境客户遇到的问题，尽量补测相关地区的真实访问路径，并记录测试条件。

以后改表单、换发信服务、调整域名或邮箱规则时重新测试。例行检查频率按业务量与风险安排，不必把固定天数当成所有企业的标准。测试结束后按权限和保留规则处理测试记录。

常见问题

客户没有成功截图，还能查吗？

可以先用大致时间、产品和经授权的联系方式查记录。结果不完整时明确说明尚未定位，并提供备用沟通渠道，不把缺少截图当作客户没有提交的证据。

通知发给多人更可靠吗？

可以减少单人缺席的影响，但要控制客户信息的接收范围，并指定谁负责。多人收到不等于有人处理。

认证通过，为什么仍进垃圾箱？

认证只是收件方判断的一部分。域名信誉、内容、投诉、收件方规则和转发过程仍可能影响处理。继续查具体投递结果，不能据认证通过保证送达收件箱。