为需要采取行动的人设计货件时间线
面向异常处理的货件追踪软件
用带时间戳的事件、当前承诺、关联凭证和明确下一项决策负责人的异常记录，取代单一可变状态字段。
实时 GPS、承运商网络和预测 ETA 数据需要专业服务或集成；该 App 用于保持运营记录与异常响应灵活可配。
事件模型
将事实、预测与决策分开
将事实、预测和决策混在一起，会让“追踪”页面看似最新，实际运营却未必如此。用户无需解读集成数据流，就应能判断实际发生了什么、系统预计什么、当前适用哪项承诺，以及下一步由谁处理。
事实
带时间戳的事件说明发生了什么、发生在哪里以及产生了什么结果。
预言
ETA 说明当前的预期以及计算或收到的时间。
承诺事项
即使 ETA 变化，也应持续显示承诺的配送时段。
决策
异常记录分配遏制、沟通和恢复工作。
时间轴
使用事件历史记录来回答状态背后的问题
每行应该保持足够的不可变性以重建运动。
| 活动 | 应该保留什么 | 需要回答的问题 |
|---|---|---|
| 已分配 | 资源及调度时间 | 这次运输由谁负责？ |
| 离开的原点 | 时间、发货地和装载信息 | 执行开始了吗？ |
| ETA 已变更 | 先前/当前的期望和来源 | 哪些承诺面临风险？ |
| 尝试交付 | 时间、地点、结果和证据 | 为什么配送点失败？ |
| 已接受 | 收件人、凭证和数量说明 | 实际收到了什么？ |
| 已退回 | 退货原因和提货/收据参考 | 货物接下来去了哪里？ |
集成设计
确保每次承运商更新都可恢复
只有连接器名称，不等于有完整追踪方案。
启动前定义
- 稳定的货件和事件标识符
- 源时间戳和接收时间戳
- 重复且无序的事件行为
- 重试队列、负责人和调节报告
保持对用户可见
- 最后确认的事件及其来源
- 目前的承诺和风险
- 打开异常和操作负责人
- 运输任务结案时的交付凭证或退货记录编号
追踪体验
面向客户与运营人员提供不同答案
两类用户需要基于同一事实，但不需要相同界面。客户看到的信息应清晰克制；内部记录则应呈现来源、不确定性和恢复工作。
客户观点
显示当前关键里程碑、预计时段和已批准的沟通内容，不暴露内部备注或无关系统事件。
操作视图
显示事件源、源时间、接收时间、当前承诺、置信度以及任何对账或异常负责人。
异常警报
当承诺或决定发生变化时引发注意，而不是每次不需要采取行动的例行扫描。
结案证据
将接受的凭证、交付的数量、接收结果或返回参考连接到最终的移动状态。
上线决策
将缺失数据视为操作状态
过期的承运商数据并不等于实际运输延迟。应显示最后确认事件、源事件时间、当前承诺及负责核对数据缺口的人员，并测试重复事件、乱序事件、重试和人工更正，确保集成最不可靠时，时间线仍然可用。
上线前需回答的问题
货件追踪软件 常见问题
货件追踪与配送管理有何区别？
货件追踪聚焦流转事件、ETA 和当前状态；配送管理还会协调请求、分配、配送点执行、凭证、异常与退货。
Jodoo 可以提供实时 GPS 追踪吗？
Jodoo 可以接收并显示外部服务的数据，但本示例不提供内置车联网。需要持续定位数据时，应接入专业追踪服务。
重复事件应该如何处理？
使用稳定的事件标识符，保留源和接收的时间戳，隔离重复的更新并显示仍需要人员协调的记录。
哪些事件最重要？
选择会改变客户承诺、运营负责人或决策的事件，例如已调度、已发出、已到达、ETA 已变更、已尝试、已拒收、已验收和已退回。
货件跟踪应如何处理过时或丢失的事件源？
持续显示最后确认事件及其来源，标记数据源已过期，明确负责补齐缺口的人员，并避免把旧 ETA 当作当前事实。运营记录应区分数据缺失与实际货运延迟。
查看实际运行的产品
打开本页面对应的示例 App
查看关联记录、运营视图、真实异常审核工作流，以及具有代表性的正常、有风险、失败和已完成配送状态。