What to Send for a Clean First Proof: Build the Handoff
Send the product and side, authoritative artwork, approved copy, separate logo, photo, and QR assets when available, the current template, source version, and a short upload note. Identify what the proof must answer: content, crop, placement, size, bleed, safe zone, image detail, or page order. A proof cannot choose missing facts after the handoff.
The 55printing File Uploader is easier to review when the file, product, assets, and question arrive together. Use the current template for geometry, keep the source version visible, and use the proof path to compare the prepared file with the requested result.
What belongs in a proof-ready handoff?
Start with the product, finished size or product selection, side or page, source version, approved copy, logo authority, photo role, QR destination, template, and requested output. Separate a reference screenshot from the production source. If an asset is missing, say so; do not ask the reviewer to infer it from a compressed preview.
| Item | What to identify | Proof question | Risk if missing |
|---|---|---|---|
| Product and page | Size, side, orientation, order | Does the file match the product? | Wrong canvas or reading order. |
| Source and copy | Authoritative version and exact text | Is content unchanged? | Old or guessed information. |
| Logo and photo | Approved asset and intended role | Are identity and crop correct? | Soft, wrong, or substituted assets. |
| QR destination | Destination and test context | Does the code point to the right place? | Printed code can be difficult to replace. |
| Template and note | Current geometry and open questions | Are boundaries and requested changes clear? | Review depends on assumptions. |
How should the upload note be written?
Name the product, side, source version, PDF or export version, approved copy, asset roles, template, requested action, proof checks, and unresolved question. Say which file is authoritative and which is reference. Keep credentials and unrelated personal information out of the note. The note should help the reviewer reproduce the decision without opening a guessing exercise.
- Name the job and product.
- Identify the authoritative file.
- List approved copy and assets.
- State the requested change or no-change rule.
- List proof questions.
- Record any missing source detail.
What should be separated before upload?
Keep the editable source or named PDF separate from screenshots, old proofs, reference images, and unrelated files. Keep logos, photos, QR source or destination details, and exact copy identifiable. If the file is already flattened, explain what it is meant to prove and request a source decision for anything that cannot be verified.
Which questions should the first proof answer?
Ask the proof to compare exact content, logo identity, photo crop, QR placement and destination, product size, orientation, bleed, safe zone, page order, and image detail. Separate questions about source authority from questions about appearance. The Artwork Quality Enhancer can be considered for visible source defects, but it cannot create missing facts or approved assets.
Which handoffs need extra care?
Business card with a small logo
Send the approved logo asset, exact copy, product side, and current source. Ask proof to compare identity, type, crop, safe placement, and any small-detail limitation.
Postcard with a QR code
Provide the destination, test result, source code asset, product template, and requested side. Ask proof to compare quiet space, contrast, crop, placement, and destination context.
Flattened screenshot handoff
Label the screenshot as reference and send the best source or named PDF. List the exact question it answers; do not treat display pixels as proof of dimensions, bleed, or editable copy.
Questions customers ask
What should I send first?
Send the product and side, authoritative artwork, source version, approved copy, current template, separate logo/photo/QR assets when available, and a short note. State what the proof must answer. Label screenshots and old proofs as references so they do not compete with the production source.
Why name the source version?
Version names prevent the reviewer from choosing between old and current files. Identify the authoritative source, export, and reference separately, then list the requested change. This keeps proof comments tied to the correct file and makes later corrections traceable. Record the version in the upload note and filename so the decision remains reviewable after handoff.
What belongs in the upload note?
Name the product, page or side, source and export versions, approved copy, asset roles, template, requested action, proof checks, and open question. Keep credentials and unrelated private information out. A concise note lets the reviewer understand the handoff without reconstructing your file history.
Should logos and photos be separate?
Keep approved logos and important photos identifiable when they carry detail, identity, or crop decisions. A separate asset can clarify authority and allow comparison with the source. If the artwork is flattened, explain which pixels are reference and which file is production authority.
How should QR information be sent?
Identify the destination, source code asset or creation authority, product side, and intended placement. Test the destination independently and ask proof to compare the code, quiet space, contrast, crop, and product context. A screenshot of a phone screen does not establish the destination.
Does a proof fix missing files?
A proof can reveal placement, crop, content, size, bleed, safe zone, and image-detail problems in the prepared file. It cannot create an absent logo, exact copy, source dimension, or approved QR destination. Mark missing inputs before asking for a final proof decision.
What if the file is flattened?
Send the named PDF or best original file, keep the flattened file as reference, and explain what it is meant to show. Identify any missing layers, exact text, logo, crop, or product information. Request a source or redraw decision when those facts matter to the job.
How do I request a clean correction?
Reference the product, page, element, source version, exact approved correction, and proof question. Confirm what is already correct and what must remain unchanged. If the correction introduces a new layout, identity, or product decision, record that as a new scope question.
Name the source, product, approved assets, request, and proof questions before sending the file for review.