服务项目、工位、技师和可预约时间怎么规划？

不少预约需求最初看起来很简单：后台维护服务项目，技师设置上班时间，顾客从日历里选一个空档。真正进入门店运营后，冲突往往不是出在日历上，而是出在日历没有表达的地方。顾客约了 14:00，系统只看见技师有空，却不知道唯一能做该项目的工位正在使用；或者项目标的是 60 分钟，现场还要留清洁、整理和交接时间，下一单仍被排在 15:00。

站在红数科技做预约类产品规划和交付的位置，我们会先把“可预约时间”从一张单独的配置表里拿出来。它不是运营人员手工填出的答案，而是系统根据项目、人员、场地和规则算出的结果。

可预约时间，算的是多项条件的交集

把这件事写成一条关系，会比先画日历页面更容易说清楚：

可预约时段 = 门店可营业时间 ∩ 项目可售时间 ∩ 合格技师可用时间 ∩ 所需工位或设备可用时间，再扣除已有预约、临时封锁和前后缓冲。

这条关系里，任何一项为空，这个时间就不该展示。门店营业并不代表每个项目都能做，技师在店也不代表他具备该项目的技能，工位空着也可能处于清洁、检修或预留状态。系统需要判断的是“这笔服务现在能不能完整交付”，而不是某张排班表上有没有一格空白。

微软 Bookings 的公开文档把服务时长、缓冲时间、可提供该服务的员工、员工工作时间和日历忙闲状态都纳入预约配置；预约间隔和服务时长也被分开处理。这个思路值得借鉴：15 分钟一个可选起点，不等于项目只占用 15 分钟。起点可以细，后续资源仍要按项目的实际占用时长锁住。

服务项目要写清“占用什么”，不能只留名称和价格

项目是预约计算的起点。一个能参与排期的项目，至少要说明顾客看到的名称和说明、标准服务时长、前后是否需要缓冲、哪些门店可以提供、什么能力的技师可以承接，以及需要哪一类工位、房间或设备。

项目之间只要时长或资源要求明显不同，就不宜只靠顾客备注区分。比如同一项服务存在不同规格，其中一种需要专用设备，另一种不需要；如果后台仍把它们当成同一个项目，系统在顾客选完规格之前就无法准确计算时间。更稳妥的做法，是拆成可独立排期的项目或项目规格，让每个规格都有自己的时长和资源规则。

时长也不要只填“实际操作时间”。准备、设备复位、工位清理、结果确认等环节会持续占用人员或场地，就应进入占用规则。哪些环节必须占用技师，哪些只占工位，要按门店真实流程确定。首期系统还不支持分阶段占用时，可以先按整段时间保守锁定关键资源；等真实预约数据足够，再判断是否值得把准备、施工和收尾拆开。这样利用率可能不是最高，但不容易把顾客排到现场后才发现接不住。

技师排班要回答“谁能做、什么时候真有空”

技师资料里的职位名称，通常不足以参与自动排期。系统更需要一组能落到服务项目上的能力关系：这名技师可以做哪些项目，是否只在某些门店或工位工作，能不能被顾客指定，不能指定时系统按什么规则分配。

工作时间和可预约时间也不是一回事。技师的可用时间应从常规班次开始，再扣掉休息、培训、外出、请假、临时停排、已有预约，以及其他会占用他的工作。跨店支援尤其要放在同一套排班里处理，否则两个门店各看各的，都可能把同一个人排出去。

人员分配规则不必一开始做得很复杂，但边界要明确。顾客选择“任意技师”时，系统可以从合格且可用的人里分配；顾客指定某人时，只展示这个人的真实空档。临时换人则要重新检查接替者的技能和时间，不能只在订单上改一个姓名。默认情况下，一名技师同一时段只承接一笔需要他持续参与的预约；多人课程或短暂辅助等场景确有并发需求，再单独设置容量。

工位、房间和设备，只要会发生争抢，就应当建成可预约资源

判断一种资源要不要进系统，有个很实用的标准：两笔订单同时需要它，而现场只有一份时，会不会有一笔做不了？会，就不能只把它写在项目备注里。

资源最好分两层维护。第一层是类型，例如标准工位、专用房间、检测设备；第二层是门店里真实存在的具体资源。项目绑定资源类型，系统在预约时占用其中一个可用实例。这样新增、停用或检修某个工位时，不必逐个修改所有服务项目。

还要把“空闲”和“可用”区分开。工位没有订单，并不代表一定能排，它可能在保养、故障、清洁或人工预留中。临时停用应记录开始和结束时间，并立即影响新的可预约时段；已经受影响的订单则要进入人工处理范围，不能静默消失。

如果一个项目同时需要技师和工位，两类资源必须一起锁定。不能先生成订单、随后再去找工位，因为并发下单时，两位顾客可能同时拿到同一个最后空档。比较稳妥的处理是：顾客进入确认环节后短时保留所选资源，付款或提交成功后转成正式占用，超时未完成则释放。保留多久要看业务流程，时间过短会让正常操作失败，时间过长又会白白压住产能。

日历展示之前，先把时间规则定下来

时间粒度决定顾客可以从哪些时刻开始预约，项目时长决定预约结束到哪里，两者不能混在一起。门店可以每 15 分钟给出一个起点，但一个 70 分钟的项目从 10:15 开始后，相关技师和工位仍要占用到项目结束，再加上设定的缓冲时间。系统计算时还应看清这些规则：

• 最早需要提前多久预约，最远可以预约到哪一天；
• 当天临时单是否开放，停止接单的时间怎样计算；
• 取消或改期到什么时间为止，改期后原资源何时释放；
• 项目是否只在固定星期、固定时段或特定门店开放；
• 顾客能否连续预约多个项目，多项目是合并占用还是分别排期；
• 门店人工加单、锁台和调班后，线上剩余时间是否立即重算。

页面不必把这些后台关系全讲给顾客，但展示结果要让人能判断。顾客选完项目和门店后，只看到确实能够完成的日期与时间；没有空档时，说明是当天已约满、该项目未开放，还是指定技师没有时间。原因能区分，顾客才知道换日期、换技师或换门店是否有用。

上线前别只测“能不能下单”，要故意制造资源冲突

预约系统最有价值的测试，不是从头到尾顺利下一笔单，而是把边界条件压在一起。可以先用门店真实项目做一张配置核对表，再逐项验证：

随后用几组容易出错的情况去撞系统：最后一名合格技师和最后一个可用工位是否会被同一订单同时锁住；技师临时请假后，线上时间是否收回；工位停用是否影响相关项目而不误伤其他项目；两位顾客同时提交最后一个时段，是否只有一笔成功；取消、超时、支付失败和改期之后，资源有没有按规则释放。

这些情况都能说清并测通，日历才算建立在真实产能上。项目、技师、工位和时间也不再是四块各自维护的数据，而是同一笔预约从顾客选择到门店交付的完整约束。门店以后增加新项目、调整班次或停用设备，只改对应的事实，系统就能重新算出可预约时间，不必靠工作人员每天手工补漏洞。

公开资料

[1] Microsoft Learn, Define your services in Shared Bookings, 页面标注日期 2024-08-08。

[2] Microsoft Learn, Add team members to Bookings, 页面标注日期 2025-04-10。

[3] Microsoft Learn, Set scheduling policies in Microsoft Bookings, 页面标注日期 2025-04-02。