陪诊资源调度系统：精准投放人力到三甲医院一号难求时段

陪诊这个行业表面看是人力的生意本质上拼的是调度。用户付钱买的不只是“有人陪着看病”而是“在正确的时间、正确的地点有一个靠谱的人接手”。很多团队初期单量少人工排班还能应付一旦铺开两三个区、对接十几家三甲医院就会发现最大的瓶颈根本不是获客而是“人手永远不在该在的地方”——早高峰的老年科排队两小时陪诊员却全被抽去送检下午妇科清闲人却扎堆闲着。我参与过的一套陪诊资源调度系统核心就是解决这个问题。它不搞花哨的AI问诊也不做复杂的健康管理只专心干一件事基于区域就诊高峰和人群画像提前调配陪诊员把人力精确投放到三甲医院“一号难求”的时段上。这套系统上线后我们单日有效接单率提升了将近四成陪诊员空驶时间下降明显患者侧的“约不到人”投诉也基本绝迹。今天把整个设计和落地方案拆开讲透。1. 需求拆解为什么陪诊系统最缺一个“调度中枢”很多人以为陪诊系统就是个“滴滴打车”的医疗版用户下单、系统派单、陪诊员接单完事。真做过就知道这套逻辑在陪诊场景下根本跑不通。挂号、就诊、取药、检查每一个环节都有严格的时间窗口。患者挂了上午10点的专家号陪诊员必须提前到、先报到、再排队如果像网约车一样“附近有单就派”很可能出现陪诊员到了医院患者却还在路上堵着或者陪诊员跟着患者做完一个检查下一个项目要等两小时这段时间就完全浪费了。更麻烦的是时段错配。三甲医院的资源高峰非常集中周一上午、周三上午、节假日后的第一天这几个时段的专家号基本是“一号难求”的状态患者量井喷陪诊需求也井喷。但陪诊员的供给是有限的如果没有提前调配就会出现“忙的时候忙死、闲的时候闲死”的极端不平衡。我们之前踩过一个很典型的坑某天周五下午系统显示某三甲医院周边有6个陪诊员在线但当天下午该院只有2个陪诊订单。而同一天上午另一家医院的神经内科排队爆满需要陪诊的患者有十几单可附近只有3个陪诊员大量订单被迫取消。原因很简单——人力全凭感觉分配没有数据支撑。所以这套“资源调度中枢”的设计目标就非常明确了提前预判不只响应即时订单而是基于历史数据和区域特征提前预判未来几天哪个医院、哪个时段会出现陪诊需求高峰。画像匹配不同患者对陪诊员的要求完全不同——老人需要耐心、懂方言孕妇希望体力好、动作利索带孩子的家长需要能帮忙照看。画像匹配决定了服务质量和复购率。动态调配把陪诊员当作可调度的资源池而不是“谁离得近谁接单”通过合理的调配策略让人力始终覆盖在最需要的时段和位置。说句实话这个“中枢”的技术门槛并不高但业务逻辑的复杂度远超预期。它不是一个单纯的派单系统而是一个集预测、画像、调度、风控于一体的综合引擎。2. 数据底座区域就诊高峰与人群画像的构建逻辑做调度最关键的是先搞清楚“需求长什么样”。我们当时没有上来就写算法而是花了两周时间梳理历史数据把三甲医院的就诊规律摸了个透。2.1 区域就诊高峰的时域特征数据源主要来自三部分陪诊平台历史订单数据、医院公开的放号时段信息、以及本地就医攻略类社区的热度数据。三条数据交叉验证能比较准确地还原出“哪个时间段大家最挤破头想挂号”。我们统计了合作区域内所有三甲医院近一年的数据发现几个共性规律时段特征典型场景需求强度周一上午 8:00-11:00各科室专家号集中放号复诊患者扎堆极高周三上午 9:00-12:00部分医院特色科室出诊日高节后第一天全天积压患者集中返院内科、外科全面爆满极高周末上午家长带孩子看儿科、眼科中高工作日下午慢性病复诊、取报告、开药中低这个表看上去简单但背后有几个值得注意的细节。周一上午的“极高”不是平均意义上的高而是峰值极端突出。我们用分位数而不是平均值来衡量比如把一周内每个小时的订单量取90分位数能更精准地找到真正的“一号难求”时段而不是简单看平均数。另外高峰时段有“传染效应”——某个三甲医院一号难求时周边二甲医院、社区医院也会跟着忙起来因为挂不上专家号的患者会退而求其次。但陪诊员往往只盯着大医院导致中小医院的订单覆盖不足。这个发现对后面的调度策略影响很大。2.2 人群画像的分层维度如果说高峰预测解决的是“何时何地有多少需求”那人群画像解决的就是“这个需求需要什么样的陪诊员”。刚开始我们走了弯路画像做得过于复杂收集了很细的标签结果调度模型反而不知道怎么用了。后来把画像收敛到四个核心维度就医类型画像常见病、慢性病复诊、术前检查、术后复查、孕产检查、儿科陪同。不同就医类型的动线和耗时完全不同直接决定陪诊员的排班时长。患者年龄画像老年患者需要更多耐心和时间余量中年患者效率优先儿童患者需要额外的安抚能力和陪同经验。辅助需求画像是否需要轮椅推送、是否需要代排队缴费、是否需要方言沟通、是否需要帮忙解读医嘱。时间敏感画像有些患者时间很充裕愿意等待有些患者是请假出来的恨不得精确到分钟完成所有项目。有意思的是画像不是越细越好而是越“可执行”越好。我们最后提炼出七种主流的“陪诊任务类型”每种类型对应一组标准的时长估算、动线模板和服务要求。调度系统不需要理解每个患者的个性化需求只需要匹配到正确的任务类型就能做出合理的排班决策。2.3 一号难求时段识别的实操方法“一号难求”不是拍脑袋说出来的需要用数据来定义。我们采用了一套组合判定法第一步计算放号紧张指数。通过历史订单中“预约成功率”和“放号后多长时间被抢光”两个指标给每个医院每个时段的“一号难求”程度打分。比如某院周一的专家号放号后在3分钟内就被抢完同时平台预约成功率不到10%那这个时段就是极端紧张型对应的陪诊需求不仅量大而且患者对陪诊员的“抢号能力”要求也高——需要在放号瞬间盯紧余号。第二步叠加天气预报和特殊日期。实测发现雨天、极端高温天、雾霾天的陪诊需求比晴天高出三成左右——很多年轻人会在这类天气给父母下单陪诊服务就是为了不让老人自己跑医院。这种外部变量必须纳入预测模型。第三步结合医院动态放号信息。有些医院会临时加号或增加周末门诊这些信息一出现就会制造短时需求峰值。系统需要监控医院公开的就诊公告页面一旦发现“加号”信息立刻触发调度预案。识别出“一号难求”时段后剩下的工作就是让陪诊员“恰好出现在那里”这就引入了调度层的设计。3. 调度引擎从被动派单到主动预置调度中枢的核心是把传统“订单来了再找人”的模式改成“提前预知需求、提前布防人力”的模式。这个逻辑的转变是整个系统价值的根本所在。3.1 动态分区与时段分级医院周围的陪诊员不是平均分布的所以我们对服务区域做了动态网格化分区。以三甲医院为圆心按步行距离和交通便利度划分出三个圈层核心圈医院周边500米内陪诊员可迅速到达。辐射圈医院周边2公里内骑行或地铁10分钟内可到达。机动圈城市范围内可调度资源用于突发情况和跨区支援。每个圈层的陪诊员数量不是固定的而是随着“一号难求时段”的靠近而动态调整。你可以理解成“人员预热”——在高峰时段来临前30分钟系统就开始向核心圈推送“待命状态”的调度指令让陪诊员提前往目标医院附近靠。我们内部管这叫“暖场”。时段分级则是把一天划分为五级级别时段示例调度策略S级周一上午 8:00-10:00全员待命提前一天锁定人员A级周中上午 9:00-11:00核心圈提前30分钟预热B级周末上午按日常排班灵活调配C级工作日下午按单触发正常响应D级晚间、夜间仅保留紧急预约这个分级不是写死的系统每周都会根据上周的实际订单数据做自动调整。S级时段如果连续两周没有出现预期中的高需求就会降级避免人力浪费。3.2 三层递进的调度规则引擎调度引擎的直接任务是把“一个陪诊任务”分配给“一个合适的陪诊员”。我们设计了一套三层递进的匹配规则而不是一步到位的“最优匹配”好处是计算速度快且便于人工介入调整。第一层硬性过滤。先把不满足基本条件的陪诊员剔除。比如老年患者订单要求陪诊员必须会当地方言那不会的陪诊员直接排除再比如妇科检查订单女性陪诊员优先平台上标注“仅限女性”的订单男性陪诊员直接不显示。这一层不做复杂计算就是SQL过滤但能大幅降低后续匹配的计算量。第二层能力评分。对过滤后的陪诊员按四个维度打分本人所在区域与医院的通达距离、历史完成单量、该类型任务的接单量、用户评价中的相关标签。四个维度加权求和得到一个能力分。默认权重是距离占40%、历史单量占30%、同类经验占20%、评价占10%。这个比例不是拍脑袋定的是先跑了两周模拟对比了多种权重组合下的订单完成率和投诉率后选的。第三层压力均衡。如果有多个能力分相近的陪诊员优先选当前“负载压力”最小的那个。每个陪诊员都有一个实时压力值——正在进行的任务数加待接单数。这个设计是为了避免“能者多劳”变成“能者过劳”防止个别优质陪诊员被系统反复派单导致服务体验下降。这套三层规则的好处是可以随时在某层上做“人工覆盖”。举个例子某陪诊员能力分不是最高但距离目标患者只有300米而系统评分最高的陪诊员在3公里外。调度员可以在第二层手动调高距离的权重让就近的陪诊员优先接单。实际运行中这种人工干预每天都有规则引擎保证的是“大部分单子不需要人操心”。3.3 前置调配策略提前24小时与提前2小时这里要重点讲一下“提前调配”的落地方式。我们在调度引擎里设了两个关键的时间节点提前24小时预排。系统基于历史数据和已知的号源信息预测第二天的S级和A级时段在晚上统一生成一份“明日预排计划”。这份计划不是强制指派而是给陪诊员推送“明日某时段某医院将有大量需求建议提前锁定接单区间”的通知。愿意响应的陪诊员可以提前占位响应率高的陪诊员会获得积分加成。这套机制上线后S级时段的接单响应率从不足50%提升到了85%以上。提前2小时确认。在预计高峰来临前2小时系统会基于实时订单数据做二次校准通过微信小程序向目标区域内的陪诊员发送“高峰预警”推送同时开启周边区域的支援通道。如果这个时候预测需求已经远超本区域人力供给系统会提示调度员开启跨区调配流程。跨区调配要解决的一个现实问题是交通成本。陪诊员跨区支援往返可能要多花40分钟通勤如果没有补贴没人愿意干。我们的方案是设置“支援溢价”机制——跨区订单的服务费提升15%溢价部分由平台和患者侧共同承担。这个比例定的不算高但因为有稳定的预期高峰长期算下来陪诊员跨区接单的意愿是够的。4. 实操过程从数据接入到开城落地的完整步骤这套系统不是一次性建成的从数据接入到真正能辅助调度决策我们走了大概两个月。这里把过程中的关键步骤和踩坑经历整理成可以直接参考的执行手册。4.1 第一步历史订单数据清洗与标注核心提示清洁的历史数据是一切预测的前提。我们接入的第一份数据是本平台过去一年的订单记录。但这个数据远看很完整细看惨不忍睹——订单创建时间、服务开始时间、服务结束时间三个字段经常对不上还有大量取消单、爽约单混在有效数据里医院的名称也存在多个写法混乱的情况。清洗分三步走标准化医院名称。同一家医院在订单里可能有五六种写法比如“第一人民医院”“市一院”“人民医院总院”其实是同一家。我们维护了一份医院别名表把所有订单统一映射到医院标准ID上。剔除无效订单。只保留“已完成”和“服务中”两个状态的订单用于预测训练。取消的、超时未接的、金额异常的全部打标剔除。否则模型会把异常当成正常需求学习进去。修正时间字段。服务开始时间如果早于订单创建时间就用订单创建时间作为兜底服务结束时间缺失的用订单金额和任务类型估算。虽然不完美但比直接弃用要好得多。4.2 第二步外部数据接入与对齐除自有订单外外部数据最关键的是医院的放号时间表和门诊排班公告。我们当时和某家三甲医院的信息科做了数据对接试点通过医院公开的预约挂号接口拿到了未来一周的放号计划和专家出诊时间表。这组数据对应到调度系统就成了“黄金数据”——出诊专家一明确当天的就诊动线和高峰时长就能初步推算出来。但这一步后来发现有个坑医院的排班信息有时会临时调整专家停诊、加号都会引起需求波动。所以系统不能只对接一次必须保持日更。我们建了一个定时任务每天凌晨同步一次早上再增量同步一次。信息一旦变化立刻重新计算后续时段的需求预测和人员配置建议把影响消化在第一时间。实时性的重要性怎么强调都不过分。上个月某医院临时发布通知知名专家将在三天后开放10个加号名额凌晨公告早上就抢光了。我们系统在凌晨识别到这条公告自动向周边待命陪诊员推送了“明日可能新增需求”的预警当天上午确实出现了12个新增陪诊需求全部由提前到位的陪诊员接住了。如果还是纯靠人工盯公告这12单大概率会流失。4.3 第三步预测模型的轻量化实现预测模型这块我们没有一上来就上深度学习。原因很实际样本量撑不起复杂模型而且算力部署也麻烦。最终的方案是“梯度提升树 简单规则修正”的组合方案。核心特征选了这么几组历史同期值上周同一天、上个月同一天、去年同期医院级别与科室类型组合当日和次日天气数据温度、降水概率是否节假日、节后第几天医院近一周的线上预约热度指数模型预测的不是绝对订单量而是“需求等级”——S/A/B/C/D五级。为什么这么做因为绝对数字预测误差大容易让调度动作过拟合但分等级预测足够稳定且对业务动作的指导意义更强。调度员不需要知道“明天上午9点会有37个订单”他只需要知道“明天上午9点需求等级是S级需要全员上”。模型上线后用滚动验证法检验了四周预测准确率达到80%以上。“准确”的定义是预测等级与实际上报等级一致或者最多差一级。这个精度对人力调度来说完全够用。4.4 第四步系统联动与实时监控面板调度系统不是孤立的它必须和接单系统、陪诊员端小程序、调度员后台联动起来。我们做了三块核心面板需求热力面板以地图形式展示未来48小时各医院“一号难求”时段的分布颜色由绿到红表示需求热度。调度员一打开面板就能看到哪里即将爆发需求不需要自己去翻数据报表。人力分布面板实时展示所有在岗陪诊员的位置、状态和压力值。与需求热力面板叠加后能直观看到“需求热点”和“人力富余区”之间的错位关系调度员可以手动发起调配。缺口预警面板系统根据需求预测和当前人力供给自动计算未来4小时内的缺口指数。缺口指数超过阈值时面板亮起预警并弹出建议动作例如“建议从B区域调配3名陪诊员支援A院”。这套面板体系上线后调度员从“被动接电话、手动找人”变成了真正的管理者角色。主观判断仍然保留但决策依据从拍脑袋变成了看数据。对于新加入团队的调度员培训时间从原来的两周缩短到三天。5. 常见问题与排查技巧实录系统上线不代表万事大吉。以下是实际运行中容易踩的坑以及对应的排查思路基本覆盖了新搭建同类型系统最常遇到的问题。5.1 预测模型频繁“低估”需求怎么办现象系统预测的S级时段实际上来了翻倍的订单导致大面积订单无陪诊员可接。排查思路先看数据源对吧。最常出现的情况是外部特征没有纳入——比如某医院临时开了新科室、某专家停诊一周后复出、或者本地突然有大型免费筛查活动。这类信息如果只靠历史数据预测模型当然看不到。我们的做法是先设置人工事件标记功能调度员发现异常波动可以手动在系统里打一个“热点事件”标签该标签会在后续训练中作为特征参与计算。同时给模型加一版“上限保护”——当预测值为A级时按A级上限的1.3倍做人员预留宁多勿缺。5.2 陪诊员不按调度预排走怎么办现象提前24小时的预排计划推送了但第二天早上陪诊员没到位出现在别的区域接了“顺路单”。这其实是机制问题不是技术问题。根本原因是预排计划没有和派单系统强绑定。我们的方案是加入了预排单锁定机制——陪诊员响应预排后系统会在对应时段自动暂停为其分配其他区域的订单除非该时段预排订单被取消。等于说你既然答应了明日去A院帮忙就不能中途被别人截走。副产品是平台上的“爽约率”也降了因为预排订单设置了违约扣分与积分权益直接挂钩。5.3 跨区调配“调不动人”现象缺口预警弹出来了但周边的陪诊员就是不响应跨区支援指令。原因通常有两个一是支援溢价没有吸引力二是跨区后接不到返程单陪诊员担心空驶回来。我们后来做了一个很简单的方案——组合单模式跨区支援的陪诊员完成目标医院订单后系统自动给其推送该院周边一定范围内的返程单或者在无合适返程单时额外补贴一段交通费用。这个方案一出跨区响应率立竿见影。核心逻辑是调度不能只让陪诊员“出一趟差”要让他“跑一趟活”有头有尾。5.4 患者画像不准导致匹配失败现象系统给老人匹配了一个年轻陪诊员但老人明显不适应服务投诉率飙升。画像不准主要发生在两类情况一是患者本人不会下单是子女代下单实际的“患者画像”和“下单人画像”混在一起了二是患者信息是几个月前填的近期病情变化辅助需求已经不同。我们的解决方式是在订单创建环节增加一道动态确认机制下单完成后系统会与下单人二次确认几项关键标签包括患者年龄、是否需要轮椅、是否需要方言陪护、预计就诊时长。虽然只多了四五个问题但画像准确率提升非常明显匹配投诉率下降了60%。5.5 极端天气冲击预测模型还有一次比较特殊的经历暴雨红色预警那天系统预测的需求量是平常的1.2倍但实际订单量冲到了1.8倍导致很多订单延误。事后复盘问题出在天气特征的编码方式上——我们把降水概率设为了连续数值特征但模型并没有学习到“红色预警”这个离散标签的极端影响。后来我们把天气特征改为分级标签比如“暴雨红色预警”单独设一级在模型中拥有独立权重。从那以后每遇到极端天气系统给出的预测会明显比普通雨天更高调度预置也更激进。5.6 冷启动城市没有历史数据怎么办展开新城市时没有历史订单数据预测模型直接失效。我们的冷启动方案是先用当地医院的放号时间表做初步分级判断——参考医院等级、放号数量和抢空历史再结合对标城市相似规模的医院数据做迁移学习。简单来说就是“拿成型的规律去套新城市然后在前两周用实时数据不断修正”。第一周允许调度员按经验值人工干预第二周开始参考系统建议第三周以后系统预测权重逐步上调。三周后系统基本可以独立支撑调度决策。6. 最后分享一点实际运行的体会做完这套系统我最大的感受是——技术难题反而比想象中小真正难的是让“一线的人愿意用并且用起来不别扭”。调度员一开始是不信任的他们觉得自己的经验比系统靠谱。后来我们做了个折中系统只提供“建议”调度员可以一键执行也可以手动修改。慢慢他们发现系统建议的S级时段确实订单多系统建议调配的区域确实需求旺信任就建立起来了。陪诊员那边也一样“预排锁定”机制一开始被抱怨约束太多但当他们发现锁定时段内订单源源不断、收入稳定后反而主动要求多参与预排。如果你也在规划类似的资源调度型系统我的建议是先别急着搞复杂的模型。把基础工作做扎实——数据清洗干净、医院别名统一、放号信息接进来这些脏活累活占了很多时间但回报率是最高的。预测模型用梯度提升树起步完全够用规则引擎比黑盒模型更容易调试和维护。等跑通了小区域再慢慢扩展城市和算法复杂度这个顺序比较稳。现在这套系统支撑了我们平台上大部分重点区域的陪诊服务下一步我们打算把医保结算进度、院内导航热力图这些数据也接进来让调配颗粒度进一步细化到科室级别。到时候“一号难求”的覆盖还能再往前挪半小时。