Proof approval for print
Stop sending another PDF every time the artwork changes.
ProofQueue keeps the proof, the revisions, the customer's actions and the approval organised in one place. Your customer opens one link, sees every file and every page at the real print size, and approves, replaces or holds it right there.
Every screen on this site is the live ProofQueue interface, photographed with demonstration jobs.
- 1The version the customer already saw, marked ARCHIVED.
- 2The version they are looking at now, on the same link.
- 3Size, pages, finish size and order number, in writing.
- 4Approve, send a replacement, or put it on hold.
A job is only ever in one of four states
Sent to the customer. Nobody has decided yet.
Signed off, with the name of the person who pressed the button.
The customer stopped it and wrote down why.
The customer sent replacement artwork. It is waiting for your review.
The problem
Proofing by email is where print jobs go wrong.
Not because anyone is careless. Because an inbox has no idea which attachment is current, and neither does anybody reading it.
-
What happens now
You are on the fourth email about the same job.
With ProofQueueThe link is sent once. Every new version appears on that same link, so there is never a fifth email carrying a fifth attachment. -
What happens now
Three PDFs are in the thread and nobody is sure which one is live.
With ProofQueueThere are no attachments. The current file is on the page, and every version it replaced is still visible, greyed out and marked ARCHIVED. -
What happens now
The customer approved something — but which version?
With ProofQueueThe approval lands on the version that was live when they pressed the button, and the superseded versions stay on the job rather than disappearing. -
What happens now
The front was approved and the back never was.
With ProofQueueEvery file on the job is on the same page, each listed with its own page count. The customer scrolls past the back before they reach the buttons. -
What happens now
The approval is a sentence buried somewhere in a thread.
With ProofQueueApproval is a button. The customer types their name first, the job status changes, and the name is recorded against the job. -
What happens now
Nobody can tell you where a job stands without opening somebody's inbox.
With ProofQueueThe dashboard counts what is pending, approved, rejected and waiting on new files, and you can filter or search it by job or by order number. -
What happens now
The customer replies “looks good, but change the date” and attaches nothing.
With ProofQueuePutting a job on hold asks for the reason in the same dialog as the decision, so the request and the name arrive together. -
What happens now
Production pulled the artwork from the wrong email.
With ProofQueueProduction works from the job, not the thread. The live file the customer approved and the file on the job are the same file. -
What happens now
Somebody spends ten minutes hunting for the latest artwork.
With ProofQueueEach job is one row: thumbnail, job number, customer, order number, file count and status. Open it and the files are there. -
What happens now
The replacement the customer sent is the wrong size or the wrong number of pages.
With ProofQueueReplacements are checked as they are uploaded: the same page count, and a first page within a quarter of an inch of the original. An administrator still reviews it before anything is replaced.
ProofQueue in use
Four situations every print shop has this week.
These are real screens from the running product, not mockups.
Situation one
The date changed, so the banner changed.
The customer asked for a new date. You uploaded the corrected artwork to the same job. Nothing was re-sent, nothing was re-attached, and the link the customer already has now shows both: the version they reviewed last week, greyed out and marked ARCHIVED, and the version in front of them today.
If they later ask what they signed off on, the answer is on the page.
Situation two
A five-page catalogue, not a five-page scroll.
Multi-page work is where email proofing quietly fails: the customer opens the PDF, checks page one, and replies. ProofQueue lays every page out at once, at the trim size, each one captioned with its own dimensions, with the cutline and safe line drawn on top.
They can change how many pages sit across the screen, open any page full-screen, rotate it, or switch the ruler to centimetres or feet.
Situation three
The customer has a better file. Let them send it.
Instead of a reply with an attachment, the customer presses Upload new file(s) on the proof itself. ProofQueue walks them through the job one file at a time and tells them, before they choose anything, exactly what the replacement has to be.
A wrong-sized or wrong-length file is refused at the door. A correct one arrives as a pending upload for an administrator to promote or reject. Nothing on the job changes until somebody on your side says so.
Situation four
“Where is that job?” answered without opening an inbox.
The dashboard counts every job by state and lets you filter to one of them, or search by job number or order number. Each row carries a thumbnail of the artwork, the customer, the order number and how many files the job has.
When a customer sends replacement artwork, the job moves into New Files and waits for you, rather than waiting for somebody to notice an email.
Before and after
The same ten jobs, run two different ways.
| Step | Before ProofQueue | With ProofQueue |
|---|---|---|
| Sending the proof | Attach the PDF and hope it is the right export. | Send one link. Every file on the job is on it. |
| A revision | A new email, a new attachment, a new chance to open the wrong one. | The new version appears on the same link. The previous one is marked ARCHIVED. |
| Front and back | Two attachments, sometimes two threads. | Both files on one page, each labelled with its page count. |
| A multi-page job | Pages the customer scrolls past in a PDF reader. | Every page laid out at once, each captioned with its own size. |
| Checking the size | The customer guesses from what fits on their screen. | Rulers, a cutline, a safe line, and the finish size written out. |
| Getting approval | “Looks good” somewhere in a reply chain. | A button, a typed name, and a status that changes. |
| A change request | A reply with no file, or a file at the wrong size. | A hold with a written reason, or a replacement checked as it is uploaded. |
| Checking status | Search the inbox and ask around. | Open the dashboard. Filter, or search the order number. |
| Handing to production | Whoever finds the newest attachment first. | The live file on the job, with superseded versions still visible but marked. |
| The record afterwards | Scattered across several mailboxes. | On the job: the versions, the actions, the approver's name and the order number. |
What it is worth
What actually changes in the shop.
Fewer emails per job
One link replaces the thread. Revisions do not generate new attachments, so the conversation stops growing.
Fewer reprints from the wrong version
Superseded artwork is visibly marked rather than quietly sitting in an inbox waiting to be printed by mistake.
Approvals that arrive as approvals
A decision is a status on a job with a name attached, not a sentence someone has to interpret.
Something to point at in a dispute
The version history, the approver's name and the order number stay on the job after the argument starts.
New staff can find the current file
The dashboard and the job page tell them. They do not need to know who was on the thread.
Customers can approve from a phone
The proof page works at phone width, so a sign-off does not wait for somebody to get back to a desk.
See it run against one of your own jobs.
A demo takes about twenty minutes. Bring a real proof — a double-sided sign, a multi-page catalogue, something that has already caused an argument — and we will put it through ProofQueue while you watch.