390.外勤雨雪行程低代码研判调度平台
外勤下雪天怎么派单？低代码调度平台实战拆解
老实讲, 在最初碰到“外勤雨雪行程低代码研判调度平台”此项目之际, 我并未觉察出它有多少厉害之处。
不就是派单吗？不就是看天气吗？不就是调度吗？
从事户外活动工作的人士都有深刻感受, 每当到了降雨落雪之际, 整个排班体系就会陷入瓦解状态, 这时打车变得特别艰难, 根本没办法打到车, 并且道路由于雨雪变得湿滑, 驾驶车辆有着安全风险, 大家都不敢轻易开车外出, 与此同时, 客户还在持续催促, 老板那边也急切需要查看各种数据, 现场简直混乱得如同煮开的粥。
我们这个团队干了三年外勤SaaS，最怕的就是冬天。
然而, 在随后的日子里, 我们察觉到了一个事实, 并非外勤人员难以管理, 而是你所运用的研判逻辑并未正确使用。
为什么雨雪天调度总是“翻车”？
大多数公司用的调度系统，说白了就是个考勤机+地图。
天晴的时候还能凑合用，一下雨就废了。
为什么？
首先, 雨雪天的路况、人效以及风险, 和晴天相比, 是全然处于两个不一样的维度的。其次, 在雨雪天这种特殊天气状况当中, 道路状况是复杂的, 人员工作效率会受到影响, 并且同时存在诸多潜在风险。此外, 晴天的时候, 路况是良好的, 人员工作效率相对稳定, 而且风险也较低。最后, 你要是拿夏天较为理想状态下的数据, 去计算冬天雨雪天的派单情况, 那无疑是自讨骂声。
我们那时与泛微e启营展开合作, 耗费三个月时间，将全国重点城市的雨雪历史数据提取出来, 进行了一次全面的梳理, 最终发觉了一个规律:
雨雪天外勤的有效工作时长，平均缩水40%。
不是人懒，是路难走、是客户取消、是交通工具切换。
所以, 你需得先去承认一个前提条件, 那就是在雨雪天气的状况下呀, 外勤工作的效率必定是会下降的, 可别强行去撑着。
那怎么办？
低代码能不能“救”外勤调度？
能。但前提是你得会搭。
不少人觉得, 低代码不过是将几个控件拖动一番, 制作一个表单, 增添一个审批流, 便称之为“平台”了。
错。
确定为真实的低代码进行研判调度, 其关键要点并非在于编写代码, 而是着重于对规则予以明确界定。
我们做的这个390平台的思路其实特别简单：
首先, 将历史雨雪方面的数据接进来, 接着, 把实时气象的接口接进来, 然后, 把员工所处的位置接进来, 最后, 把客户的地址接进来。
第二步: 运用可进行可视化展示能够呈现直观效果的“规则引擎”来针对相关情况设定具有一定界限范围的阈值。具体来说, 存在这样一些情况, 像是当降雪量超过5mm这个数值的时候, 便会自动触发备选路线这一机制, 以及当出现表现为路面状况的结冰预警这样的情况时, 将依照已定规则强制对派单优先级进行调整。
第三步：让一线主管自己改规则，不用求IT部门
话说回来, 其实就在于将那种凭借主观随意决策的方式转变为依据数据来进行判断, 把通过打电话实施催促行为替代为借助系统进行推送。
客户最关心的三个问题
参与过的都清楚, 外勤调度系统难以推行下去, 并非是由于技术方面存在欠缺, 而是因为这三件事情尚未得到解决:
1. 雨雪天到底派谁去最合适？
不是派遣那处于距离最近位置的, 而是去挑选那在当下路况情形里具备安全特性最为突出、速度最为快捷、客户满意度处于最高水平的。
对于这般复杂的逻辑, 传统系统没办法用来运算从而得出结果。可是, 低代码这个平台却能够达成此事。你可以针对那些相关维度详尽地拆分开来瞧, 就像距离、路况、历史迟到率、车辆类型以及员工当下状态等。借助对这些维度开展加权计算, 系统就能够自行给出推荐。
2. 怎么让员工觉得“公平”？
雨雪天谁都不想出门。你硬派单，员工就辞职。
所以, 我们于平台之中增添了一种模式, 此模式为“自愿抢单 + 保底派单”的双模式。在恶劣天气这种状况之下, 对于那些心甘情愿外出工作的员工而言, 单量将会达成加倍, 补贴也会自行开展计算。然而对于那些不愿意出去的员工来说, 他们能够申请“今日不可调度”, 不过处于这种情形时会扣除相应的积分。
不是强制，是博弈。
系统向你传达这样的信息, 若你不采取行动, 而其他人采取行动, 那么其他人所获取的收入就会高于你, 你自行做出选择。
3. 调度结果怎么看？
很多老板的痛点是：我知道今天调度乱了，但乱在哪？谁的问题？
所以, 我们用心打造了一个专属的, 有着独特风格的、名为“雨雪行程热力图+异常点标注” 的看板, 利用这个看板, 可以清楚地表现出何处出现了拥堵情形, 谁正在进行绕路驾驶, 哪位客户反复实施取消行程等种种状况, 使人一眼就能确切察觉。
不是让你事后复盘，是让你实时干预。
真正的壁垒不在技术，在“研判逻辑”
实情而言, 低代码自身不存在什么门槛。今日你运用咱家的平台搭建, 明日你采用别家的同样能够搭建。
真正拉开差距的，是那个“研判模型”。
就是雨雪天到底怎么打分、怎么排优先级、怎么动态调整。
与泛微e启营的海总团队, 我们磨了半年之久这样长的时间, 费尽诸多心力, 才成功做出一套具备可复用特性的逻辑包。
举个例子：
同样是下雪，北京和上海的处理逻辑完全不一样。
干冷的北京, 其雪呈粉状, 路面结冰速度较快；湿冷的上海, 雪是湿的且存在路面打滑情况, 不过路面不一定会结冰。
所以, 两个城市的“安全系数权重”存在差异, 由此推荐的交通工具亦有所不同。
此物, 于代码中被写死, 你无法予以更改。然而, 借助低代码搭建而成, 各个区域的主管皆可自行进行调试。
别把平台当成“万能药”
写到最后，想说一句可能会让同行不高兴的话：
调度平台解决不了管理问题。
倘若你所在的公司, 原本就不存在对于外勤事项进行管理之人, 原本就不存在关注客户体验之人, 那么即便平台再厉害, 也不过属于一种摆设罢了。
平台只是工具，让好人更好，让懒人更懒。
所以, 我们打造这个390.外勤雨雪行程低代码研判调度平台, 不是为了取代任何人, 而是为了给那些真心想用心做好外勤管理工作的人, 提供一把称手好用的利刃。在他们开展外勤管理事务时, 能借助这一平台工具, 更高效、精准地完成各项任务, 进而提升外勤管理的整体水平与质量。
雨雪天谁都躲不过，但你可以提前知道该怎么办。
这，就是研判的价值。
最新评论