Do you have a folder in your company called “graphics NEW final v3 definitive (1)”? Don't worry, most of our clients do too. And that folder is exactly why reordering a simple job can take three days instead of three hours - someone first has to figure out which file actually went to print last time.
Why it's worth building a production file library at all
Because every reorder without an organized archive risks sending to print a file with an error that was already fixed once before. We've seen it many times: a client calls, says “the exact same thing as last time,” sends a file from their inbox, and the file is missing a correction we made at their request six months earlier. No one is lying, no one is at fault - there were simply five versions of the same logo in the mailbox, and the wrong one went out.
For a one-off order this doesn't hurt, because you're settling everything from scratch anyway. For recurring orders - labels for the same product line, a catalog refreshed every season, bulk packaging ordered quarterly - the lack of order starts costing real time and nerves. And time in this business usually means a production deadline that no one likes to push back.
What should actually go into the library
Not just the graphic file - that's only half the story. A complete set for one product should include the source file (native, e.g. from a graphics program, with layers preserved), the final production PDF sent to print, a material specification (weight, paper type, finishings), and - if the product requires it - the die-cut file or information on which die-cut was used.
Add one thing people forget most often: a note on what was agreed. Something like “client asked for a warmer shade of red, +3 to magenta compared to the original design.” A year from now no one will remember that conversation, and a file without such a note looks identical to a version without the correction.
Minimum archive set per product: Source file with layers, final production PDF, specification sheet (paper, finishings, dimensions), die-cut file for packaging, a short note on any non-standard arrangements.
File naming convention, or the simplest thing people neglect most often
A good file name answers three questions without opening it: what it is, what version it is, and when it was made. Something like “label_moisturizing-cream_200ml_v3_2024-06.pdf” says more than “label final final2.pdf,” and takes exactly the same amount of time to write.
Set one scheme for the company and stick to it rigidly, even if it seems overly formal. Product or project name, then version, then the date in year-month format (because it sorts correctly alphabetically, unlike day-month-year). If you have several language or flavor variants of the same package, list them separately - “box-tea_lemon_v2” and “box-tea_honey_v2,” not two files with the same name in different folders, because that's a sure way to send the wrong flavor to print.
Avoid these in file names: “final,” “definitive,” “to_print,” “CORRECTED” without a version number and date. These words say nothing six months from now, when you'll have five files with the same word “final” in the name.
Versioning, or how not to lose the history of corrections
Every change to a design is a new version number, not an overwrite of the old file. It sounds obvious, but in practice most companies overwrite the file under the same name, because “it's still the same design, just corrected.” The problem shows up when, six months later, it turns out the previous version was better, or the client wants to go back to an older layout - and the file no longer exists, because it was replaced.
Simple rule: v1 is the first version sent for approval, every subsequent substantive correction (text, layout, color change) gets the next number. The version that actually went to print deserves its own marking in the name, e.g. an added “_PRODUCTION” or “_printed” note, so that a year later no one has to guess which of the seven versions was the final one.
For packaging, this rule carries extra weight, because the rules for preparing such projects require accounting for the die-cut, cut and score lines, and separate layers for special finishings [prepress.packaging_requirements]. If someone shifts a score line by a millimeter during a correction and the old file version disappears, no one will be able to reconstruct which construction actually went into production.
A folder structure that still makes sense a year from now, not just today
The folder layout should reflect how you actually search for files, not how convenient it was to save them at a given moment. The structure that works best is client or brand at the top, then product or product line, and only inside that the individual versions and dates. If you have many clients and many recurring orders - seasonal catalogs, labels for a fixed product line, bulk packaging - this layout lets you find the right place in seconds instead of digging through email.
The material specification deserves its own folder. We work with paper in specific weight ranges - uncoated offset 80-140 g/m² for book blocks and functional materials, gloss and matte coated stock 115-350 g/m² for catalogs and promotional materials [paper.offset_uncoated.gsm] [paper.coated_gloss.gsm] - and if a client has once settled on a specific weight for their catalog, it's worth recording that alongside the file rather than relying on memory nine months later.
What to keep separate: master files versus working files
A master file is the one that actually went to print and was approved - a working file is everything that came before it. Mixing these two categories in one folder is the most common cause of mistakes on reorders. Keep master files in a separate location, ideally protected from accidental editing - a folder called “FOR REFERENCE, DO NOT EDIT” sounds clunky, but it works better than anything more elegant.
The format of the master file matters too. Our production standard is CMYK, and the preferred print format is PDF, ideally a flattened PDF/X-1a, because such a file has built-in safeguards against accidental changes to color profiles or fonts [prepress.file_format] [prepress.colorspace]. If the library keeps the master file in exactly this format, the risk of someone accidentally changing something in it and sending the altered version as “the same as always” drops to practically zero.
Master file = the one that went to print and was approved. Working file = everything along the way. If these two categories get mixed up in one folder, sooner or later someone will send the wrong version to print.
A real-life scenario: reordering labels after six months
A cosmetics manufacturer orders labels for a cream line once a quarter, always in the same run size, sometimes with a small change - a new batch number, an updated ingredients list on the back. Without a library, every such order starts from zero: digging up an email from three months ago, checking whether it's really the right version, asking about the material again.
With an organized archive, it looks different. The client opens the “label_moisturizing-cream” folder, sees the latest version marked as production, sees a note next to it about the material and run size, and the entire communication with the printer basically comes down to one sentence: “same as before, just change the batch number to X.” We produce labels as self-adhesive, on a roll or in sheets, matching the technology to run size, material, and application requirements [labels.types] - and choosing that technology happens much faster when the specification from the previous order is written down rather than reconstructed from memory.
The most common mistakes when building such a library
First and most common: the archive exists only in one person's head. As long as that person works at the company and remembers where everything is, it works. The problem appears when that person goes on vacation, changes roles, or simply forgets because a year has passed. A library only makes sense if anyone else in the company can read it without additional explanations.
Second mistake: keeping everything in one flat folder of email attachments. That works for the first ten files, then turns into a pile where the name “logo.ai” repeats seven times across different subfolders.
Third mistake, less obvious: no information about which file is in which resolution and what it's actually suitable for in practice. The standard resolution for images used in offset and digital printing is 300 dpi at 1:1 scale, while large-format prints viewed from a distance only need 150 ppi [prepress.image_resolution_dpi] [prepress.large_format_ppi]. If the library contains images in a lower resolution with no description of what they were meant for, sooner or later someone will use them where they don't belong - and the result will only become visible on the finished print.
What this looks like for packaging, because the stakes are higher here
For packaging, the library must contain something more than graphics - it must contain the construction. We produce various construction types, from unit and bulk cartons through flap boxes, including FEFCO 0201 and related styles, to shaped boxes with a lock, lid-and-base boxes, drawer boxes, sleeves, gift boxes and rigid boxes, as well as constructions designed individually for a specific product [packaging.constructions]. Each of these constructions has its own die-cut, and that die-cut is a separate file that must be linked to the graphics - otherwise, on reorder, someone might use graphics designed for one construction together with a die-cut from a completely different one.
There's a practical upside to this: on reorders, the physical die-cut tool is often kept from the previous order, so a well-documented library lets you immediately verify whether the reorder can use the existing tool or whether a new one is needed. That's a difference worth knowing before you start counting the production schedule, because standard packaging production takes 7-12 business days, and knowing what needs to be prepared from scratch versus what already exists affects the real turnaround time [packaging.leadtime.production_days].
Tools - you don't need to buy an expensive DAM system
For most companies, even those with several product lines, a well-organized network drive or cloud storage with a clear folder structure and consistent file naming is enough. DAM (digital asset management) systems make sense at a truly large scale - hundreds of SKUs, multiple brands, multiple design teams scattered around the world. If you order a dozen to a few dozen products on a recurring basis, a simpler system arranged by hand, but consistently, works just as well and doesn't require an implementation that eats up time on its own.
More important than the tool is designating one person or process responsible for keeping the library up to date. A file with no process owner sooner or later ends up in the “old” folder, next to ten other ownerless files.
What this means for working with a printing company
An organized library on the client's side shortens the entire reorder process, because we respond to quote requests within a maximum of 24 hours regardless [company.response_time_h], but how long it takes to prepare the actual job for production largely depends on whether the file, specification, and any die-cut are ready right away, or need to be reconstructed from conversations held six months ago. A good library is, in practice, a time saver on both sides, not just the client's.
Before sending a file for reorder, check
- Is this really the file marked as production/master, not a working version from email
- Does the version number and date in the file name match the last order
- Is the material specification (weight, finishings) recorded alongside the file
- Is the correct die-cut file attached for packaging
- Does someone else in the company besides you know where this file is kept
A production file library is one of those things that don't look impressive until the moment they suddenly turn out to be priceless - usually on the day an order urgently needs to be reordered, and the one person who remembered the details happens to be on vacation.
production files archiving PDF/X print reorder prepress packaging labels
Looking for a printer? We handle artwork file requirements end to end — from file checks to safe delivery.