Confirmation决定提交后用户看到什么，Notification决定向谁发送什么邮件，两套条件可能分别配置。成功页面出现不能证明某个通知条件已满足，更不能证明目标邮箱已收到。
先画出提交后的分支
按业务写清不同选择应进入哪种确认方式、通知哪个部门和是否给客户回执。不要只有“提交成功”这一条统称。某些表单应跳转资料页，某些显示下一步说明，业务分流和邮件动作需要各自明确，才能发现规则缺口。
核对每份通知的启用与条件
查看当前通知状态、收件字段、智能标签及条件逻辑，确认选择值与规则真实匹配。复制通知后容易遗留旧部门、旧字段或互相矛盾的条件。不要因为主通知启用，就推断所有分支的独立通知也处于有效状态。
把确认内容写到已完成阶段
用户看到的说明应表达实际接收或下一步，不宣称销售已经审核、付款已结清或服务已交付。若后续动作可能失败，应有相应监测和处理，不让确认页掩盖接口问题。回执中的回复地址与内部通知也需按用途分别安排。
用分支矩阵验证
为每个选项组合准备非敏感授权样本，检查确认内容、通知日志和实际收件对象，包含没有匹配项的情况。避免一个选择触发两份不必要通知，或某条路径没有任何负责部门。测试流量从真实询盘分析中排除，保留分支结果而非仅一张成功截图。
关键区别
Confirmation：用户看到的反馈；不证明邮件已经发送。
Notification：按配置发送邮件；条件与启用状态独立查。
业务受理：后续真实处理；不能由成功页代替。
怎样确认处理到位
各业务分支都有正确反馈和负责通知，收件结果可核实，没有重复或漏发，确认文案不夸大完成阶段，测试样本不计入真实询盘。
容易误判的边界
本文不把所有未收件问题归为条件配置。条件满足后仍可能有投递故障，应沿实际发送链路继续核查，而非只改成功页面。
