网站、UI 和品牌需求共用一个表单时，切换服务后的旧答案应该怎么处理，需要分别定义保留、展示、校验与提交。某个问题从页面上消失，不代表它的值已经清除，也不代表这次需求仍应包含它。
多服务需求表单的核心，是让当前选择、核对摘要和实际保存范围保持一致。访客可以保留暂时不用的输入以便返回，但接收人员不应拿到一份混合了多个未确认服务答案的需求。
先区分共用资料和服务专属问题
联系人、公司与主要沟通方式可能在不同服务之间共用；网站栏目、产品界面范围、品牌应用资料，则通常对应不同任务。是否共用取决于业务用途，不能因为字段名称相近就把它们放在同一个值里。
假设访客先选官网设计，填写旧站地址与语言，再改为品牌视觉，希望整理 Logo 和应用规范。旧站地址可以作为补充背景，也可能与本次范围无关。表单应根据明确规则决定是否纳入，而不是让隐藏字段自动变成品牌需求。
计划时间这类看起来共用的答案也要确认含义。网站上线、UI交付和品牌应用准备，可能是不同事件；用户填过一个日期，不代表另外两项也承诺同一天完成。可以保留它作背景，再询问当前任务具体指什么，不用相同字段名掩盖范围差异。
建立字段清单时记录服务归属、是否条件必填、切换后是否保留，以及实际提交条件。每项问题能解释它在当前任务中的用途，后续显示和校验才容易一致。
也要区分“一个表单可以选择一种服务”与“一个需求同时需要多种服务”。前者是切换当前分支，后者需要明确多服务组合及对应资料。不能靠用户不断切换几个选项，就假设已经选择了全部服务。
完成标志是同事能够指出哪些答案跟着联系人共用，哪些只属于当前服务，哪些组合需要另行确认，而不是仅看到页面能展开不同问题。
切换时保留输入，但让影响可理解
用户切换服务可能是在比较，也可能选错了。立即清空全部输入，会增加返回成本；完全保留却不说明提交范围，又可能制造误解。可以按字段性质安排保留与排除。
共用资料若仍适用，可以保留。服务专属答案可暂存在对应草稿中，返回原服务时恢复；当前服务不使用的内容，应从核对与提交范围排除。若某次切换确实会永久清除资料，操作前说明影响。
例如从网站需求切到 UI 需求，共用联系方式保留，旧站栏目答案暂存，UI 相关页面范围重新填写。回到网站需求时可以找回原输入，但仍需核对它是否符合当前问题。这是设计示例，不代表某个后台已有相同功能。
联动反馈不宜让页面突然跳到用户看不懂的位置。新问题出现时说明对应服务，已完成内容的状态保持清楚；如果某项答案因范围变化失效，应指向具体问题，让用户重新确认。
同名字段也要谨慎。例如“页面数量”在官网和 UI 项目中含义可能不同。把上一个分支的数字直接带过来，虽然减少输入，却可能改变项目范围。必要时独立保存并明确单位和对象。
隐藏、保留和提交，是三个独立结果
视觉隐藏只处理当前界面，提交范围仍需要明确实现。不能把“看不见”当作已经自动排除，验收时要核对保存记录，而不只看表单截图。
校验也要跟着当前范围变化。品牌分支没有使用的网站字段，不应继续阻止提交；当前需要的品牌信息也不能因为之前填写过网站问题，就被误认为全部完成。
服务端应按本次有效服务核对允许的答案与必要资料，不能只信任页面传来的状态。具体做法由实施团队评估，业务要求则清楚表达：“本次选择什么，就按什么范围保存和校验。”
如果旧答案被保留供返回使用，它可以属于草稿，却不属于本次提交。这个区别应在维护说明里写清。数据结构上是否分组、草稿如何关联，由开发确定，但用户的任务范围不能含糊。
用户主动清空某项答案时，要让当前保存值同步变化。若后台把空值当作“保留旧值”，已删除的答案可能在恢复或通知中再次出现。需求应区分没有填写、明确清除和不适用，由实施方解释怎样保存；验收时检查清空后重新打开的结果。
保存后的记录还要说明本次服务类型与相关答案。接收人不应看到一组无法判断归属的字段，然后再猜访客到底想咨询哪项服务。
提交前摘要只显示当前有效范围
核对摘要帮助访客发现错误，应该优先显示本次服务、联系渠道、主要范围与尚未确定的项目。把所有历史输入重新抄一遍，会让已经排除的旧答案看起来仍属于当前需求。
摘要与表单使用同一套范围规则。当前隐藏且不提交的专属字段，不应再次出现在确认区域；允许共用的背景信息则按实际用途标注，不能换个位置就失去原来的含义。
假设摘要显示品牌需求，却带着“英文官网五个栏目”的旧回答，访客可能误以为系统仍准备同时处理官网。即使后台最后排除了这些值，核对界面也已经误导，需要修正。
返回修改后，摘要应重新计算，不能继续使用第一次打开时的旧副本。用户改变服务、删除答案或选择不确定，最终核对都应忠实表达最新状态。
摘要不用隐藏资料缺口。没有填写、明确不需要和暂未确定是不同结果，可以用清楚语言区分，让后续沟通知道哪些需要补充，而不是统一留成一个空白。
草稿恢复与后续沟通，也要保留服务归属
恢复旧草稿时，先确认原来的服务选择，再按对应问题恢复。不能把先前分支的所有答案直接加载到当前默认服务。表单规则已变化时，提示用户复核受影响内容。
共用联系方式如果切换了渠道，也需检查原字段是否仍适用。例如选择邮箱联系后，电话是否变为选填，应依据当前规则处理；服务和渠道是不同维度，不能用一次切换同时清空不相关输入。
多人协作补充资料时，说明这份草稿或记录属于哪个需求。把另一个同事提交的 UI 范围附到品牌记录，需要明确标为补充或新服务，不能让相近的联系人自动决定合并。
后续沟通确认增加服务，可以保留原记录和新增范围，说明何时改变、谁确认。这样接收人员知道任务扩展了，而不是误以为最初提交就包含所有内容。
没有复杂协作系统的企业，也可以用记录编号和清楚分组实现交接。范围正确比把页面做成很多步骤更重要，不能用更多折叠区块掩盖答案归属问题。
验收切换、返回和恢复后的真实记录
准备测试样本，先填写网站专属问题，再切换到品牌并补充当前答案。检查页面显示、条件必填、核对摘要和后台记录是否使用相同范围，旧网站资料是否按约定保留或排除。
再返回网站，确认应恢复的输入存在，需要重新核对的条件有提示。随后测试切换后刷新、恢复草稿、清除答案和提交失败后的继续，避免仅正常路径通过。
如果支持同时选择多种服务，额外检查组合场景：每组专属答案有明确归属，共用资料没有冲突，缺少其中一项必要信息时提示具体位置。不要把单服务切换验收当成组合需求也已完成。
观察实际通知或导出内容时，同样检查当前范围。后台保存正确，邮件却带着隐藏旧答案，也会影响接收人判断；需要把后续展示纳入约定的核对范围。
多服务需求表单的成功标志是访客知道正在提交什么，运营看到同一份范围，返回填写也不丢掉有用资料。把保留与提交分开定义，共用表单才能兼顾方便和准确。相关操作可参阅《B端复杂表单怎么设计？分组、联动、保存与校验方法》。
常见问题
切换服务后，旧答案一定要删除吗？
不一定。可以暂存以便返回，但要明确是否参与当前校验、摘要与提交。保留在草稿里不等于纳入这次需求。相关操作可参阅《企业网站咨询表单应该收集哪些信息？字段越少不一定越好》。
隐藏字段，后台会自动忽略吗？
不能默认如此。需要实施方按有效服务处理，并检查保存记录。页面截图只能证明没有显示，不能证明没有提交。
联系方式应该随着服务切换一起清空吗？
通常先评估是否仍适用。共用信息可按规则保留，渠道变化再检查相关字段；不要用服务切换清除所有不相关输入。
同时需要网站和品牌服务，应该怎么填写？
表单若支持组合，分别明确两组范围与必要资料；不支持时提供补充说明或后续确认方式。不能把多次切换当作自动选择全部服务。
为什么核对摘要正确，还要查看后台记录？
摘要是用户确认的信息，后台是实际保存结果，两者都要一致。提交处理或通知输出也可能使用不同规则，应按交付范围核对。
链接复制成功
