做预约功能，第一版往往做得简单，选个日期选个时间点提交。上线后问题陆续来，两个人约了同一个时间、约了来不了、来的时候发现师傅在忙别的事。
这些都不是技术问题，是规则没定清楚。
一、库存按什么算
要先明确产能单位。是每个时段能接待几个人，还是每个师傅同一时间只能接一个人，还是每台设备同一时间只能服务一项。三种算法对应三种数据结构。
资源型的最常见，比如一个师傅同一时间只能服务一位客户，那库存就是师傅数量乘以时段数量。这类要按资源分配，不能只按总数控制，否则会出现师傅被重复安排。
还有一种要区分服务时长。剪发半小时和烫发两小时占用的资源不一样。如果不按时长算，排出来的时间表在现实中是排不开的。这类要按占用时长扣减资源。
二、时段怎么划分
按整点划分最省事，但实际效率低。九点到十点这个时段，九点来的和九点五十五来的，占用时间差别很大。按半小时或者更细的粒度划分，资源的利用率会高一些。
时段之间要留缓冲。前一位客户延迟，后一位就得等。实际操作中，留出百分之十到二十的缓冲时间，比把时间排满更现实。这一点做的时候容易被忽略，上线后才知道时间不够用。
还要处理特殊时间。午休、闭店、设备维护这些时段要能排除在外。做成可配置的，不要写死在代码里，不然每次调整都要找开发。
三、取消和爽约
取消要设时限。提前多久可以自由取消，超过时限要不要扣费，这两条要明确并且在下单时告知。没有时限的话，用户随时取消，排期就乱了。
爽约要记录。用户约了不来也没取消，这类要有记录，累计到几次之后限制其预约权限。没有记录机制，爽约会越来越多。这类规则要提前公示，不要事后才说。
还要考虑不可抗力。天气、突发情况导致的取消，不该计入用户的爽约记录。要留一个由工作人员手动豁免的口子。
四、必须留人工调整的空间
系统排出来的时间表是打不过现实的。客户临时加项目、师傅请假、设备故障，这些都需要人工调整。
所以后台要能改预约。包括改时间、改服务人员、改服务内容、直接取消。改的时候要记录是谁改的、为什么改，方便后续追溯。
前台也要给用户留出口。用户想改时间，如果系统只能取消重约，那他可能就不改了，直接不来。提供改期功能，改期不影响次数记录，用户的配合意愿会高很多。
最后一点，提醒要发。预约前一天发一次提醒，当天早上再发一次，能显著降低爽约率。提醒里带上一键取消的入口，让来不了的用户方便地取消，把时段释放出来给别人。