A print shop goes digital, part 3: a simple admin backend built from real enquiries

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 moment the paper book broke

In this scenario, a repeat customer’s sticker job goes to print with the wrong artwork because the current attachment is not connected clearly to the confirmed line in the job book. Similar mismatches and a growing need for the assistant to see the same job information show that the agreed next-phase conditions have arrived.

What the enquiry data showed

Before designing anything, the shop reviews the accumulated form enquiries and handoff records. The data answers questions that would otherwise have been guesses:

• A few product families dominated. The long tail of unusual requests was real but thin; the tool could be simple because the work was more repetitive than it felt.
• File issues clustered at the start of a job, not throughout it — so “artwork confirmed” deserved to be an explicit checkpoint, not a vague hope.
• Deadlines were the field customers filled most carefully. Due dates, not prices, drove the shop’s daily stress — so the tool should be organized around dates.

None of these findings required the new backend to discover. They required a structured first operating phase and enough representative work to expose the rules and exceptions. The necessary observation period depends on the business; it is not a fixed number of months.

What the admin backend actually was

The tool the shop commissioned was deliberately minimal — one internal screen, four things per job:

1. The job record — customer, product, quantity, due date, created when an enquiry became a confirmed job.
2. The files — attached to the job itself, ending the era of files living in email threads.
3. An owner — one named person per job, so “I thought you were handling it” stopped being possible.
4. A status — a short list of stages, visible to everyone at a glance.

That was the whole first internal slice. Enquiries that never became jobs stayed in the Submeto-to-email path. Quoting stayed in LINE. The tool managed confirmed work, nothing upstream of it.

Just as deliberate was how it arrived. For the first month, the paper job book kept running in parallel — not from distrust, but because the new entry step had to become a reflex before the shop could depend on it. The assistant was named the owner of data quality: one person answerable for “is this record true?”. When records went stale in week two, the fix was shortening the entry form, not lecturing the assistant. Adoption is part of the build, and needing time for it is nobody’s failure.

What this phase deliberately was not

• No customer-facing anything. Customers noticed nothing; this phase was entirely internal.
• No order or payment features. Quotes and bank transfers worked as before.
• No production planning, no scheduling, no logistics. The status list existed, but it was a first draft — and as part 4 will show, the first draft was wrong in an instructive way.
• No reports or dashboards. One list, sorted by due date, was the dashboard.

The evidence that would justify phase four

The shop again wrote down what to watch:

• Statuses being skipped or mislabeled because the list didn’t match how the shop floor actually worked;
• Customers still asking “is my job done yet?” often enough to matter, now that the shop could at least answer instantly;
• Disagreement inside the shop about what a status meant — the sign that a workflow needs defining, not just recording.

All three arrived within weeks. Part 4 covers the fix: rebuilding the status list from production experience, and separating what the shop sees from what a customer should see.

---

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