惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

云风的 BLOG
云风的 BLOG
GbyAI
GbyAI
G
Google Developers Blog
Engineering at Meta
Engineering at Meta
月光博客
月光博客
腾讯CDC
Recent Announcements
Recent Announcements
酷 壳 – CoolShell
酷 壳 – CoolShell
爱范儿
爱范儿
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
S
SegmentFault 最新的问题
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
阮一峰的网络日志
阮一峰的网络日志
博客园 - 【当耐特】
The GitHub Blog
The GitHub Blog
Last Week in AI
Last Week in AI
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
aimingoo的专栏
aimingoo的专栏
Google DeepMind News
Google DeepMind News
Y
Y Combinator Blog
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Martin Fowler
Martin Fowler
A
About on SuperTechFans
博客园 - 叶小钗

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
出行行业订单调度系统V1.0版本产品说明
灿烂千阳 · 2023-08-18 · via 人人都是产品经理

网约车行业中的订单调度系统应该如何设计呢?这篇文章里,作者尝试围绕调度方式、匹配系统设计、派单流程等方面进行了说明解答,一起来看一下吧,或许会对想了解网约车行业订单调度的同学们有所帮助。

一、背景介绍

网约车行业订单调度通常来讲有抢单、派单两种方式,根据平台所处阶段、平台运营模式、业务情况、市场供需关系等,决定采取抢单或派单方式。

1. 抢单场景

  • 让更多的车主听到单,增加参与感。
  • 在乘客能够接受的范围内(不能等太久)。
  • 自由选择,减少因派单不合理车主对平台的负面情绪。

2. 派单场景

  • 让乘客能坐到车。
  • 让乘客更快的坐到满意的车(近、服务好、不能取消or取消自动改派)。
  • 让车主行车过程中更安全,能接到单(自动接单)。
  • 最合理的调度、匹配运力。

3. 平台所属阶段

  • 初期:抢单,单少、车辆少,抢单可以增加车主参与度。
  • 发展期:引入派单,采用混合模式,随着车辆的增加,对人、车需要做一定的筛选,按供需关系需要做一定的运力调度,同时也能防止刷单。
  • 成熟期:混合模式,采用类似“滴米”机制,按订单品质决定派单或抢单。

4. 平台运营模式(业务性质)

  • 公司车辆:适合派单,用最合适的车辆接乘客。
  • 社会车辆:适合抢单,增加参与度,减少派单不合理的负面情绪。
  • 专车:优先乘客体验,适合派单。

5. 市场供需关系

当乘客需求 多于 司机服务能力时,适合用抢单。

当乘客需求 少于 司机服务能力时,适合用派单。

二、订单调度

订单调度需要注意以下几个方面:

  • 是否允许异地车接单
  • 订单调度方式

城市限行规则,不能发给被限行的车主。

1. 调度方式

结合行业目前的业务场景,可以使用抢单、派单结合的方式,根据订单品质决定派单or抢单。

订单品质分析算法:

一个订单品质的好坏跟里程、路况、地段、乘客信用都有一定的关系,系统需要从这四个维度进行计算,最终得出一个分数值决定这个单的品质。

后台支持配置每个因子的分数值,总价值100分,超过60分视为好单,默认:

  1. 里程30分;
  2. 路况30分;
  3. 地段25分;
  4. 信用15分;

订单分数值 = 里程分 + 路况分 + 地段分 + 信用分 > 60分,视为好单。

里程:支持按城市配置里程超过多少公里算好单,里程换算分数值(多少分/公里)。

默认配置里程 = 建议远途公里数*60%

默认里程换算 = 1分/公里

算法:

订单路程 = 取地图起点 – 终点驾车路径规划策略5第1条的行驶距离/1000

计算分值 = (订单路程 – 配置里程) * 里程换算xx分/公里 + 里程分*60%

里程分值 = 计算分值小于0则取0,计算分值大于里程分则取里程分。

路况:地图路况分未知、畅通、缓行、拥堵,通过计算畅通路程占订单路程的百分比,得出路况分。

算法:

畅通路程 = 取地图起点–终点驾车路径规划策略5第1条,导航路段信息交通情况未畅通的路段距离和/1000 (技术可以调研是否能通过返回结果的条数进行分析)

路况分值 = 畅通路程/订单路程 * 路况分

地段:

分析订单终点的价值,以订单终点所在位置为中心点,计算一段时间内周围发出的历史订单数量。支持统一配置计算周期、计算范围,按城市配置历史订单超过多少算好单、订单换算分数值(多少分/单)

默认计算周期 = 7天 (统一)

默认计算范围 = 直线2公里(统一)

默认配置订单数 = 50单

默认订单换算 = 0.1分/单

算法:

历史订单数 = 配置周期内,配置范围发出的订单数(起点在范围内)

地段分值 = (历史订单数 – 配置订单数) * 订单换算xx分/单 + 地段分*60%

乘客信用:根据付款及时率、评论情况分析。

目前信用体系的乘客信用分默认为100分。

算法:

信用分值 = 乘客信用分/100 * 信用分

2. 匹配系统设计

怎么评判车主是否适合乘客?

乘客叫车时,系统给周围可能接单的车主计算一个与当前订单的综合匹配值,从静态、动态两个维度进行评判,每个维度包含多个因子,计算所有因子分值之和得出每一个车主与订单的综合匹配值。

综合匹配值 = 基础分 + 静态分值 + 动态分值

基础分:计算匹配值的基础因子,系统可配置,默认1000分。

静态信息:静态信息包括注册时长、历史服务分(最近100单)、车主类型等。V1.0阶段只考虑车主类型。

默认车主类型分 = 普通车主0分;共享合伙人+10分;高级合伙人+15分;

算法:

静态分值 = 车主类型分

动态信息:动态信息包含车型偏好、直线距离、规划距离、路况熟悉度、是否限行等等。V1.0阶段只考虑距离、是否限行,支持配置起点规划距离换算分值。

默认距离换算 = 50分/公里

算法:

距离 = 取地图车主位置–订单起点驾车路径规划策略5第1条的行驶距离/1000

限行 = 取地图起点–终点驾车路径规划策略2的限行结果,1需要减去基础分

(PS:根据城市是否限行决定是否调用地图判断)

动态分值 = 0 – (距离 * 距离换算xx分/公里) + (限行=1 ? -1000 : 0 )

3. 派单流程

派单需要让乘客更快的坐到满意的车,最终目标是派给最可能接单、最应当接单的车主,这样既能保证接单率(用户体验),也能保证服务者的利益。

后台支持配置:

  • 每次筛选车主数,区间[1-10],默认6位
  • 乘客等待时长,区间[30-90],默认60s
  • 系统等待周期,区间[5-15],默认10s
  • 是否自动接单,默认 否(系统给车主自动接单)
  • 车主接单时长,区间[10-30],默认15s
  • 几位车主不接单转抢单模式,默认3位
  • 是否支持车主取消,默认 不允许

静态筛选条件:

  • 空闲且非听单状态
  • 接受派单
  • 根据是否允许异地车接单条件筛选
  • 取城市派单范围内,直线距离从近到远
  • 静态信息分从高到低的6位车主

4. 抢单流程

抢单属于自由选择模式,可以增加车主参与感,需要结合场景考虑乘客是否可接受,系统设计支持多人同时抢单。

后台支持配置:

  • 筛选数量、乘客等待时长、系统等待周期设置同派单
  • 车主接单时长,区间[10-30],默认18s
  • 匹配等待时长,区间[2-10],默认5s
  • 车主听单次数,区间[1-3],默认2次
  • 是否支持车主取消,默认 不允许

静态筛选条件:

  • 空闲且非听单状态
  • 根据是否允许异地车接单条件筛选
  • 取城市派单范围内,直线距离从近到远
  • 静态信息分从高到低的6位车主

专栏作家

灿烂千阳,人人都是产品经理专栏作家。一名专注于跨境电商、网约车出行、货运物流领域的产品经理,拥有深厚的专业知识和实践经验,擅长数字化营销、智能运营、需求分析、数据分析。

本文原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。