Production Hub

The order was the product all along

Print people have always thought in jobs. The industry even has a standard format for job tickets, so putting the order at the center wasn’t a new idea.

What made it hard was history. PrintOS had grown one app at a time, and each app kept its own version of the job, looked after by a different team. We could have given every app the same look. It would have felt tidier, but the gaps between them would still be there.

So I didn’t start with screens. We defined the order once, as a shared structure every service can read and write, and connected the existing apps to it. Moving all the data would have taken years. A shared definition let the apps keep running while they stopped disagreeing.

What used to be an app is now something the order carries: its artwork, its place in the schedule, the state it is in, the conversation around it.

Built for the extreme case

One shared record works well for a box of business cards. I wanted it to hold up at the other end too. Imagine a global brand wrapping buildings in a dozen cities on the same morning. That’s one client and one campaign, but a dozen orders and hundreds of panels, printed alongside other clients’ work.

That’s where my first model broke. Operators don’t think in orders. They think in runs: a batch of panels, often from several clients, on one machine at one time.

So the model has two sides. On one side are the client, the campaign, the order, and its items. On the other are the runs. Each item knows which run it belongs to, and each run knows which orders it touches. If a printer stops, every affected order shows it straight away, and the account team knows before the client has to ask.

Orders can start with gaps

Big orders rarely arrive complete. Files come late, and a visual changes two days before launch. That’s normal, so the system had to allow for it.

An order can exist unfinished, and each step simply says what it needs before it can begin. Scheduling needs sizes and dates, printing needs approved files, and shipping needs an address for every destination.

From there, orders move through a few clear states: waiting for files, in proof, scheduled, on press, partly shipped, delivered. Reprint branches off that path. Each state belongs to one team. Once a proof is approved, the specs are locked, and any late change becomes a new version that goes back through proof. Nothing gets quietly edited after sign-off.

Automation that knows the work

The automation that matters starts on the production floor. If a machine goes down, its runs are flagged and every affected delivery date is checked again. When a run finishes, the finishing team gets its task. When a client rejects a proof, the order goes back to the account team with the client’s notes attached.

None of this is configured off to one side. A rule sits on a stage of the order’s own path, and says what should happen the moment a job arrives there: who picks it up, and what they are told. The states aren’t only labels. They are where the automation lives.

Every automatic step leaves a note on the order. When a task appears and nobody knows why, people stop trusting the system, and that trust is hard to win back.