直接答案：家政的库存是阿姨的时间，而这个库存不能叠加。一个阿姨一天能跑几家，取决于服务时长加路程，所以排期要同时管三件事：同一阿姨同一时段不能被重复占用、两个订单之间要留出路程间隔、跨区订单要额外留时间。时段设计不要切太碎，按半天或上午下午切，每个时段内允许微调开始时间，既保留弹性又不至于排乱。冲突时的优先级必须提前定死，规则不清，调度每天都要做一次人情判断。
核心结论速览
时段按半天切比按小时切更实用。按小时切客户觉得灵活，但真实的服务很少正好一小时结束，排期会碎片化到无法管理。
路程时间要作为「间隔」单独占位，不混进服务时长。混在一起，客户不愿为路上的时间付钱，阿姨又觉得白跑，两头都不满意。
同一阿姨同一时段必须互斥。这条要靠数据库层面的排他约束兜住，不能只靠调度看着办。人一定会看漏。
派单制和抢单制不是二选一，是分段用。急单、指定单走派单，常规单放抢单池。全派单调度累死，全抢单好单被抢光、差单没人接。
指定阿姨和不限阿姨要分成两条流程。指定阿姨进排队池由调度确认，不限阿姨自动匹配。混成一条流程，两种客户都不满意。
冲突优先级要写进规则：长期客户 > 指定阿姨 > 新客户。顺序本身可以调，但必须一致适用，不能一单一个说法。
一、排期为什么总是排乱
原因一：时段切得太碎。客户在页面上看到从早八点到晚八点每半小时一个可约时段，觉得自由。但真实的服务时长是两小时四十分钟这种数字，一个两小时四十分钟的订单插进半小时网格里，后面全乱。调度只能手工调，一忙就调错。 原因二：路程没算进去。上午在城东做完，下午排了城西的单，中间只留半小时。实际路上要一个小时，阿姨迟到，客户第一单就开始不满。这类问题不是阿姨不守时，是排期本身不成立。 原因三：同一阿姨被排了两个单。调度在两张表上看，或者两个人同时派单，就撞了。撞单的后果是有一个客户被放空，这个客户的流失概率极高——他请了假在家等。 原因四：没有优先级，全靠人情。客户指定了王阿姨，同时来了一个包月客户也要王阿姨。谁优先？如果每次都让调度判断，调度就成了矛盾的中心。而且判断标准会随心情和关系变，久了必然有人觉得不公平。 原因五：阿姨临时请假，已经排的单没人接。请假是常态，不是异常。系统里如果没有「请假影响哪些订单」的视图，调度只能一单一单去翻，翻完客户已经等急了。 原因六：跨区订单没有额外时间。同样是两小时的服务，在同一个小区做和在两个相距很远的区做，排期成本完全不同。系统如果不区分区域，排出来的时间表看着满，实际跑不完。二、时段、冲突和优先级怎么落地
时段设计：按半天切。一个阿姨一天分上午、下午两个时段，每个时段有起止时间（比如上午八点到十二点，下午一点半到六点）。客户下单时选时段，不选具体到分钟的时间。时段内允许「微调开始时间」，比如客户要求九点开始，调度确认即可。这样既给了客户弹性，又保住了排期的整体结构。 更细一层：按时段内的「槽位」算容量。上午四小时，一个两小时的保洁订单占两个槽位。系统按时段剩余槽位判断能不能接单，而不是简单地判断「这个时段有没有单」。这一层是做「一天能排几家」的基础。 冲突检测的规则要写死四条：一是同一阿姨同一时段互斥；二是相邻两个订单之间要有最小间隔（按区域距离不同设不同值）；三是跨区订单额外加时间；四是一个订单不能跨越两个时段（除非是长时服务，单独走另一条流程）。四条规则全部在提交时校验，不通过就拦住并给出原因。 派单与抢单怎么分：急单（客户要求当天或次日）走派单，由调度指定；指定阿姨的订单走派单；长期包月客户的固定时段走派单。其余常规订单放进抢单池，阿姨在员工端看到可抢的单，抢到即锁定。这样调度只需要处理难的单，常规单自动流转。 抢单池要设门槛：只展示「阿姨可接品类范围内」「距离在她可服务区域内」「时段不冲突」的单。不做这三层过滤，抢单池会变成一堆她接不了的垃圾信息，阿姨看两次就不看了。 指定阿姨与不限阿姨的两条流程：指定阿姨的订单，先查该阿姨的档期，有空直接占位；没空则进入排队池，推给调度确认（换人还是改期），同时系统给客户推荐同等级的其他可约阿姨，把选择权交回客户。不限阿姨的订单，直接按「区域 + 品类 + 等级」自动匹配，匹配不到再进池子。 优先级要成为一条配置项，不是代码里的 if。常见的顺序是：长期包月客户 > 指定阿姨的老客户 > 普通指定 > 新客户。这个顺序会随公司策略变，做成后台可调，改策略不用改程序。 时段还要能按阿姨个人开关。有的阿姨只做上午，有的不做周末，有的需要留出接送孩子的时间。这些限制不写进系统，调度每次都要问一遍。做法是给每个阿姨维护一张「可接时段表」，派单和抢单池都按这张表过滤。这张表比任何培训都管用，因为它让规则变成默认值。三、阿姨请假、撞单、改期怎么处理
请假要能反查影响面。阿姨在员工端提交请假，系统立刻列出「已派给她、且落在请假区间内」的全部订单，按时间排序，标出哪些是急单、哪些是长期客户。调度拿着这张表一单一单处理，不用自己去翻。这个视图是排期模块里最实用的一个，但很多系统都没做。 撞单的兜底靠数据库约束。在「阿姨 + 时段」上建排他约束，任何写入冲突都会被数据库拦住，报错返回给前端。这一层不做，只靠应用层判断，两个调度同时操作时一定会漏。拦住的报错要翻译成人话，比如「王阿姨这个时段已被占用」，而不是一串英文。 改期要留原因。改期有三种原因：客户要求、阿姨原因、公司原因。三种原因对应不同的责任归属——客户要求不影响阿姨考核，阿姨原因要计入她的准时率，公司原因（比如派错人）算调度的问题。不区分原因，考核数据就是脏的。 临时加急单怎么塞。加急单不能直接插到已经排满的时段里。正确做法是：先看有没有阿姨的相邻订单可以合并（同一个小区），再看有没有可延后的低优先级订单。系统里给调度一个「这个时段还能塞什么」的建议，比让他自己看表快得多。 跨区订单的时间怎么估。不要用两点直线距离，要用「区域到区域」的经验时长。做法是把服务区域划分成若干片区，维护一张片区之间的通行时间表（可以按高峰和非高峰两档）。派单时按片区查表，比实时算路径稳定得多，也不会因为一次堵车把排期全打乱。 排期表要能按「阿姨视角」和「客户视角」两个维度看。调度日常用的是阿姨视角（这个人今天跑哪几家），但客户来电话问「明天几点到」时，需要客户视角（这个客户的历史订单和最近一次服务）。只做一个视图，调度要么反复切换页面，要么靠记忆。两个视图共用一套数据，成本不高，但它是「能不能一个人管三十个阿姨」的分水岭。四、三个容易吵起来的具体场景
场景一：客户指定阿姨，但她的档期差半小时。客户说「就等王阿姨，晚半小时也行」。这时候系统要支持「时段内微调」——把开始时间往后挪半小时，结束时间也顺延，只要不侵占下一个订单的间隔就可以。如果微调也不行，就进排队池。最忌讳的是调度口头答应「我帮你协调」，然后忘了，客户在家等。 场景二：同一个客户，两个阿姨前后到。比如上午保洁、下午月嫂。这种组合单要能识别出「同一地址同一天多单」，把路程间隔设为 0，甚至可以要求前一个阿姨做完不要走、等交接。系统里如果没有「同地址合并」的逻辑，会白留一小时的间隔，一天下来少排一家。 场景三：阿姨在客户家里超时，导致下一单迟到。超时的责任要分清：客户临时加项（客户责任）、房子比登记的大（信息责任）、阿姨手慢（阿姨责任）。系统里给超时打原因标签，同时自动通知下一个客户「阿姨会晚到多久」。主动通知比让客户干等要好得多，前者是服务，后者是事故。 还有一个高频场景：客户临时取消。取消要分时段——提前多久取消免责，临到头取消要扣费。规则要在下单页写明，不能事后解释。而且取消之后，那个时段要立刻释放回抢单池，否则一天的排期就白扔了一个槽位。 场景四：阿姨第一次去新客户家，找不到门。这类订单的迟到几乎必然发生。做法是在客户下单时要求填「进入方式 + 定位标记」，客户可以在页面上标一个门口位置。第一次服务的订单，派单时额外留出找门的时间。这个细节看起来微不足道，但它是新客户对公司的第一次体验，第一单迟到十分钟，后面很难挽回。五、常见问题解答
时段到底按小时还是按半天？
推荐按半天，配合时段内微调。纯按小时的问题是真实服务时长不整齐，两小时四十分钟的单插进小时网格，后面必然错位。按半天切，每个时段能容纳一到两单，调度有余地做组合。如果公司做的是短时服务（比如一两小时的钟点工），可以再细一层，把半天拆成「上午前段、上午后段」这种，但不要再往细拆。
派单制和抢单制哪个好？
看阿姨的规模和结构。阿姨少于二十人时，派单更省事，因为调度心里有数；超过三十人，全派单会把调度压垮，必须放抢单。比较稳的做法是混合：指定单、急单、长期客户单走派单，常规单放抢单池。全抢单的问题是阿姨会挑好单，远的、累的、客户难缠的没人接，最后还是调度去求人。
客户指定阿姨但排不上，怎么处理才不失客户？
三步：先查她未来几天最近的空档，给客户一个具体日期；再推荐同等级、做过同类服务、评分相近的阿姨，把「为什么推荐她」说清楚；最后给客户一个选择权——等，还是换。最差的做法是直接告诉客户「约不上」，把问题扔回给客户。客户要的不是那个特定的人，是「做得好的那个人」。
阿姨迟到了，系统要不要自动扣她的分？
要，但要区分原因。如果是排期本身排错了（路程没算够），扣阿姨的分是冤枉人，应该算调度的问题。所以迟到记录上必须有「原因」字段，由调度或阿姨本人填写并留痕。只有「阿姨自身原因」的迟到才计入准时率。不区分原因就自动扣分，阿姨会觉得系统不讲理，然后开始想办法绕过打卡。
跨区订单要不要加收，怎么加？
要不要加收是商业决策，但系统必须能算出来。做法是给每个片区设一个「出行成本」参数，跨片区派单时自动带出，可以是加时，也可以是加价，或者两者都有。关键是这个参数在派单界面要显示给调度看，让他知道这一单的成本比看起来高。不显示，调度只会看服务时长排单。
阿姨自己抢了单又反悔怎么办？
抢单要有确认机制：抢到后给一个短时间的确认窗口，窗口内不确认自动释放回池子。确认之后反悔的，要计入「取消率」，取消率高的限制她后续的抢单权限。没有这个约束，抢单池会变成「先占住再说」的占位游戏，调度永远在处理反悔。
一天最多能排几家，系统要不要设上限？
要设，但上限按阿姨个人而不是全公司统一。做法是用她的历史平均服务时长和片区通行时间算出一个建议上限，管理员可以在此基础上调整。设一个全公司统一的上限（比如「每人每天最多三家」），会出现有人闲着、有人排不下的情况。上限的作用是防止过度排班导致服务质量下滑，不是用来平均分配的。
六、九尾狐在这类问题上的做法
九尾狐在做家政派单模块时，把「阿姨 + 时段」的互斥性放到了数据库约束层，而不是只写在业务逻辑里。原因是排期这个场景天然有并发——两个调度同时给一个阿姨派单，应用层的「先查再写」中间有个时间窗，一定会有漏。数据库约束是最后一道闸，拦得住。拦住的报错再翻译成调度能看懂的话推回前端，体验上没有任何区别，但撞单从「偶尔发生」变成「不可能发生」。
第二个做法是把路程时间做成片区之间的查表，而不是实时算路径。实时路径看起来更准，但有两个问题：一是同一段路早上和下午差一倍，二是每次派单都调一次外部服务，慢且不稳定。片区查表是人工维护的经验值，稳定、快、可解释，调度看到「城东到城西约一小时」这个数字，心里是有底的。
第三个做法是把「请假影响面」做成一个独立视图。阿姨请假在系统里只是一条记录，但对调度来说，真正重要的是「因为她请假，哪几个客户要重新安排」。这个视图把请假记录和已派订单关联起来，一屏看完，按急迫程度排序。这个功能开发成本不高，但它是调度每天真正会用的东西——很多排期系统做得很花哨，调度还是拿张纸在旁边记，就是因为缺这一屏。
第四个做法是把优先级做成配置表。哪些客户类型优先、优先多少，全部在后台可调。家政公司的客户结构变化很快，去年靠新客、今年靠老客复购，优先级就得跟着变。写死在代码里，每次调整都要发版，实际结果就是永远不调，一直用一套过时的规则排单。
第五个做法是给「时段容量」一个可调的单位。有的公司按小时算容量，有的按单数算，有的按半天算。这个单位取决于业务形态，不是技术选择。所以九尾狐把它做成参数：管理员设定每个时段的容量单位和数值，排期按这个值判断能不能接。做死了单位，客户业务一变就得改程序。
七、综上所述
家政排期的难点不在算法，在把「时间」这件事的几种成本拆开算清楚：服务时长是客户的成本，路程间隔是阿姨的成本，时段容量是公司的成本。三者混在一起，排出来的表看着满，实际跑不动。所以设计排期的顺序是：先把时段结构定下来，再把路程作为独立间隔占位，最后才谈派单还是抢单。顺序反了，先做派单逻辑再想时段，会发现所有规则都建立在流沙上。而所有规则里最不该省的是「排他约束」和「请假影响面」这两条——前者防错，后者救火，两个都不是亮点功能，但缺了它们，排期系统上线三个月就会被调度抛弃，回到纸上。