访客点击提交后，最需要确认的是需求有没有保存、企业接下来怎样处理，以及如果发现漏项该怎么办。表单提交完成页若只显示一个绿色图标，可能无法回答这些问题；若写满“马上联系”“已安排专家”，又可能表达系统尚未完成的动作。
完成提示应该依托真实结果。先分清保存成功、通知发送与人员处理，再决定页面展示什么。设计漂亮的回执，不能替代实际记录，也不能把计划中的后续流程写成已经发生。
保存、通知和人工处理是三个事实
需求保存成功，表示服务器已形成可以查询的记录。通知发送是把新需求提醒给相关人员，可能在保存后发生；工作人员查看和联系则属于业务处理。三个阶段可以紧密衔接，但不宜合并成一个笼统的“全部完成”。
例如，假设系统已保存需求，邮件通知随后失败，访客不应该因为邮件问题被引导再次提交一份相同需求。页面可以仍确认需求已收到，同时由接收团队检查通知。若需求本身未保存，则不能显示提交成功。相关操作可参阅《咨询表单提交后怎么设计？成功提示、邮件与销售跟进》。
“已收到您的需求”适用于真实保存已确认的场景；“我们正在为您安排方案”则需要有实际流程支撑。没有自动分配或人员确认，完成页不应为了营造服务感而使用这种说法。
设计时需要向开发确认成功依据：最终保存结果是否已经返回，是否存在未完成附件，什么情况下返回结果不确定。如果只有按钮点击事件，页面跳转并不能证明数据写入。应使用真实结果驱动完成状态。
对用户有意义的反馈可以简短。先明确收到的对象，再给核对信息和下一步；复杂的内部技术错误不必全部显示，但需要提供不会诱发重复提交的恢复路径。
需求编号应该能用于核对同一条记录
如果系统有真实需求编号，可以在完成页显示，并说明它用于补充或查询。编号需要来自已经保存的记录，不能每次打开页面随机生成一个看似专业的号码。
编号不是装饰。访客携带它联系企业时，接收人员应能定位同一条需求；通知邮件中的编号也应对应后台。否则完成页、邮件和业务人员各持一个编号，反而增加沟通成本。
不一定所有官网都需要复杂编号体系。简单咨询可使用系统已有的记录标识或受控查询方式，但不要暴露他人的信息。是否向访客展示、是否允许公开查询，需结合现有系统权限设计。
如果业务团队会把编号复制到后续沟通记录，需要先验证搜索能找到对应条目，并确认不同来源的编号不会混淆。不能用一套前台临时编号和另一套后台编号，要求工作人员靠姓名猜测对应关系。编号展示简洁与后台核对可靠应同时成立。
回执还可以显示提交时间、选择的服务及经过适当处理的联系方式，帮助访客判断自己提交的是哪次需求。显示多少，应以核对任务为准，避免把全文、敏感资料和附件详情重新铺满公开页面。
若允许复制编号，操作应该清楚，并给出复制结果。复制失败时仍应能手动选取，不必把最重要的信息只能放在短暂消失的提示中。手机上也要能看到编号和继续操作，不能依赖鼠标悬停。
下一步写成企业实际能够执行的动作
完成页的下一步应回答由谁处理、以什么方式继续，以及是否还需要用户做事。如果只有接收团队后续查看，可以说明“我们会通过您选择的联系方式继续沟通”，而不必编造已预约某位顾问。相关操作可参阅《企业官网“联系我们”页面怎么设计？别把高意向客户逼进一个没有反馈的表单》。
处理时间只有在排班、责任人和响应规则落实后才适合承诺。没有明确安排时，可以写明工作时段或建议的补充渠道，但不要虚构具体小时数来提升信任。
已有正式服务承诺时，要让提示与承诺范围一致。例如只在工作日处理，就不应将夜间提交写成马上响应；某种紧急支持不属于普通咨询，也应指向对应入口。内容团队不能单独决定业务时限。
补充方式比一句“耐心等待”更有帮助。可以提供已核对的联系入口，并提醒用户引用需求编号。若企业没有编号，则说明需要提供哪些核对信息，但避免要求用户重复发送全部敏感附件。
按钮应与当前阶段相匹配。查看相关服务、返回首页或继续浏览案例，可以作为后续动作；“再次提交”不宜成为唯一主按钮。否则用户可能误解刚才的提交尚未完成。
漏项、更正与结果不确定要有不同路径
访客刚提交就发现电话填错，完成页可以指向补充更正渠道。若系统支持编辑已提交需求，说明实际可修改范围与条件；若不支持，就由接收团队按照已有记录核对，而不是暗示用户能直接改动后台。
提交超时是另一种情况。浏览器没收到确认，不代表服务器必然没保存。此时应展示结果待确认或查询方式，并保留用户输入。不能使用保存失败的文案驱动立即重发，也不能未经核对显示成功编号。
刷新完成页也应避免新建记录。回执展示与提交动作需要区分，用户查看自己的回执，不应因为重新载入页面再触发一次保存。开发验收应专门覆盖刷新、返回及重复打开。
附件不完整时，反馈要准确指向缺口。若允许先保存文字需求再补文件，可以展示需求已保存、附件需补充；若业务要求全部资料完成才能提交，就要在提交前阻止并提供修正方式。两种实现不能共用相互矛盾的文案。
文字同样要兼顾可感知性。成功信息应该出现在用户能够发现的位置，页面跳转后的标题和主要反馈要清楚，键盘操作后不能停留在已经消失的按钮。不要只靠颜色告诉用户是否成功。
让测试样本穿过页面、记录和邮件
验收前准备带有明显测试标识的受控需求，记录服务、联系方式和附件状态。从真实提交入口完成一次，查看完成提示，再到后台找到同一条记录，最后核对实际接收的通知。
JVDS自身网站通知核验已经明确采用后台保存与邮件实际收到相互核对的方式。这个经验提醒我们：仅看到配置验证成功，或仅看到前台成功提示，都不足以确认完整接收流程。本文不据此承诺其他网站的通知结果。
测试标识要能从正常咨询中辨认出来，避免接收人员按真实项目继续跟进。验收后按既定管理方式清理或标记测试记录，保留必要的验收结论。不要为了删除测试影响，误删其他访客在同一时间提交的需求。
测试时比较的是同一条需求，而不是分别证明“表单有记录”“邮箱有一封邮件”。编号、时间、服务和测试标识应能对应。字段遗漏、联系方式改写或附件数量错误，都需要回到具体环节修复。
再覆盖几个非正常场景：提交前检查未通过、网络结果不确定、已保存但通知失败、完成页刷新，以及回执返回表单。根据真实实现安排受控测试，不必在正式网站上反复制造真实咨询。
每个场景写出预期文案与下一步。例如已保存未通知，应避免让用户重复提交；未保存，应提示可以修正后继续；结果不确定，应提供核对方式。成功标志是用户知道当前事实和可做动作，接收团队能找到对应记录。
上线交接时，将完成页文案与业务处理负责人一起确认。换了接收邮箱、调整服务范围或人员安排后，也应复核这些说明。回执是业务流程的一部分，不能仅在上线前当成最后一屏视觉稿验收。
常见问题
完成页必须显示需求编号吗？
不一定。系统具有稳定编号且接收团队能据此核对时，展示才有价值。没有真实编号来源，不要随机生成装饰编号；可以使用已确认的其他核对方式。
页面说提交成功，就代表工作人员已经看到吗？
不能这样理解。保存、通知和人工查看是不同事实。完成页应只表达已确认的状态，人员处理与响应承诺要与真实业务安排一致。
通知邮件失败时，应让访客重新提交吗？
如果需求已经保存，通常应由接收团队处理通知问题，避免制造重复记录。是否需要补充信息取决于保存内容，不应仅因通知失败要求重填整张表单。
可以写我们会在很短时间内联系吗？
只有具备明确负责人、排班和实际执行规则时才适合写具体时限。没有依据时，说明真实处理方式与补充渠道更稳妥，不能由完成页自行许诺。
访客想更正刚提交的信息，该怎样引导？
提供企业实际支持的修改或补充入口，并说明如何引用同一条需求。若不支持在线修改，不要展示不存在的编辑按钮，也不宜将再次提交作为唯一方案。
链接复制成功
