顾客在小程序预约了周六下午的试妆服务，到店后却需要重新说明项目；领到的券无法核销，服务结束后也找不到记录。这些问题常常发生在多个系统已经连接接口，却没有明确业务状态与处理责任的情况下。
小程序与门店打通，需要围绕一次完整的服务过程设计数据关系：谁预约、由哪家店承接、使用什么权益、实际完成什么服务，以及哪些结果应回到会员档案。本文面向产品、开发和实施团队，以美妆门店为例展开。字段、状态、时间窗口及数字均为设计示例，应按实际业务调整。
一、先定义一条可以追查的服务链路
可以从"线上选择项目---提交预约---门店确认---顾客到店---权益核销---完成服务---记录回流"这条路径梳理需求。直接进店的顾客从到店环节进入，取消预约的顾客提前退出，不必强行让所有人走完全流程。
这里至少有四种对象：会员、预约、服务单和券。预约表达未来的服务安排，服务单表达实际发生的服务，券表达可使用的权益。它们可以关联，但不宜用一个状态字段代替全部过程。
| 对象 | 回答的问题 | 建议保留的关系 |
|---|---|---|
| 会员主档 | 服务属于哪位顾客 | 各渠道身份与验证结果 |
| 预约记录 | 何时、何地、预约什么 | 会员、项目、时段及变更历史 |
| 服务单 | 实际完成了什么 | 预约、执行门店、人员及时间 |
| 券实例 | 哪一份权益被使用 | 会员、活动、核销业务及撤销记录 |
| 销售订单 | 是否发生商品交易 | 支付、退款及关联服务 |
有预约不代表已经到店，券被占用不代表服务已经完成，服务完成也不一定产生商品销售。保留这些区别，后续才能解释未到店、未核销和未成交分别发生在哪里。
跨系统还应约定编号映射。门店服务单保留预约编号，核销流水保留服务单或订单编号，会员系统接收业务结果时保留来源系统与来源记录编号。这样客服才能从一个入口查回整条过程。
二、预约成功要包含资源确认
预约表单可以很简单，但预约确认要面对真实资源限制。项目需要多长时间、哪些员工可以执行、是否占用独立工位、门店何时休息，都会影响一个时段能否接单。
如果一个工位在一小时内只能完成一项服务，就不能只根据"当天还有空位"接受多个同一时段预约。可以按员工、工位或可服务名额建立容量规则；具体精度取决于业务，不必把所有项目都建成复杂排班系统。
一种状态设计是：待确认、已确认、已取消、已到店、未到店。服务开始和完成由服务单管理，避免预约状态同时承担排班与服务结算两类责任。小程序应清楚展示当前状态，而不能提交表单后统一提示"预约成功"。
改期也需要资源重新确认。先检查目标时段，再按约定方式切换占用，并保留原时间和变更原因。若新时段不可用，不能已经释放原预约却让顾客以为改期完成。
重复点击和网络重试应对应同一次提交。可以给提交动作分配稳定请求编号，由服务端识别重复；容量判断与预约确认则需要具有一致性约束，防止两个请求同时占用最后一个名额。这是需要验证的行为要求，不限定某一种数据库实现。
门店收到提醒不代表一定有人处理。应提供待确认列表、负责人和超时处理方式。员工请假或门店临时停业时，也要能查出受影响预约并按规则重新安排，而不只是删除排班。
三、会员识别要支持散客和身份异常
预约记录需要可靠地关联顾客，但不能把"提供手机号"直接等同于已确认所有会员身份。手机号可能录错、变更或被多人使用，跨渠道身份关联应执行已确定的验证和冲突处理规则。
建议以内部稳定会员编号承载历史关系，渠道标识用于连接主档。无法确认关联时，保留待核实状态，并允许门店完成必要服务。不要为了让报表看起来统一，就把相似姓名或相同联系电话的档案静默合并。
直接进店且没有预约的顾客，可以创建无预约来源的服务单。愿意并适合关联会员时，再按流程关联；未关联会员的服务也应有独立业务编号。否则所有统计都会偏向已经入会的人群，散客服务量和工作负荷则被遗漏。
导购提前准备所需的信息，应限于本次服务相关内容。例如预约项目、未使用权益、顾客主动提供的偏好与必要的历史记录。跨店查看、修改服务记录和导出资料等权限分别设计，不因为"统一会员"就向所有员工展示全部数据。
四、券码核销与服务履约分别确认
券码只是识别入口，是否可使用还需要判断归属、有效期、适用门店、服务项目、使用次数及当前状态。服务券与满减券的用途不同，校验对象也不同，不能只要扫描成功就一律扣减。
以一次体验服务券为例，顾客到店后先校验券与项目是否匹配，再依据业务规则占用或核销，最后关联实际服务单。核销发生在服务开始还是完成时，需要提前确定，并配套取消、未履约和异常撤销的规则。
| 场景 | 需要提前约定的处理 |
|---|---|
| 券有效，但项目或门店不匹配 | 明确原因，不静默替换项目 |
| 两台设备同时核销同一券 | 只允许一次有效核销，其他请求返回可解释结果 |
| 请求超时，不知道是否成功 | 查询原请求结果，避免创建第二次核销 |
| 服务取消或无法履约 | 按规则释放或撤销，并保留原记录 |
| 商品退款，服务已经完成 | 分别处理销售与服务事实，不能直接恢复全部权益 |
核销失败提示要便于现场处理。过期、被占用、已经使用和系统未确认是不同情况，应告诉店员下一步去哪里查看，而不是统一显示"无效券"。
如果需要人工例外处理，应限制权限并记录原因。不能靠手工将券状态改回"未使用"来抹掉历史，否则同一张券多次消费后很难解释。
五、服务记录回流要结构化，也要允许纠正
服务结束后的记录，应先覆盖能够支持下一次接待的必要信息，例如项目、执行时间、实际使用产品、顾客反馈及后续事项。自由文本可以补充，但关键业务字段尽量不要全部写在备注里。
可将"顾客主动表达的偏好""员工观察""系统推断"分开标识，避免把推测当成事实。护理或试用反馈也不能自动升级为医疗判断；本文讨论的是服务记录设计，不涉及诊断或治疗建议。
服务单完成后向会员档案回传摘要，并保留详情的来源关系。接收失败时进入可重试队列或异常列表；重复回传时按来源记录识别，不能在会员时间线上出现多份相同服务。
更正记录应保留版本或修改轨迹。比如把"使用产品 A"纠正为"使用产品 B"，需要能看到是谁在何时因为什么修改。已经用于后续任务的字段变化，也应触发相应检查，避免系统继续依据旧记录安排跟进。
对于到店但未完成服务、服务中断和投诉处理中等情况，保留独立结果。不能为了让流程顺利结束就一律点击完成，再在备注里解释"实际未做"。
六、后续关怀由服务事实触发，并有退出条件
服务完成可以生成跟进任务，但不意味着必须立即发送营销消息。应先判断任务目的、可用渠道、顾客偏好以及已有沟通记录，再决定是否执行。
例如一项试用后的反馈任务，可以记录执行人、预定时间、关联服务单及完成条件。顾客已经反馈，任务就应结束；顾客明确不希望继续联系，应停止相关安排；服务被撤销或进入投诉处理时，则转为相应人工流程。
渠道能力要通过实际接入确认。不要把"系统已经生成任务"写成"消息已经送达"，也不要默认任何小程序都可以随时向所有顾客发送通知。执行记录应区分计划生成、提交渠道、渠道返回结果和实际反馈。
导购手工跟进与自动消息还要共享必要的执行状态。若店员已经完成沟通，自动流程需要知道是否应取消后续任务，避免同一天围绕同一件事重复联系。
七、到店率与核销率先统一统计口径
效果评估应从明确的分母开始。预约按提交日统计，还是按计划服务日统计，会得到不同结果；以预约单还是去重顾客为单位，也不能混用。
一个可执行的示例口径是：以当周计划服务的有效预约单为一组，排除在约定截止时间前已取消的记录，观察这些预约最终是否到店。该口径下，到店率等于已到店预约数除以有效预约数。取消量另外报告，以免高取消率被排除后看不见。
假设当周有 100 张计划服务预约，20 张在截止时间前取消，剩余 80 张中有 56 张到店，到店率为 70%。这只是口径示例，不是行业目标；如果改用全部提交预约为分母，得到的指标应另行命名。
券核销率则需要说明统计的是发放、领取还是有效可用券，以及核销是否已经撤销。跨周才核销的券不能随意与本周新发券相除，最好按领取批次设置一致观察窗口。
关联成交也不等同于增量成交。可以报告到店服务后指定时间内发生的有效订单，但要说明关联方法、退款处理和跨渠道遗漏。小程序来源顾客与自然进店顾客本身可能不同，不能直接把两组复购差异全部归因于小程序。
八、接口验收围绕异常能否继续处理
一次联调至少走完预约确认、改期、到店识别、核销、服务完成与记录回流，还要覆盖直接进店的顾客。验收时沿同一组业务编号查看各端状态，避免只看每个页面都能打开。
重点增加重复提交、消息延迟、员工更换、券状态冲突和回流失败等情况。预期结果应写在测试前：什么可以自动重试，什么必须人工确认，哪一端负责最终状态。
业务发生时间与系统接收时间最好分别记录，特别是门店暂时断网后补传。若旧的预约确认事件晚于取消事件到达，系统不应无条件把已取消预约恢复。可通过版本、状态约束或事件顺序处理，具体实现由技术方案决定。
上线初期可以每日核对三类差异：线上已确认而门店未收到的预约、已核销却找不到服务关系的券、门店已完成而会员档案未收到的服务记录。每项差异都需要责任人和处理结果，不能只生成一张无人查看的报表。
当预约安排可靠、权益使用可解释、服务记录能回查，顾客从小程序进入门店的过程才更连贯。下一阶段增加更多活动和服务项目时，也应沿用这套数据关系与异常处理方式。