A print shop goes digital, part 2: choosing the next operating slice

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 pressure to build “the next thing”

A few weeks after launch, the enquiry form was doing its job: enquiries arrived with product type, quantity, deadline and an optional artwork attachment already connected, cutting the opening back-and-forth of every conversation.

And immediately, the question appeared — from a supplier, from a friend who runs a bigger shop, from the owner’s own late-night browsing: “Shouldn’t you add online ordering now?”

Here is what that question quietly got wrong: it assumed the shop was discovering its needs one at a time. It wasn’t. The owner could name the whole picture on day one — order handling, production statuses, delivery tracking, an internal backend. The full need existed from the start. The real question was never whether, but in what order — and the order system’s turn was not first.

What the shop reused instead

The unglamorous truth is that the shop already had an order-handling process, made of ordinary tools:

• LINE stayed the negotiation channel — quotes, file corrections, “can you make the red darker” — where customers already were.
• Submeto and email formed the file-delivery path. Customers attached artwork to the enquiry form; Submeto delivered it to the configured email channel with the structured job details.
• The paper job book stayed the source of truth: one line per confirmed job — customer, product, quantity, due date, deposit or not.

None of this was new. What was new was that the website fed these tools cleaner inputs — structured enquiries instead of “hi how much for stickers”.

What an order system would have cost — in attention

The real cost of an order system is rarely the build. It is what the shop would have had to spend attention on while running a business:

• Encoding rules before they had surfaced. The shop knew its trade — but the rules as a system needs them, exceptions included, only surface through real operation. Print work is full of “almost standard” jobs; a system either rejects them or grows special cases nobody maintains.
• Adapting people and software at once. The owner and the part-time assistant would have been learning a new tool while discovering its assumptions were wrong — the worst combination. When staff route around a system built like that, the system is at fault, not the staff.
• Skipping the shared-understanding phase. The shop and its developer did not yet share a vocabulary for how a job really flows. That understanding forms through practice, and the smaller phases were where it formed.

An order system built at this point would have been a guess, frozen into software.

What this phase deliberately was not

To be explicit, this phase had:

• No order system, no shopping cart, no checkout — deferred, not dismissed. The need was real from day one; its turn had not come.
• No customer login. There was nothing for a customer to log in to yet.
• No automation between the form delivery, LINE and the paper record. The owner copied confirmed details by hand and owned the accuracy of the job book. That manual handoff made its errors and exceptions visible enough to shape the next build.

The evidence that would justify phase three

The shop wrote down what to watch:

• Hand-copying details into the job book producing real errors or lost enquiries, not just mild annoyance;
• Uploaded files repeatedly mismatched to confirmed jobs after the email handoff;
• More than one person needing the same job information at once — the moment a paper book stops scaling.

For this scenario, assume all three signals then become visible in normal operation. Part 3 covers the response: not the whole end-state system, but a small admin backend shaped by the enquiries and staff handoffs themselves.

---

The boundary matters: the enquiry form and website from part 1 are a normal website project. Order systems, admin backends and the production or logistics tools discussed in this series are separate system projects with their own scope — they are not included in a standard website package.