预约能下单，改期和爽约却全靠人工：预约小程序立项前要定哪些规则

“上午十点还可以预约两个人”，可能有完全不同的含义。它可能是一位老师能接两个学生，也可能是两间房各接一位顾客，还可能是一名工作人员、一间房和一台设备必须同时空闲。

需求里如果只有“每天可预约人数”，开发方很难知道真正要保护的是哪种资源。同样一个时间格子，员工、场地、设备、车辆、服务名额和营业日历，可能都有独立约束。

老板可以先把每项服务的资源写清楚：

还要区别营业时间、人员排班和可预约时间。门店开着，不代表所有服务都能约；员工在岗，也不代表可以把已占用资源再次卖出去。

已预约、已确认、已到店、已核销、已完成、已取消、已爽约，分别对应不同事实。把它们都压成“成功”和“失败”，员工就只能在备注里重新解释。

一套简单状态也可以够用，但必须定义每个状态的含义、谁能变更，以及变更以后影响哪些资源和权益。

例如顾客提交申请以后，如果需要门店确认，用户看到的就应该是“待确认”，并知道多久能得到答复。系统不能先显示“预约成功”，再让顾客到店后发现商家还没有接单。

哪些操作允许重复，哪些只能做一次，同样需要约定。前台网络慢，连续点了两次核销，不应该消费两次权益；工作人员误操作，也要有可追溯的纠正办法。

OWASP 的业务逻辑安全指南强调把流程作为明确状态管理，并处理重复步骤和并发操作。对老板来说，验收重点是业务结果：步骤不能随意跳过，重复请求不会重复占位，已经完成的任务不会无依据地再做一次。

改期看起来像改一个日期，实际涉及重新分配资源。新时段没有空位、服务人员不同、价格或优惠条件变化，都会改变原安排。

如果系统先取消旧预约，再发现新时段没位，顾客可能两头落空；如果先创建新预约，却忘记释放旧资源，又会占掉两份名额。

开发前要明确改期是否需要确认，以及失败以后保留什么结果。顾客应该能够看到本次申请状态，门店也能找到原记录、目标时间与处理人。

常见规则需要逐项确认：

• 顾客能自行改期，还是只能提交申请；
• 距离服务开始多近时不再允许自行改期；
• 是否限制改期次数，员工例外处理由谁批准；
• 跨员工、跨门店、跨服务项目是否属于同一种改期；
• 新安排确认以后，旧名额何时释放；
• 服务价格、已使用优惠及权益有效期怎样核对。

这些事项没有一个适合全部行业的默认答案。时间和次数应由商家确定，开发团队将它们实现为清晰规则。

取消预约、取消已付款订单、退款申请和退款成功，不是同一个状态。服务已经开始、顾客临时取消、商家无法提供服务，也不应被同一按钮草率处理。

取消规则要在顾客作出决定前呈现，记录其适用版本。商家后来调整规则时，应确认新规则影响哪些预约，不能让旧订单的条件悄悄变化。

迟到则需要结合后续安排判断。能够延后服务，还是只能缩短本次时间、申请改期或进入人工处理，由资源和商家规则共同决定。系统可以提供判断依据，但不应让客服临场编一套收费办法。

爽约需要说明怎样认定。没有完成核销，不一定等于顾客没来，也可能是前台漏操作或设备故障。认定前可以核对签到、联系和服务记录，并保留人工更正入口。

涉及退款的技术闭环，可以继续阅读支付、订单与退款异常说明。本篇关注预约资源与服务安排，不将一次退款申请当成整个售后过程已经结束。

热门时段满了以后，候补可以帮助补空位，但要给等待的人一个明确预期。

什么时候通知候补者，有多少时间接受，没人接受以后怎样递补，都会影响真实名额。如果通知一批人，却没有控制确认过程，就可能把释放的一位变成多张有效预约。

排队顺序也需要有依据。按提交时间、会员条件或人工安排处理，应由商家确定，并在适用场景说明。员工临时插队或调整名额，要留下原因与权限记录。

候补者确认以前，还要核对服务时间、价格、参加人数和资格。原来愿意等待，不代表顾客已经接受后来出现的新安排。

通知只是帮助用户获得信息。是否成功送达，与有没有形成有效预约，需要分别记录；消息渠道不可用时，应有查询和人工联系办法，不能把“系统尝试发过消息”当作顾客已经知道。

前台想要的通常是一扫就能处理。后台仍需确认预约属于谁、是否适用这家门店、当前是否允许核销，以及这一动作会消费什么。

一次预约可能对应一次服务，也可能对应多位参加者、套餐中的一个环节，或储值与次卡中的一部分。核销对象如果没有定义清楚，前台看到“完成”以后，剩余次数和实际服务情况就容易对不上。

还要考虑这些常见情况：

• 顾客手机没电，能否用其他方式查询与确认；
• 一张预约包含多人，能否部分到店、分次核销；
• 顾客到错门店或提前到店，谁有权限处理；
• 工作人员误核销，怎样申请更正，已经发生的权益变化如何核对；
• 网络中断时，记录如何保存，恢复后怎样避免重复。

断网情况下是否允许继续服务，需要商家依据风险决定。它不是把所有预约都先标成完成，也不能让前台事后靠记忆补出一份记录。

员工请假、临时停业或设备维修，可能影响一批预约。后台如果只有逐单修改入口，门店很快就会重新用群聊和 Excel 协调。

可以让系统先识别受影响预约，显示服务时间、顾客联系状态、替代资源和处理进度，再由有权限的人确认方案。批量改动还应保留原安排，避免员工不知道自己究竟改过哪些单。

这类任务尤其需要一个负责人。系统能够列出名单，并不意味着顾客已经全部得到妥善安排。没有答复、不能接受替代时间、需要退款的情况，都应该留在可追踪的队列里。

恢复营业以后，也要确认旧任务如何关闭，不能把已取消的预约重新变成有效名额。

老板可以先准备一张规则表，再让开发方按同一范围报价。标准时段与单资源预约，和跨门店、多资源、候补、批量改期，工作量不同。

首期可以缩小范围，但要明确哪些例外由人工处理、系统至少留下哪些记录，以及人工处理会改变哪些状态。

验收不宜只跑一笔正常预约。至少准备这些样本：

关于材料和证据，可以结合软件项目验收资料清单一起约定。规则表、实际样本、异常处理和员工操作说明，都是交付内容。

华茂思捷提供预约小程序、门店管理系统与技术顾问服务。如果你准备开发预约功能，可以先整理一周排班和几种常见例外，联系我们把服务规则转成可以报价、可以验收的需求。

• OWASP：Business Logic Security Cheat Sheet，用于核对服务端业务规则、状态管理、重复操作和并发处理的基本原则。

预约情形属于需求示例，没有对应真实客户项目；具体改期、取消、费用和爽约规则应由商家确认，本次写作没有对任何线上预约系统实施测试。