配送员软件

配送员软件 — 执行人的作业工具：它把当班任务送到配送员手上，显示地址和订单内容，带着他从一个站点走到下一个，并记录每个站点上发生了什么。从公司这一侧看，这就是 配送管理：调度员不必挨个打电话，就能看到谁在哪里、什么已经完成。

一个例子就能看出区别。没有程序时，配送员在聊天里拿到地址，打电话给客户问哪个单元门，晚上再向调度员口述今天送了什么。调度员把这些抄进表格——前提是他记得，而且配送员没记乱。到了一天结束，谁也说不出某个订单确切的交付时间。

在程序里，这一切都是记录。一单配送有一张卡片，卡片上有地址、内容、时间窗和当前状态，每一次变更都有时间和操作者。回答「订单在哪、它身上发生过什么」只要几秒钟，而且不取决于配送员接不接电话。

举个例子。 早上订单在仓库拣好并派给了配送员——任务连同地址和配送时间窗一起出现在他的应用里。配送员取了货、标记了领取、按站点跑起来，每到一站就改一次状态。第三个地址上客户不在家——配送员填了原因，这一单没有「消失」，而是进入调度员的排查队列。傍晚业务员按系统里的记录答复客户，而不是按配送员的记忆。

配送自动化 的起点，是当三个问题的答案再也装不进调度员的脑子时：这个订单派给了谁、它此刻处于什么状态，以及有什么能证明它已经交付。

配送单生成之后，订单会 指派给某位具体的配送员。指派不是群里的一条消息，而是一项操作：这单配送有了执行人，执行人也有了一项带编号、下发时间和当前状态的任务。

任务立刻进到配送员的应用里，不用打电话，也不用转发地址。配送员打开清单，看到的是完整的一个班次：派了多少站点、哪些已经关闭、下一单是哪个。

谁来指派。 通常是调度员——手工指派，或者按公司设定的规则：按城市片区、按订单类型、按配送员空闲时间。自动分配 可以实现 ，按某家具体服务商的流程来做；我们不会事先把它当成现成功能来宣称——每家的分配规则都不一样，也不能替公司去凭空设想。

配送员对一项任务能做什么：

• 接受 — 确认任务已收到，并由他接手处理
• 打开卡片 — 查看内容、地址、时间窗、备注和付款方式
• 改变状态 — 标记取货、出发、抵达站点和交付
• 留下备注 — 记下下次用得上的信息，或者能解释延误的原因
• 标记问题 — 记录这单配送没能完成的原因
• 给调度员发消息 — 不用离开任务界面，就能就某一单配送提问

任务里不该有的，是多余的东西。配送员不需要订单成本、客户历史和公司报表：屏幕上留下的是把货送到并交出去所需要的内容。其余的用访问权限挡住，而不是用小字。

配送站点 — 一个地址加一单配送。配送员的一个班次由这些站点构成，应用同时用两种方式展示它们：按行车顺序排列的清单，以及地图上的标记。清单回答的是「接下来做什么」，地图回答的是「离这儿有多远」。

先后顺序 事先排定并对配送员可见：哪一站是当前的、哪些已关闭、哪些在后面。关闭一站之后，下一站自动成为当前站——配送员不用在清单里找，也不用每次重新决定去哪。

顺序在当天可以调整。 调度员挪动站点、插入急单或撤下已取消的——变更会推送给配送员，路线历史里也留下改了什么、什么时候改的。系统绝不该悄无声息地把计划换成另一份：一个事后才知道变更的配送员，只能把一天重新排一遍。

自动生成最优行车顺序 — 是一种能力，它 可以自行实现，也可以通过对接接入 某个地图服务。我们不会把它当成现成功能来宣称：这种优化的质量取决于交通数据，也取决于某家具体服务商的约束——收货方的时间窗、片区、包或车的容量。

实践中，很多服务商用手工排序就够了：调度员比算法更懂这座城市，而收货方的时间窗本来就把一天框得很死。

仓库和配送不是两个共用一个群聊的部门，而是同一个流程的两段。「已拣配但未交接」的订单和「已交接但未标记」的订单，是两种不同的状态，混起来代价很高：前者要去仓库找，后者要去配送员那里找。

这个接缝很简单： 仓库员工标记交出，配送员标记接收。在两个标记都打上之前，订单挂在一个中间状态里，双方都能看到。这样一来，丢失的货件总能定位到它是在哪一段丢的，排查也就不会变成挨个问当班的人。

完整的仓储核算——收货、库位存储、库存、拣配和盘点——是另一个页面的主题， 「仓储解决方案」。这里只讲接缝：仓库交给配送员什么，又从他那里拿回什么。

如果仓库跑在另一个程序里 — 这是常见情况：仓储核算已经在既有系统里做了，没有人打算换掉它。这时接缝以数据交换的方式搭建：配送员软件取到订单是否备好和货件构成，回传状态、确认和退货。

交换的内容取决于外部系统能对外提供什么，并在调研时确认。事先宣称已有现成的对接，就等于替别人的产品做承诺。

同一条原则在反方向上同样成立——在退货上。没有交回的标记，未送达的订单就一直躺在配送员的后备箱里直到下个班次，并且恰恰在没人对它负责的那一刻从账上消失。