验收要由未来实际使用的人参与

用户验收测试的目的，是让业务团队依据事先约定的任务和结果，判断当前交付能否进入下一阶段。它不同于实施人员逐项演示，也不同于技术团队核对代码是否运行。由项目负责人指定验收代表时，应覆盖日常操作岗位、流程负责人和必要的管理角色；若只有项目发起人参加，一线实际使用中的理解差异可能被遗漏。

验收前说明本轮范围、当前版本、测试账号、环境限制和已知未完成事项。每位参与者知道哪些内容要实际操作、哪些只是观察，哪些问题需要提交责任人处理。验收代表可以参与制定用例，但执行时最好自己按工作顺序完成任务，不要让演示人员代为点击或在旁提示每个步骤。遇到依赖人工协调的环节，也要如实记录。

验收标准要在开始前获得业务和项目责任人确认。可观察的标准包括指定角色能否找到记录、完成关键操作、按要求交接并查询结果；不可用“看起来顺畅”“整体满意”代替所有任务的结果。可用性反馈仍有价值，但应与约定功能通过情况分开记录。若标准尚不清楚，先补充规则，不在验收会上临时改变通过门槛。

用真实流程顺序组织验收脚本

脚本按照岗位实际工作的先后顺序排列。每项写出起始条件、输入信息、执行角色、操作动作、预期结果、证据和结束状态。选取少量能代表日常业务的虚拟或经批准处理的样例，覆盖正常任务和最重要的例外。真实顾客信息不应为验收方便而随意复制到文档或截图中。

例如一条顾客跟进任务，可以由接收岗位核对记录，完成分配或承接，补充过程结果，再由下一岗位查阅。验收人应知道哪个动作算完成、任务转手后谁负责，以及如何查看历史过程。选用此类场景是为了演示验收组织方式，不代表某个系统已具备所有相应流程，实际以当前交付方案和账号可验证范围为准。

让不同岗位分别完成自己的步骤，并观察交接点。一个主管账号能看到结果，不代表普通员工也有同样权限；某个人依靠熟悉产品完成操作，也不代表培训后的普通用户能够独立复现。必要时让参与者在没有演示人员代操作的情况下重做关键任务，记录额外解释或临时绕行的步骤。

选代表任务时兼顾常态和交接断点

验收样例不要只挑最熟练的操作。选择一条经常发生的常态任务、一条涉及岗位交接的任务，以及一条项目组最担心的边界情况。每个样例都说明为何具有代表性、对应哪些工作岗位和本次验收范围。若某类门店、区域或服务流程没有参加，明确标记适用限制，不能把少数样例的通过结果推广到未参与的业务范围。

场景准备由业务人员核实数据和规则，避免实施人员为方便演示临时创造业务流程。执行前向参与者说明任务目标，但不提前逐步告诉每个按钮位置；必要的操作指导另记为培训反馈。若用户只有在提示后才完成操作，验收记录应说明提示内容和频次，判断是否需要补培训、改说明或调整流程。

把问题分成缺陷、规则和培训事项

验收中发现偏差，先记录事实：用例编号、角色、前置状态、实际操作、预期依据、实际结果和影响范围。然后再分流。若当前表现偏离已确认要求，可登记为交付缺陷；若双方对业务规则理解不同，交由规则负责人澄清；若操作可用但用户不清楚入口或方法，安排培训或改进说明。不能把所有困难都写成产品缺陷，也不能一概归为员工不熟悉。

每条问题指定负责人、处理期限和复核者。修复后由原验收岗位重跑相关步骤，并检查可能受影响的交接、查询或报表。未复测的问题仍保持待处理状态。若短期内无法解决，写明是否存在人工替代方案、适用范围和承担风险的责任人，不能仅在会议纪要里写“后续优化”就宣布通过。

验收意见不必追求全员没有任何保留。不同岗位的差异意见记录各自依据，明确需要谁作决定、是否影响关键任务、下一次核对时间。项目团队应区分必须解决的阻断项、可接受的已知限制和上线后观察项，以免少数意见被沉默，也避免某个非关键偏好无限扩大首期范围。

不同代表给出相反意见时，不用简单多数票覆盖关键业务岗位的限制。先查看分歧关联的场景、影响和验收标准，由被授权的流程负责人决定是否改变规则、追加验证或缩小适用范围。决定过程及其适用条件都留在记录里，后续推广时才能知道原结论针对什么团队和任务。

用结论记录约定下一步，而非只签一个“通过”

验收记录写明测试对象和范围、版本、参与岗位、通过的任务、未通过事项、未覆盖范围、遗留问题负责人和后续检查时间。结论可以是通过、附条件进入下一阶段或暂缓，具体门槛由项目自身风险和责任人确定。签字表示确认本次记录和决定，不应被理解为所有未来变化都已覆盖。

对附条件通过的事项，写清条件、完成期限、复核方式和逾期后的处理选择。若发生版本或配置变化，应判断哪些已通过用例需要重新执行。验收文件与需求、培训材料、问题清单保持可追溯，后续团队才能理解当时为何接受限制，避免新员工只看到一个孤立的签字页。

上线前后保持使用者反馈闭环

试运行期间继续收集操作岗位遇到的具体任务困难，区分一次性个案和重复发生的问题。反馈要关联岗位、流程阶段和当前版本，不收集不必要的个人信息。项目协调人按节奏回看未决事项，明确哪些影响继续推广、哪些可进入后续改进。若主要问题来自角色职责或业务规则，先由组织内部澄清，不能把流程决策全部推给软件供应方。

企雀会员管理公开资料介绍会员分层，以及顾客领取分配、跟进进度与结果记录。验收相关方案时，可把这些公开描述拆成由不同岗位亲自操作的核验任务：分层信息如何查阅，分配后责任和进度如何呈现，结果如何留存。公开介绍不等于当前方案已满足项目验收条件；以实际账号、约定用例和复测记录形成结论。查看企雀会员管理公开介绍