Packaging Artwork Management Problems: The 7 That Reach the Printer, and How to Avoid Them

Why does an approval workflow project turn into a full packaging platform?

The brief is narrow: stop approving artwork by email. Then marketing asks for a briefing workflow, because briefs are also chaotic. The agency asks for a portal. Someone raises digital asset management, because photography is scattered too. Procurement mentions the printer tender process. Each is a real problem and none of them is the one that costs you twenty thousand units.

What makes this specific to packaging is that artwork sits at the junction of marketing, regulatory, quality, legal, procurement and an external design agency, so a project touching it becomes the meeting where every one of those functions raises their worst process. The scope grows from the $70,000 to $150,000 first release into the $180,000 to $420,000 full platform, and the release date moves past the seasonal range that prompted the project.

The sequence that works is to build the control first and the convenience second. Release one is the artwork record with locked versions, controlled regulated components sourced from your specification system, sequenced approvals that reset on change, and printer publication with logged downloads, in 12 to 16 weeks. Automated text comparison, the claim library, agency portals and briefing come next, funded by the first release preventing something. Keep it to one brand family, one market and PDF proofs, and defer native file handling until the workflow is proven.

What goes wrong when you migrate the existing artwork archive and approval history?

The archive migrates. The approval history does not, because it never existed as a record.

What you have is a folder structure with filenames carrying version numbers that stopped being accurate somewhere around the third revision, plus approvals distributed across individual mailboxes, some belonging to people who have left. There is no reliable way to reconstruct which version of a pack was signed off by regulatory and which was signed off by legal, and any attempt to assert one in a new system is manufacturing evidence.

The second problem is identifying the current approved version per pack. In a mid size brand with several hundred stock keeping units across markets, a meaningful share have two or more candidates and nobody is certain which one the printer is holding. The only reliable source is frequently the printer, which is an uncomfortable discovery and a useful one.

The approach that works is to establish the current approved artwork per pack by confirming with the printer or supplier what they hold, load that as version one in the new system with the confirmation recorded as its provenance, and archive everything else as historical with no approval status asserted. Then the first genuine approval record in the new system is real. Budget this as a workstream with named regulatory and packaging staff, because it is a judgement exercise rather than a data transfer.

Why do the specification, design tool and printer handoffs break after launch?

The specification integration is the highest value link in the whole category and the one most likely to be underestimated. Regulated content lives in a specification or recipe system with its own structure, and mapping ingredient declarations, allergen statements and nutrition data into artwork components is a modelling exercise rather than a field mapping. It breaks after launch when the specification system changes a field or someone adds a new attribute, and the artwork component silently keeps the old value. Impact flagging needs to fire on the source change, not on the artwork edit.

Design tool handoffs break on file format. PDF proofs behave predictably. Native design files carry linked assets, fonts and colour profiles, and a version comparison that works on a flattened proof does not work on a package of linked components. Deferring native handling to phase two is a deliberate choice and worth making.

The printer handoff breaks on habit. You can build publication with logged downloads, and someone will still email a file because that is how it has always worked and the printer's contact asked. The fix is partly technical and partly contractual: lock and clearly mark superseded versions, log every download against a print job, and put it in the supplier agreement that only artwork collected from the publication location is to be printed.

What happens when signature and audit requirements are scoped late?

The build gets partly rewritten. Electronic signature and audit obligations, where they apply, change the record model rather than the interface: what constitutes a signature, what is captured alongside it, how records are protected from alteration, and what validation documentation you need to produce.

The determination of whether they apply belongs with your quality and regulatory team rather than with a software vendor, and it needs to happen in discovery. Teams that defer it end up with a workflow that is operationally correct and evidentially weak, and the remedy is not a settings change.

There is a related trap for regulated businesses. If you are a pharmaceutical or medical device company already committed to a validated labelling system, revalidating a custom build is a cost most people underestimate, and in that situation the honest answer is usually to stay with the validated system and fix the process around it.

The fix is to run the applicability question as a named discovery deliverable with a date, before the workflow is designed. Write down which records require signature, what the audit trail must capture, and what validation evidence your quality team expects. Deciding this after the workflow is built is considerably more expensive than deciding it first, and the difference is not marginal.

Should you build custom or configure what you already own?

If you run fewer than about 50 packaging changes a year with a single market and a single printer, a strict shared drive convention and a two person sign off is proportionate and a build is not. Say that plainly to whoever is proposing one.

If proofing accuracy is your immediate pain, buy GlobalVision regardless of what else you do. It does that specific job well and is why many quality teams have it. Its limitation is that it is a comparison tool rather than the workflow, so you will still need something holding the version of record.

Esko WebCenter is the right answer for a large business with many brands, many markets and a packaging function big enough to own a platform properly. The honest caveat is that it is a configuration programme with a long tail, and mid size brands frequently buy it and use a fraction of it while still approving by email. Kallik suits pharmaceutical and medical device labelling and its content model reflects that origin, which makes it heavy for seasonal food packs and promotional variants. Twona is light and pleasant and runs out of room once you need market specific claim libraries.

Build when two or more apply. Your regulated content lives in a specification system and you want artwork to reference it rather than retype it. You run many market variants and need a claim library with market permissions. Your approval chain includes external parties needing tightly scoped access. Or you have had a print error and the investigation could not establish who approved what.

How do hidden costs get into the quote?

The first is market count, which drives cost more than product count. Each market brings its own regulated content structure and its own labelling rules, and the differences are structural rather than translations. Emphasising allergens within an ingredient list, as required in the European Union, is a different content model from a separate declaration, and packaging and recycling labelling obligations continue to expand under extended producer responsibility schemes.

The second is external party onboarding. Each agency, printer and packaging supplier is an access model, a training exercise and a support relationship. A quote priced for one agency does not extend to five by multiplication, because the fifth one has their own file conventions and their own opinion about your process.

The third is native file handling. Working with linked design files rather than flattened proofs changes storage, rendering and comparison substantially, and it is the item most often assumed rather than quoted.

The fourth is the specification integration itself, which is genuinely the highest value part of the build and requires access to a system that may be owned by another function with its own change control.

The fifth is signature and validation scope, which is a documentation burden as much as an engineering one and cannot be estimated until the applicability question is answered.

What separates an artwork build that works from one that fails?

The first separator is how regulated content is represented. If the artwork holds text, the build has missed the point. You need components that reference a governed source, with versioning and impact flagging when the source changes, so a recipe change immediately shows which packs are affected and which of them are already at the printer.

The second is what happens to approvals when a new version is uploaded. Reset on change is not a preference, it is the control, and a system where prior approvals persist produces false confidence that is worse than email.

The third is whether automated comparison sits inside the approval gate rather than beside it. A tool someone remembers to run is a tool that misses the proof nobody thought needed checking. Extracted text compared character by character against approved components, with a difference blocking the gate until it is explained, is what makes the human review about judgement rather than proofreading.

The fourth is the printer handoff. Publication with logged downloads against a specific job, superseded versions locked and marked, and press proofs checked against the approved record rather than against an email. This is one of the cheapest parts of the build and removes the most common route to an expensive error.

The last is ownership. Your approval history is the evidence you will rely on if a pack is ever challenged. At Digital Heroes the client owns the repository, the artwork archive, the approval records and the infrastructure accounts from the first commit, with complete export at any time.