成丰货运平台 · 货主端运输计划使用体验提升与产品优化
本方案旨在系统性解决成丰货运平台运输计划功能的以下三大问题:
| 序号 | 目的 | 说明 |
|---|---|---|
| 1 | 清除bug与体验问题 | 解决运输计划功能目前存在的bug及产品体验问题,初步提升用户体验 |
| 2 | 提升使用粘性 | 通过功能优化和体验提升,让货主愿意持续使用运输计划功能,而非仅作为"必填项"敷衍填写 |
| 3 | 扩大有效使用 | 让货主更多更好地使用公司目前的运输计划产品功能,提升运输计划的真实使用率(目前预估仅20%以内) |
经与客户成功部门沈宝海沈总、承运部门梁元峰梁总沟通了解到,目前运输计划虽为平台必填项,但实际真正使用成丰平台运输计划功能的货主占比很低,预估在20%以内。大部分货主仅因平台强制要求而敷衍填写运输计划,并未真正将其作为日常物流管理工具使用。
基于行业调研和客户成功部门反馈,影响运输计划使用率的核心因素可归纳为以下几类:
| 序号 | 因素类别 | 详细说明 |
|---|---|---|
| 1 | 需求侧因素 | 订单需求波动大,中小货主计划变化快;受政策因素、环保因素、环境因素、价格因素等影响需求变化导致运力需求波动较大;货源供给不稳定导致实际发运量与计划不符 |
| 2 | 运力侧因素 | 车辆可用性不稳定(年检、维修等);运力信息不对称,货主无法实时掌握可用车辆状态;空驶率高导致运力浪费 |
| 3 | 信息协同因素 | 货主→调度→司机之间信息传递滞后,依赖电话/微信沟通;大中型货主中了解计划的人与操作系统的人不一致;缺乏实时跟踪 |
| 4 | 产品与工具因素 | 操作体验不佳,存在bug;校验规则不合理(如已计划车数不得为0);功能设计未充分考虑不同规模货主的差异化需求 |
| 5 | 管理因素 | 大量中小货主仍依赖Excel、电话、微信群制定计划;缺乏数据分析支撑;异常处理机制缺失 |
核心结论:运输计划使用率低的根本原因不在于货主不需要计划,而在于产品功能不够好用、不够灵活、不够贴合不同规模货主的实际业务场景。本方案的核心思路是:先修bug、改善体验 → 再调研真实需求 → 再持续迭代,逐步让运输计划从"不得不填写"变为"主动使用"。
本项目采用分步推进策略,循序渐进,每一步的成果为下一步的输入,确保方案执行稳健有效:
目标:梳理运输计划产品功能、清除目前存在的bug问题、产品问题,初步提升用户体验
输出:V1版产品优化迭代方案(含bug修复、规则优化、流程优化)
关键动作:
目标:通过客户调研了解真实需求,为后续迭代提供方向
输出:V2版产品优化迭代方案
关键动作:
目标:逐步完善运输计划功能,提升共性能力,满足更多货主需求
输出:持续迭代的产品功能版本
关键动作:
| 编号 | 截图 | 问题描述 |
|---|---|---|
| B01 | ![]() | 已抢单车数未能随实际的抢单操作数据变化而变化。例:实际抢单成功(已创建运单3单时),前端展示页面仍显示已抢单为2,且当前待审核运单显示为2,但已抢单为0。 |
| B02 | ![]() | 已计划4车,订单车数为30车,剩余未计划仍显示30车,应为26车。 |
| B03 | (无) | 信息内容展示bug,货主端与司机端的剩余可抢单数不一致。 |
| B04 | ![]() | 在选择每日不限量时,剩余可抢单数据错误。已有2个待审核订单,已计划30车,剩余可抢单数应为28车。 |
| ... | (待补充) | (待补充) |
| 编号 | 目前的问题 | 用户体验改进内容 |
|---|---|---|
| U01 | 订单车数、已计划、已抢单、剩余可抢单与待装车、待卸货、待收货审核区域内容展示部分,信息展示方式优化、区域区分不明确。 | 通过优化页面布局及展示方式,表现各数据相互逻辑关系,让货主更容易明白相关数据的含义。 |
| U02 | 目前字段信息含义说明暂无。 | 可通过增加信息字段说明,提升用户体验。 |
| U03 | 在创建、修改运输计划时,目前货主无法获知相关规则,如每个数据的设置上限、哪些数据不可为空、哪些数据设置了会相互影响。 | 可在相关规则设置时标注规则要求,让用户在创建、修改运输计划时明确告知规则,无需反复尝试来验证规则。 |
| ... | (待补充) | (待补充) |
以下为运输计划功能的现有业务规则,经当前负责测试的同学和前任产品经理确认(2026-07-06)。这些规则描述的是产品当前的运行逻辑,供研发、测试等所有相关同学作为信息同步和参考依据:
已计划 ≤ 订单车数)。创建和修改运输计划时均受此约束。已计划车数是货主当前已安排计划的部分,不能超过货主发布货源时设定的订单总需求。
已计划 > 0,即已计划=0 → 系统拦截,无法创建)。剩余可抢单 > 0,即剩余可抢单=0 → 系统拦截,无法保存)。说明:以上13条规则为现有业务规则,描述的是产品当前的运行逻辑。其中规则12、规则13已有计划中的优化变更(需求迭代 RR20260623274028,待上线),详见B01/B02对应的优化内容。本次第一步优化仅改动规则12和规则13(即B01/B02),不改动上述其他11条规则。
第一步的V1版优化方案包含以下功能点:
| 序号 | 功能模块 | 功能点 | 优先级 | 说明 |
|---|---|---|---|---|
| 1 | 创建计划校验优化 | 创建运输计划时允许已计划车数为0 | P0 | 原规则拦截已计划=0,优化后允许创建。已计划=0时司机端可见但无法抢单;货主后续调整为>0后司机才能抢单 |
| 2 | 修改计划校验优化 | 修改运输计划时允许剩余可抢单车数为0 | P0 | 原规则拦截剩余可抢单=0,优化后允许保存。剩余=0时司机无法继续抢单,已抢单的运单正常执行。已计划<已抢单时仍拦截 |
| 3 | 司机端展示适配 | 已计划为0时的司机端展示 | P0 | 已计划=0时展示"0/0车"或"待定",抢单按钮不可点击 |
| 4 | 交互提示优化 | 创建/修改页面增加实时提示 | P1 | 已计划=0时提示"司机可见但无法抢单";剩余可抢单=0时提示"司机无法继续抢单" |
| 5 | 页面布局优化 | 优化数据区域展示,区分逻辑关系 | P1 | 优化订单车数、已计划、已抢单、剩余可抢单与待装车、待卸货、待收货审核区域的页面布局及展示方式,表现各数据相互逻辑关系 |
| 6 | 信息字段说明 | 增加字段信息含义说明 | P1 | 对各数据字段增加信息含义说明,帮助货主理解字段含义 |
| 7 | 规则提示优化 | 创建/修改时标注规则要求 | P1 | 在创建、修改运输计划时,标注各数据设置上限、非空要求、数据间相互影响等规则说明,让用户明确了解规则,无需反复尝试来验证 |
第二步的核心是通过对不同类型、不同规模货主的调研,了解运输计划的真实需求和流失原因,为V2版优化迭代方案提供方向指引。调研客户分类如下:
调研目标:了解他们对运输计划的需求是什么,需要哪些优化
挑选数量:每类型1-2个客户
调研内容:
调研目标:了解为什么不使用了,哪些问题或功能不合理阻碍了正常使用
挑选数量:每类型1-2个客户
调研内容:
| 调研方式 | 适用场景 | 说明 |
|---|---|---|
| 客户访谈(电话) | 不适合走访的客户(已经在调研客户名单中的) | 直接与货主或操作人员沟通,了解使用情况和需求 |
| 内部数据分析 | 正在使用的客户以及全部客户的数据对比 | 由客户成功/承运部门/大数据部门提供使用数据、活跃度等 |
| 现场走访 | 中大型货主 | 深入了解企业内部物流管理流程和人员分工 |
| 序号 | 输出物 | 内容 |
|---|---|---|
| 1 | 客户调研报告 | 各类型客户的调研结果汇总,包括使用原因、流失原因、功能需求、优化方向等 |
| 2 | V2版产品优化迭代方案 | 基于调研结果,输出第二版运输计划功能优化方案,包括新增功能点、交互优化、流程优化等 |
| 3 | 种子客户名单 | 愿意继续使用/试用优化后运输计划功能的货主客户清单,作为第三步种子用户 |
第二步与第一步的关系:第二步的调研方案设计需基于第一步梳理出的产品现状和已知问题,确保调研内容覆盖已知痛点。调研结果为V2版优化方案提供真实需求输入,避免闭门造车。
第三步是在第一步和第二步的基础上,持续迭代运输计划功能,逐步扩大使用范围和提升产品共性能力:
基于行业调研和现有痛点分析,第三步的共性能力提升方向可参考:
| 序号 | 方向 | 说明 |
|---|---|---|
| 1 | 强化计划编排能力 | 支持基于历史数据的需求预测、多维度运力匹配、多方案对比优化,从"手动下单"升级为"智能排程" |
| 2 | 提升全程可视化 | 装货→在途→卸货全节点实时可视,异常事件自动预警,预计到达时间智能预测 |
| 3 | 差异化服务不同规模货主 | 大型企业提供API对接能力,中型企业提供轻量TMS功能,小型企业提供极简一键发运体验 |
| 4 | 数据驱动优化 | 沉淀运输全流程数据,提供准点率、运力利用率等KPI分析,基于数据洞察帮助货主优化运输计划 |
| 5 | 强化异常处理 | 建立系统化异常处理流程(天气预警→自动调整→通知相关方→跟踪结果),减少人工干预延迟 |
说明:以上共性能力提升方向仅为参考,具体方向需根据第二步调研结果确定,避免脱离实际需求闭门造车。
第一步:梳理产品功能、清除bug、初步提升体验
梳理运输计划现有产品功能清单和13条业务规则
确认已知bug(B01-B04)并补充测试中发现的bug
梳理创建/修改运输计划的产品流程
编写V1版产品优化迭代PRD(含校验规则优化、交互提示优化、页面布局优化、字段说明、规则提示等)
与研发、大数据的测试团队进行方案评审
确认跨业务线协同范围(中台、CRM修改入口适配)
研发团队实施V1版优化(P0:校验规则优化与司机端适配 + P1:交互提示、页面布局、字段说明、规则提示)
测试团队验证优化点,确认bug修复效果
确认中台、CRM侧修改入口同步适配
V1版优化上线发布
收集货主使用反馈(预留2周时间确保业务人员充分收集反馈),为第二步调研提供参考
第二步:市场调研,输出V2版产品优化迭代方案
与客户成功部门协作,筛选代表性客户
制定调研问卷/访谈提纲
确认调研方式(电话访谈/现场走访)
协调调研时间安排
正在使用运输计划的客户访谈(中小型1-2个 + 中大型1-2个)
原来使用、现在不用的客户访谈(中小型1-2个 + 中大型1-2个)
内部数据分析(使用数据、活跃度、流失数据)
编写客户调研报告,汇总各类型客户调研结果
基于调研结果设计V2版产品优化迭代方案
筛选种子客户名单
V2版优化方案与研发、测试团队评审
确认V2版优化优先级和研发排期
启动V2版研发
第三步的时间计划视第一步和第二步的执行情况而定,暂不固定具体时间。原则如下:
| 原则 | 说明 |
|---|---|
| V2版上线后启动 | 第三步在V2版优化上线发布后正式启动 |
| 按月度/季度迭代 | 按月/季度进行一次客户回访和功能迭代,持续收集反馈并优化 |
| 种子用户逐步扩大 | 每个迭代周期逐步扩大种子用户范围,从2-4个扩展到更多货主 |
| 共性能力逐步沉淀 | 从个性化需求中提炼共性能力,每个版本沉淀1-2个共性功能点 |
除货主端外,成丰货运中台、成丰助手(内部CRM)也有修改运输计划的入口。本次优化涉及的校验规则变更(优化1、优化2),需要其他业务线产品配合,确保中台和CRM侧的修改入口同步适配新的校验逻辑,各入口行为保持一致。
| 序号 | 业务线 | 涉及入口 | 协同要求 |
|---|---|---|---|
| 1 | 货主端 | 创建运输计划 + 修改运输计划 | 本次优化主要实施端,优先适配 |
| 2 | 成丰货运中台 | 修改运输计划入口 | 需同步适配优化2(剩余可抢单=0允许保存)的校验逻辑 |
| 3 | 成丰助手(内部CRM) | 修改运输计划入口 | 需同步适配优化2(剩余可抢单=0允许保存)的校验逻辑 |