A print shop goes digital, part 4: turning production experience into a workflow

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 status list that looked right and worked wrong

The admin tool from part 3 launched with a status list that any software person would recognize: New → In Progress → Done. It was tidy, generic — and within weeks, nearly useless.

“In Progress” was the problem. A job waiting for the customer to approve a proof, a job queued behind the big banner order, and a job physically on the press were all “In Progress”. The list recorded that work existed; it said nothing about what was blocking it or whose move was next — which was the only thing anyone in the shop actually wanted to know.

So the assistant started skipping status updates. The easy reading is “staff resistance”; the correct reading is diagnosis. People stop feeding a system when it gives nothing back, and a status field that answers no one’s real question gives nothing back. The tool had demoed well — a working screen is not the same thing as a tool adopted in daily work.

Rebuilding the list from the shop floor

The fix did not come from studying other software. It came from the owner and the assistant standing in the workshop and naming the states a job actually passes through, including the uncomfortable ones:

• Waiting on artwork — the customer hasn’t sent usable files yet. The shop’s move: chase.
• Proof sent, awaiting approval — the shop is blocked on the customer. Different chase, different urgency.
• Ready to print — approved and queued. The only state where the press schedule matters.
• Printing / finishing — physically in production. Rarely needs attention; mostly just true.
• Ready for pickup or delivery — done, but not yet gone. Jobs used to silently rot here.
• Closed — collected or shipped, and paid.

Two things distinguish this list from the generic one. First, most states encode who is blocked on whom — the question that drives the shop’s day. Second, states like “ready for pickup” exist because jobs really did get stuck there, something no template workflow would have predicted.

Internal statuses are not customer statuses

The second insight of this phase: the shop’s internal list should not be exposed to customers unchanged.

“Waiting on artwork” is, internally, a mild accusation. “Queued behind the banner order” is honest but invites negotiation. Customers needed a shorter, calmer vocabulary — received, in production, ready — mapped from the internal states without exposing the shop’s scheduling and chasing machinery. For now, the customer view existed only as a discipline: staff answering “is it done yet?” used the customer vocabulary consistently, whatever the internal state said.

What this phase deliberately was not

• No customer-facing status page yet. The mapping existed; the page did not. Building it before the internal workflow stabilized would have meant publishing a moving target.
• No automation of status changes. Every transition was a human clicking, on purpose — wrong automatic statuses destroy trust in a tool faster than no tool at all.
• No scheduling or capacity planning. “Ready to print” made the queue visible; deciding the queue order stayed a human judgment.

The evidence that would justify phase five

The next candidate was delivery. The shop agreed to watch for:

• Delivery-related questions (“has it shipped? what’s the tracking number?”) becoming a measurable share of all customer messages;
• Tracking numbers getting lost between the courier slip, LINE and the job record;
• The “ready for pickup or delivery” state accumulating jobs whose delivery outcome nobody could confirm.

Part 5 covers what the shop did about logistics — and why the first step was, once again, deliberately manual.

---

The boundary matters: the website and enquiry form from part 1 are a normal website project. The admin backend, workflow tooling and the logistics topics in this series are separate system projects with their own scope — they are not included in a standard website package.