操作问题
运输团队会通过重复的电话和电子邮件获取预计到达时间、POD 和发票副本。客户缺乏一个地方来查看活跃负载、历史发货和未决请求。
当从 TMS 导出手动重建门户数据时，客户会看到过时的状态，并且内部团队对自助服务失去了信任。
该蓝图的目标是一个从 TMS 和文档存储读取操作事实的门户，而不是复制电子表格。
- 大量状态查询需要调度和 CS
- 文档分散在电子邮件、SharePoint 和 TMS 附件中
- 没有针对取件变更或配件请求的结构化接收
- 不同客户群的品牌不一致
用户和角色
托运人用户需要对其账户、通道和服务水平进行过滤的可见性，而不是运营商的整个网络。
客户服务和调度需要内部视图，包括异常队列、批准路径以及对客户更改内容的审核。
财务部门可能需要对与已关闭的货件关联的发票包进行只读访问。
- 发件人管理员 — 帐户设置、用户邀请
- 托运人运营商 — 跟踪、文件、请求
- 客户服务——例外情况、消息传递、批准
- 调度 — 与 TMS 负载相关的请求履行
核心工作流程
客户使用来自 TMS 或集成源的里程碑时间表搜索并深入了解活跃和已完成的发货。
文档工作流程涵盖 POD 检索、海关包和运输说明上传 - 以及病毒扫描和保留规则。
服务请求捕获取件更改、滞留标志或报价请求，并使用 SLA 计时器路由到正确的队列。
- 跟踪发货→查看里程碑→下载文件
- 提交服务请求 → 内部批准 → TMS 更新
- 通知客户控制规则的异常或延迟
- 旅行完成后，与 POD 和发票包形成闭环
产品模块
企业托运人可选择使用 SSO 进行帐户和用户管理。
发货工作区结合了地图提示、里程碑表和相关文档。
请求收件箱提供 CS 模板和 TMS 批准后回写。
有关关键事件的电子邮件和门户内警报的通知首选项。
系统和集成
TMS 仍然是货运记录系统。门户通过 API 或受控文件投放来消耗负载、停止、状态和费用。
文档存储可保存 POD 图像、BOL 以及带有签名 URL 的自定义 PDF。 ERP 可能会在发货结束时收到发票触发信息。
电子邮件摄取可以补充没有 API 的合作伙伴；验证队列可防止未经身份验证的上传进入客户视图。
- TMS — 负载、里程碑、商业状态
- 文件存储 — POD、BOL、海关
- ERP / 计费 — 发票触发器、账户主数据
- 身份 — 托运人企业的 SSO、MFA
- 通知 - 电子邮件、CS 工具的网络钩子
数据模型注意事项
将面向客户的货件视图与内部 TMS 标识符分开——映射客户识别的外部参考。
里程碑事件应该与源系统时间戳具有幂等性，以解决争议。
请求对象需要状态、所有者、SLA 以及与一批或多批货件的链接，而不会在负载拆分时孤立。
实施路线图
第 1 阶段：试点账户部分的只读跟踪和文档。
第 2 阶段：获得 CS 批准和选择性 TMS 回写的服务请求。
第 3 阶段：通知、SSO 和扩展帐户层次结构。
第 4 阶段：对门户采用率和偏离联系量进行分析——诚实地衡量，而不是作为客户结果进行营销。
- 试点通道或账户组
- 与电子邮件状态进程并行运行
- 定义 TMS 字段门户可能会更新
- 在营销门户广泛之前在异常队列上训练 CS