订单类型多样
空运、海运、铁路至少构成一类核心业务，前段还会衔接拖车、散货车和内贸铁。不同方式拥有不同字段、流程与资料。
时空数距
把复杂货代协同，转化为可追踪的业务系统。
从业务驻点、一线访谈和流程建模开始，围绕供应商、客户与平台三方，推进出口门到站 MVP、询盘匹配、订单协同与复杂资料流转落地。
先进入业务现场，再决定系统应该承接哪些复杂度。
1 个月业务部门驻点与流程观察
7 家合作企业与相关公司
200+供应商、客户与业务人员
300+访谈、观察与需求信息
01项目背景
订单发运不是终点，资料、责任和异常能否被确认，才决定履约是否继续。
货代公司并不是单一运输服务商。一笔订单可能同时包含班列、报关、集装箱、拖车、多个供应商和不断变化的资料截止时间。传统流程依赖电话、表格和即时通讯反复确认，信息冗杂、标准不足、状态不透明。
产品没有把平台做成客户与供应商直接交易的撮合市场。货代公司仍然位于链路中心，负责审核、分配、资料中转与异常协调。系统需要放大这种协调能力，而不是绕开它。
因此，产品工作从角色职责、状态流转、资料归属和权限边界开始，再决定页面如何呈现。界面只是业务模型的一个出口。
02进入业务现场
复杂度来自运输方式、角色权限、资料状态和时间约束的叠加。
驻点前半个月先理解真实作业。四个结构性问题决定平台不能套用普通订单系统。
平台强中心化
订单信息先经货代公司确认，再流转给客户或供应商。平台还要阻止信息泄露和双方绕开平台交易。
资料时限动态变化
班列机构可能临时调整资料截止时间。资料必须被及时审核、转发、补齐和确认。
单笔订单多式联运
国际班列订单还会携带报关、集装箱与拖车信息，复杂订单需要同时协调多类供应商。
03需求挖掘与收敛
300+ 条信息没有被做成需求清单，而是被收敛成产品入口、状态和规则。
研究问题
用户说出来的是愿望，现场暴露的是使用条件。
现场语境
后半个月进入供应商和客户现场，在不打扰工作的情况下观察用户如何在办公室、业务现场与手机之间切换。除了订单和资料需求，还关注设备、年龄、软件习惯、异常沟通和协作节奏。
研究路径
主动访谈订单、资料、费用与异常
现场观察设备、地点与操作习惯
流程还原角色、动作、状态与分支
范围收敛首期必须跑通的主链路
研究输出
从现场条件，到可以执行的产品规则。
下面的界面不是并列展示的五个图例，而是同一条推导链：先接住一线异常，再保证信息准确进入平台，最后让平台用可解释的方式完成筛选与决策。
01一线操作现场如何接住任务
移动工作台消息、状态与下一动作
订单动态3 条待处理
OF-21
拖车路线发生变化
进入保税区绕行，请确认额外费用与到场时间。
DOC
报关资料需要补充
缺少检验报告，资料截止时间今天 16:00。
RAIL
班列计划已更新
发运日期调整，请重新确认客户交付计划。
PAY
订单费用待核验
客户已提交支付凭证，等待平台确认。
观察手机是一线主要办公工具，异常消息必须带着订单上下文到达。
发布货盘表单准确优先于极限密度
货盘类型
国际班列运输
发运日期
2022-09-18
运输线路
成都国际铁路港 至 莫斯科别雷拉斯特
舱位数量
12
报价
平台审核后可见
规则标签置于输入框上方，复杂表单先保证阅读与填写准确。
02平台判断信息如何被筛选
货盘快速筛选高频动作一次完成
货盘类型
国际班列
海运
空运
拖车
散货
内贸铁
成都至莫斯科 | 9 月 18 日
12已审核货盘，舱位 12，支持门到站
规则货盘类型前置并平铺，保留完整筛选，同时缩短高频路径。
询盘决策不展示完整价格排名
TIME最快速
优先近期发运与到达时间。
RISK最安全
优先路线稳定与合作记录。
COST最划算
平衡报价、杂费与服务条件。
取舍兼顾客户决策效率、供应商机会和平台调度价值。
03 · 归纳结论把局部观察收束成跨页面规则
核心消息、订单状态和资料任务必须适合现场处理。
易懂和准确优先于高密度后台组件，减少培训依赖。
拖车绕行、偏载掏箱与资料变更必须绑定订单节点触达。
04MVP 范围取舍
第一版用“出口 - 门到站”验证完整协作，而不是一次覆盖所有运输类型。
这条链路同时暴露货盘、审核、询盘、支付、派单、接单和资料流转问题，足以验证三端模型能否成立。
业务节点供应商端平台端客户端
01 发布
发布货盘路线、报价、舱位与发运信息
02 审核
审核货盘确认完整性与有效状态
03 询盘
发起询盘选择时间、安全与成本偏好
04 匹配
参与竞单确认可承接范围
匹配供应商结合报价与合作情况分配
无符合条件供应商：关闭或重新匹配
05 支付
核验支付确认凭证与订单费用
未支付：联系客户并提醒
支付订单费用提交支付结果
06 生成
生成订单关联匹配、供应商、费用和资料
07 派单
平台派单确认最终履约供应商
08 接单
确认接单进入履约与资料任务
09 协同
回传履约节点、异常和资料
维护业务状态审核、转发和异常协调
查看与确认进度、资料和下一动作
05角色与权限边界
同一笔订单共享业务事实，不同角色只看到自己应该处理的内容。
供应商端
发布货盘、参与匹配、确认接单，并持续回传运输节点与资料。
- 主要输入
- 路线、时效、报价、舱位
- 主要动作
- 发布、竞单、接单、回传
- 权限边界
- 不获取客户完整身份与联系方式
平台端
维护供应商与客户之间的业务秩序，承担审核、调度、中转与异常协调。
- 主要输入
- 全局货盘、询盘、支付和资料状态
- 主要动作
- 审核、匹配、派单、转发
- 权限边界
- 能看全局，但每次操作必须留下状态和去向
客户端
发起询盘、确认决策方向、支付订单，并查看自己的进度与资料。
- 主要输入
- 发运时间、服务偏好、订单资料
- 主要动作
- 询盘、选择、支付、补充
- 权限边界
- 不需要理解平台内部调度和供应商完整信息
06询盘匹配规则
不做最低价货盘列表，用三种决策方向平衡客户、供应商和平台。
如果把所有货盘按价格平铺，用户只会选择前几条，供应商机会持续向头部集中。
系统负责缩小可行范围和解释决策方向，平台仍结合舱位、合作记录、资料质量和业务风险完成最终匹配。
- 没有选择纯列表
- 避免头部货盘长期占据订单。
- 没有完全自动下单
- 保留真实业务经验与异常判断。
- 没有把最划算等同最低价
- 把杂费、时效与后续风险一起纳入。
客户询盘结果国际班列 | 成都至莫斯科
优先匹配近期可发运、路线稳定的货盘。
平台结合舱位、供应商履约情况和当前订单要求确认分配。
客户看到预计发运与到达范围
平台判断舱位、路线、履约记录
供应商影响满足时效者进入候选
07资料协同规则
资料区不是附件仓库，而是一套隔离信息、传递责任并完成双向审核的状态系统。
客户上传资料先进入平台待办
平台审核与转发检查基础信息和泄露风险
供应商业务审核真正接收方判断是否可用
平台回传结果客户收到通过或补充要求
平台检查基础正确性和信息泄露风险。
平台不替真正接收方判断专业资料是否可用，而是控制资料在正确角色之间流动。
平台转发的作用转发时可以补传同类型资料、指定接收方和真正审核角色，因此同一套资料区既能承接小型订单，也能兼容国际班列和后续多式联运。
08对象抽象与扩展
把页面需求继续向下抽象，沉淀为四类可复用业务对象。
新增运输类型时，不必从零搭建页面，而是组合已有对象、字段、状态和权限规则。
订单
三端协作的主上下文。
- 业务类型与订单号
- 客户、供应商与平台关系
- 费用、支付与异常
运输环节
可组合的履约节点。
- 班列、报关、拖车、集装箱
- 计划时间与实际时间
- 责任供应商与异常
资料
归属于订单和运输环节。
- 资料类型、版本与截止时间
- 上传方、接收方与审核人
- 预览、下载、补传与转发
审核状态
描述当前责任与可见范围。
- 待审核、已通过、未通过
- 待上传、待转发、已回传
- 角色权限与操作记录
09实际交付与落地
最终交付是一条能从货盘发布走到资料协同的订单链路。
3协作角色供应商、客户、平台
1MVP 主链路出口门到站
9连续业务节点发布货盘到订单协同
4核心业务对象订单、环节、资料、状态
OF20221547896
福建利越达外贸 | 国际班列运输 | 出口门到站
路线报价
运输节点
资料审核
供应商已提交路线报价，等待平台确认。
平台审核后再向客户展示有效方案。客户与供应商不直接看到对方完整信息。
当前角色平台端
业务对象路线报价
下一动作审核并进入询盘库
可见范围平台全量，客户暂不可见
异常分支信息不全则退回供应商
协作结果形成可用货盘
从电话、表格和即时通讯，走向可追踪、可审核、可扩展的货代协同。
时空数距把货代公司的中心协调能力，转成角色明确、状态可追、资料可控、异常可接管的平台能力。