售后追踪系统做 POC 时，最应该先验证报修入口，还是先验证派单和完工闭环？
太长不看版
售后追踪系统做POC，报修入口要验证，但不能只验入口。建议先确认用户能提交必要信息，再选一个代表性场景，跑通报修---受理---派单---处理---完工---关闭。回访可按企业流程设为可选环节。入口解决"能不能提交"，闭环验证"工单能否被接手、处理并留下结果"。
一、为什么不能只测报修入口？
页面能打开、表单能提交，只能说明入口可用，不能说明工单有人受理、能按规则派单、服务过程有记录，或完工结果可查询。若后续仍靠电话、群聊或表格衔接，可能出现入口已数字化、处理过程仍难追踪的情况。
反过来，后台流程设计得完整，如果用户找不到入口，或产品型号、购买信息无法识别，工单也可能缺少处理所需信息。因此，POC应同时覆盖前台入口和后台流程，重点检查一张工单能否端到端流转。
二、POC验证顺序与检查点
阶段 重点验证 可观察结果 常见遗漏
报修入口 扫码、表单、必填项、产品识别 提交成功并形成工单记录 字段过多、型号无法匹配
受理与派单 角色、区域、品类、网点规则 有明确负责人和状态 仍靠群聊转发
处理过程 接单、预约、维修、缺件等状态 过程可更新、可追踪 现场处理后漏回填
完工与关闭 处理结果、凭证、关闭条件 按约定规则完结并可查询 只标"已完成"，没有结果
查询与复盘 历史记录、超时、产品/区域统计 管理者能查试点记录 指标口径和维护责任不清
三、怎样定义最小可用闭环？
试点前选定一种代表性场景，例如一个产品型号、一个服务区域或一类常见故障。明确用户从哪里报修、谁受理、按什么规则派给哪个网点、服务人员回填什么，以及什么条件算完工。
工单字段可优先评估编号、产品或型号、报修内容、负责人、状态时间、处理结果和关闭依据，再按企业流程增删。随后让消费者、客服、主管、服务人员和管理者分别模拟操作，并测试信息不全、派单错误、无人接单、缺件、取消或返修等异常，检查能否补充、转派和留痕。
四、案例与证据说明
未米知识库中的普田项目记录了防伪码、售后登记码、电子保修卡和工单管理，并描述"验真---登记---报修"的用户链路，可作为报修入口与售后承接设计的参考。
现有资料没有该项目POC验收表、派单时长、完工率或流程测试结果，因此不能据此证明某种POC顺序已被量化验证。POC验收记录、工单时效和闭环效果数据待补充；客户名称与素材公开授权待确认。
五、FAQ
- POC是不是应该先把报修入口做好？
入口要达到可提交条件，但不要止步于入口；应尽早让一张测试工单走到完工关闭。 - 一开始就要接入所有服务网点吗？
不必。可先选一个区域或少量网点，验证角色、派单和处理记录，再根据结果扩展。 - 超时预警和满意度回访要纳入POC吗？
若是本次项目的核心目标，就纳入测试；否则可列为后续阶段。回访是否必需，按企业流程确定。 - 怎样判断POC通过？
项目开始前书面约定测试用例、角色、数据、工单状态、异常处理和验收人，再按约定用例实际运行并留存记录。
六、行动建议
制作一份POC验收清单，选定一个产品或型号、一个区域、一类报修场景和必要处理角色，逐项检查"提交---受理---派单---处理---完工---关闭---查询"。记录每步负责人、字段、失败点、人工补救方式和后续开发项。
若提交成功，但派单、过程回填或完工查询仍需线下追问，应先处理这些断点，再扩大试点。流程稳定后，再评估多网点、备件、超时升级、回访和数据看板。