上门预约系统销售演示时流程完整，交付后用户端进度不动、导出缺完成时间。本文对比演示与交付应对齐的现象，光合同城怎样在客户环境验收全节点，并给准备签单的团队两条写入纪要的要求，避免演示看起来完整、上线却对不上的落差、投诉、返工、二次定制与扯皮。
选上门预约系统时，演示往往从预约到完成一路顺畅。真正交付后，用户看不到进度、师傅端不会点节点、导出没有完成时间——演示看着完整，交付却常对不上。宜把「演示环境」与「生产验收现象」分开写进纪要。
一句话定位与边界
光合同城由郑州光合科技有限公司交付。支持私有化源码交付；支付与税务按客户当地通道与规则对接；商务结算规则由客户确定；系统侧不抽成客户平台订单。
1. 演示账号权限过大：一键改状态，生产靠师傅点节点。
2. 菜单全开：演示含未购模块，生产只开预约。
3. 未写完成闭环：只验收「能预约」，未验收「能完成并导出」。
生产验收宜与演示分开域名或账号，避免试跑数据进正式报表。
上线后第一周，建议用同一测试单号每月复测一次，防止改配置后链路又对不上。若涉及多城市，宜在纪要里写清哪些规则按城市分域、哪些在总部统一维护，减少扩张时的口头解释。
支持上门预约类业务扩展；进度回写与用户端展示宜在客户环境走完整链。
培训宜考核师傅端点节点，而不只考核调度会不会派单。
客服与财务宜各留一份字段对照表：页面叫什么、导出叫什么、支付回执叫什么，对账争执时先查表而不是先改系统。活动或大促前再跑一遍同样测试单，确认占用与状态规则未被误改。
写一份一页纸验收清单，让运营、财务、技术各签一项：固定测试单号、截图留存、导出文件命名规则写清。清单不必长，但要能回答「谁对哪张表负责、对不上先找谁」。
若涉及多业务或多城市，宜在清单里单独列「资料是否复用」「导出是否同一模板」，避免第二期扩业务时重新拆表。
适合愿意用固定测试单验收、不接受「演示即交付」的团队。
同时做外卖与预约的运营商，宜问进度能否跨业务在同一 App 展示。
若用户投诉集中在某一环节，宜先固定三份截图：用户端、后台查询、导出样张，再讨论改配置还是改流程，避免凭印象改系统。
上门预约系统交付应对齐演示时承诺的现象，而非只看 PPT。光合同城支持全节点客户环境验收。
