分配前完成信息受理
Logistics dispatch request form for complete intake
让调度员收到可以直接评估的请求。地址、时段、装卸要求或订单信息缺失时，应退回受理环节，而不是日后演变为配送失败。
该请求与客户、货件和调度记录相关，因此无需重新输入重复的信息。
最多 5 名用户可免费使用，无需信用卡。
无需编程即可调整字段、工作流和仪表板。 探索 1,000 多个应用模板和业务场景
信息采集要求
只询问是什么改变了计划或执行
每个必填字段都应支持调度决策。
| 字段分组 | 作用 | 准备规则 |
|---|---|---|
| 客户及相关订单或请求 | 将请求与业务承诺联系起来 | 存在稳定的参考和活跃的客户 |
| 服务地点及窗口 | 定义工作可以在何时何地进行 | 地址和所需时间可用 |
| 服务类型和级别 | 设置送货、提货、转运或退货期望 | 支持所请求的服务 |
| 处理需求 | 表面预约、升降门、温度、签名、照片或扫描要求 | 在分配容量之前要求是明确的 |
| 指示 | 保留访问或执行详细信息 | 电子邮件中没有隐藏任何关键指示 |
请求生命周期
仅当请求完成时才将其移至调度
就绪状态是一种受控状态，而不是默认状态。
- 01
草稿
请求者可以添加或更正信息，而无需进入实时队列。
- 02
准备好规划
所需地点、时间、服务及处理信息齐全。
- 03
计划
该请求与货件或分配相关。
- 04
缺少处理细节
调度员返回确切缺失的需求。
- 05
暂停或取消
原因和下游影响仍然可见。
转换
提交后让下一步行动显而易见
高转化率的形式也设定了用户的期望。
下一步处理
告知申请人：调度人员会审核信息是否齐全并确认负责人。
不应该提交什么
将紧急响应和不受支持的服务类型排除在普通队列之外。
哪里可以追踪进展
计划开始后，将请求链接到货件和货件记录。
受理体验
帮助请求者第一时间提交可调度的工作
较短的形式并不一定是更好的形式。使用渐进式问题和明确的选择，以便调度员收到最少的完整信息，而无需要求请求者了解内部路由规则。
使用特定于服务的选择
让送货、提货、转运和退货选择仅显示其相关位置、时间和处理问题。避免使用充满大多数请求者会跳过或误解的字段的通用表单。
解释所需时间
将所需时间与承诺的服务窗口和紧急程度分开。当请求对于正常服务来说太晚时显示，以便用户可以选择批准的升级路径。
重用已知信息
关联客户、订单或原始请求，避免重复输入地址和编号。若本次运输使用了不同信息，仍应提供经授权的更正流程。
返回可操作的反馈
如果规划部门无法接受请求，请指出缺失的字段、不受支持的服务或容量问题以及负责人。请求者应该确切地知道在重新提交之前必须更改哪些内容。
上线决策
为请求者提供一条清晰的路径来完成调度准备工作
提交前解释服务类别、截止时间及处理详情。重用已知的客户和订单信息，仅显示所选服务所需的问题，并返回不完整的请求并进行精确更正。这减少了调度员的返工，而无需要求请求者了解内部容量或路由规则。
上线前需回答的问题
物流调度申请表 常见问题
派遣申请表包含哪些内容？
包括客户和相关订单或请求、服务类型、位置、所需时间、服务水平、处理需求、说明和请求者背景。
表单应立即分配司机吗？
通常不会。首先验证准备情况，然后让调度人员比较产能、能力、优先级和时间承诺。
缺失信息该如何处理？
返回请求并提供确切的缺失详细信息和负责人。不要将不明确的请求放入实时调度队列中。
该请求可以创建连接的货件工作吗？
是的。配置的流程可以将接受的请求链接到货件和分配记录，同时保留原始订单或请求参考。
紧急请求应如何处理？
使用明确的优先级和所需时间以及升级负责人。不要让“紧急”一词绕过强制性地点、服务和处理细节，或覆盖已经交付给客户的工作。
查看实际运行的产品
打开本页面对应的示例 App
查看关联记录、运营视图、真实异常审核工作流，以及具有代表性的正常、有风险、失败和已完成配送状态。