A print shop goes digital, part 5: when to connect delivery and logistics

This series follows one print shop through several phases of going digital. The journey is built from real implementation experience in this industry — the stages and challenges should feel familiar if you run this kind of business. Each part covers what was built, what was deliberately not built, and what evidence justified moving to the next phase.

The delivery problem, precisely stated

By this point, the evidence from part 4 had arrived: delivery questions were a steady share of customer messages, and tracking numbers lived on paper courier slips that got photographed into LINE, forwarded, and lost. Twice, the shop could not tell an anxious customer whether a finished job had actually shipped.

The tempting response was the impressive one: integrate with the couriers’ systems, generate labels from the admin tool, show live tracking to customers. Every vendor pitch for such systems shows exactly that screen.

The shop instead asked a narrower question: what is the smallest change that makes shipped jobs traceable?

What the shop built: a field and a habit

The answer was almost embarrassingly small. The admin tool from part 3 gained three things on each job:

1. A delivery method — pickup, courier, or the shop’s own van run for nearby customers.
2. A tracking-number field — typed in by hand from the courier slip, at the moment the parcel left.
3. A shipped date — filled in at the same moment.

Plus one habit: whoever hands a parcel to the courier records the number before doing anything else. The habit mattered more than the fields; the fields only made the habit checkable.

The customer experience improved immediately, without any customer-facing feature. “Has it shipped?” became a ten-second lookup and a copy-pasted tracking number in LINE, instead of an archaeology dig through slips and chat photos.

Why manual first, even here

Manual tracking-number entry sounds like the thing systems exist to eliminate. But doing it by hand first bought the shop knowledge it could not otherwise get:

• Which couriers actually got used, in what proportions — an integration supports specific carriers, and guessing the list wrong means building it twice.
• Where the process really failed — the shop learned that lost tracking numbers were a handoff problem (courier arrives during a rush), not a typing problem. An API would not have fixed the actual failure.
• The volume and error cost. In this scenario, a handful of ordinary shipments could still be handled safely by a recorded habit. A lower-volume operation with regulated, high-value or time-critical delivery might reach a different decision.

What this phase deliberately was not

• No carrier API integration, no label printing, no live tracking.
• No customer-facing shipment page. Tracking numbers went out through LINE, in the conversation customers already trusted.
• No changes for pickup customers — most jobs never shipped at all, a fact the new delivery-method field made visible for the first time.

The evidence that would justify real logistics integration

The shop defined the thresholds honestly, knowing it might never cross them:

• Manual entry producing unacceptable error, delay or compliance risk, whether because of volume or the value of each shipment;
• One or two carriers clearly dominating the records, so an integration has a narrow, stable target;
• Customers asking for tracking links often enough that pushing them proactively would meaningfully cut inbound messages;
• The shipped-date records showing delivery disputes (“it never arrived”) that live carrier status would actually resolve.

At the close of this phase, none of these thresholds had been crossed — and that, too, was a result. Part 6 steps back and looks at the whole journey: what the evidence-first approach got right, and where the shop misjudged.

---

The boundary matters: the website and enquiry form from part 1 are a normal website project. The admin backend, workflow tooling and the delivery record-keeping in this part — and any future carrier integration — are separate system projects with their own scope, not included in a standard website package.