印刷厂数位化，第 5 章：什么时候才接快递系统

这一整条系列，跟着一家印刷厂一步步走进数位化。故事的情境来自我们在印刷行业的真实实施经验——你要是开这类店，每一章应该都会看到自家店里的影子。每章都会说明：盖了什么、刻意没盖什么，以及是靠哪些证据才敢接着往下走。

把送货问题讲清楚

到这为止，第 4 章的证据已经出现了：送货问题是顾客讯息中稳定的一部分，而追踪号躺在纸本快递单上，被拍进 LINE、转来转去、然后不见。有两次，工厂没办法告诉一位心急的顾客，一件做好的工作到底寄了没。

那个吸引人的回应，是看起来很厉害的做法：跟快递系统整合、从内部工具印出货标签、给顾客即时追踪。每一份这种系统的业务简报，都会展示那个画面。

API（应用程序接口） 就是两个系统之间讲好的接头暗号，让它们能互相传资料。接上快递的 API，代表系统之间会自动交换追踪资讯。

这家厂反而问了一个更窄的问题：让已寄出的工作变得可追踪，最小的改动是什么？

这家厂盖了什么：一个栏位和一个习惯

答案小得几乎有点尴尬。第 3 章的内部工具为每张订单加了三项：

1. 一种送货方式 —— 自取、快递、或工厂自己的车给邻近顾客送。
2. 一个追踪号栏位 —— 包裹交寄的那一刻，从快递单人工打进去。
3. 一个寄出日期 —— 在同一个时刻填入。

外加一个习惯：谁把包裹交给快递，谁就先记下号码再做别的事。习惯比栏位更重要；栏位只是让习惯可以被检查。

顾客体验立刻变好，而且没有任何面对顾客的功能。“寄出去了吗？“变成十秒内的查找、在 LINE 上贴一个复制好的追踪号，而不是在单据和聊天照片里考古。

为什么连这里都先走人工

人工输入追踪号，听起来正是系统要来消灭的事。但先用手做，帮工厂买到别的方式买不到的知识：

• 实际用了哪些快递、比例多少 —— 一份整合要支援特定快递，猜错清单等于做两次。
• 流程在哪里真正失败 —— 工厂学到，追踪号会不见是交接问题（快递在忙乱中到店），不是打字问题。API 并不会修好真正失败的那一环。
• 量和错误的成本。 在这个情境下，少数一般出货仍然可以用记下来的习惯安全处理。要是换成件数更少、受管制、高价值或赶时间的出货，可能会做出不同的决定。

这一阶段刻意不是这些

• 没有快递 API 整合、没有标签列印、没有即时追踪。
• 没有顾客看得到的出货页。 追踪号透过 LINE 送出，在顾客本来就信得过的对话里。
• 没有为自取顾客改变任何东西 —— 多数订单根本没寄货，这个事实第一次被新的送货方式栏位显现出来。

足以让真正物流整合成立的证据

这家厂老实设好门槛，也清楚自己可能永远跨不过去：

• 人工输入造成无法接受的错误、延误或合规风险，不管是量太大还是每件价值太高；
• 有一两家快递明显主导纪录，让整合有个窄而稳定的目标；
• 顾客索取追踪连结的频率，高到主动推送能明显减少进厂讯息的程度；
• 寄出日期纪录显示，有些送货纠纷（“它根本没到”）正是即时快递状态能真正解决的。

在这个阶段结束时，这些门槛一项都还没跨过——而那本身也是一种结果。第 6 章退一步，看整段旅程：证据优先的做法做对了什么，以及这家厂在哪里判断错了。

---

边界很重要：第 1 章的网站与询价表单是一个正常的网站专案。本部分的内部后台、工作流工具与送货纪录——以及未来任何快递整合——都是各有范围的独立系统专案，不属于标准网站套件。