配送点完成后的收件决策
用于明确决策的配送验收表单
将“司机已完成配送点作业”与“收件人已验收货物”分开，保留检查数量、货物状况、备注和下一步行动，并关联到货件。
当验收是一项实际业务决策时使用此表单；简单的门到门配送可能只需轻量签收凭证。
最多 5 名用户可免费使用，无需信用卡。
无需编程即可调整字段、工作流和仪表板。 探索 1,000 多个应用模板和业务场景
两种结果
不要让配送完成状态覆盖验收结果
这些记录回答了不同的问题。
配送凭证答复
- 司机到达目的地了吗？
- 采集了哪些凭证？
- 司机报告的数量是多少？
- 何时何地记录完成情况？
验收答案
- 收件人检查了什么？
- 接受什么数量和条件？
- 是否有短缺、损坏或拒收？
- 接下来会发生什么退货、换货或索赔？
决策模型
给部分接受一条真正的道路
只有“验收/拒收”两个选项，会迫使团队掩盖混合结果。
| 成果 | 记录 | 下一步 |
|---|---|---|
| 已接受 | 接受数量和收件人确认 | 凭证完成后闭环 |
| 部分接受 | 有理由接受和有争议的数量 | 公开短缺/损坏解决方案 |
| 有条件接受 | 条件、预订和所需采取的行动 | 跟踪纠正措施以进行验证 |
| 拒收 | 原因、凭证和保管责任状态 | 创建回程取货或保留指令 |
后续行动
将接受与必须响应的团队联系起来
签名采集完成，并不代表表单处理已经结束。
客户服务
查看收件人评论、承诺风险和通信负责人。
物流
请参阅所需的退货取件、重新投递或承运商证据。
质量或供应商团队
查看相关的状况证据、批次/项目背景和处置。
验收设计
为每个决定提供足够的证据和可见的后果
收件人应清楚自己正在验收什么；内部团队也应立即看到该决定会如何影响配送、退货和客户处理。应明确谁可以记录决定、何时需要办公室审核，以及结果写入哪条下游记录，避免签名成为与运营脱节的孤立图片。
注明检查范围
显示货件、物品或包裹编号、预期数量，以及要求收件人确认的货物状况标准。不要在未说明具体确认内容的情况下只要求一个笼统签名。
支持混合结果
分别记录已接受、有争议和拒绝的数量。部分验收应保留成功交付的证据，同时针对未解决的部分提出短缺、损坏、更换或退货行动。
解释下一步
告知收件人和运营团队结果是否闭环投递、等待审核、创建回件取件或需要采取纠正措施。避免显示任何关于后续行动的确认屏幕。
验证条件闭环
当验收取决于更换、文件或维修时，请向负责人和截止日期保留条件。仅在审核了商定的行动和证据后才将其闭环。
上线决策
将收据与索赔或更换决定分开保存
收件人可能会接受某些货物，但对数量、状况或文件有争议。分别保存已接受、有争议和拒绝的金额，然后将未解决的部分连接到退货、更换、索赔或纠正工作。验收记录应显示哪些立即闭环，哪些仍需要验证的后续行动。
上线前需回答的问题
配送验收表 常见问题
为什么要将配送验收与配送凭证分开？
交付凭证记录配送事件及现场证明，验收记录则保留收件人的检查结果和决定。两者可以同时完成，但分开记录能避免已完成的配送点掩盖短少、损坏或拒收。
表单可以记录部分验收吗？
是的。分别保留已交付、已接受和有争议的数量，并要求说明差异的原因和下一步行动。
谁应该批准被拒绝的配送？
这取决于过程。物流可能拥有退货动作、客户服务承诺以及质量或采购处置。配置显式负责人和审核步骤。
何时不需要单独的验收表单？
对于低风险交付（所需证据本身即构成接受），请使用较短的 POD 流程并避免重复的数据输入。
有条件接受后会发生什么？
创建具体的纠正措施、负责人和到期日期，同时保留已接受和有争议的数量。仅在收件人或授权审阅者验证商定的响应后才闭环条件。
查看实际运行的产品
打开本页面对应的示例 App
查看关联记录、运营视图、真实异常审核工作流，以及具有代表性的正常、有风险、失败和已完成配送状态。