Guide · Proofs · 4 min read · updated 4 September 2026

Proof approval for personalised orders: getting a yes before you make it

The most expensive item in a personalisation shop is the one made twice. A name spelled the way the customer typed it, in the font they picked, engraved and shipped, and then the email: it was meant to be Nakamura with a k. The material is gone, the slot on the machine is gone, and the second shipping label is yours.

A proof step catches that before the cut. This guide covers what a proof has to show to be worth the customer's minute, when it is right not to ask, and how to keep the step from becoming the bottleneck.

Why a proof step pays for itself

A proof does two things. It moves the spelling decision back to the person who typed it, at the one moment they will actually read it. And it records who approved which version, when, from which link, so a later dispute is a look-up rather than an argument.

It also changes what a remake costs. When the customer approved the proof that had the typo in it, the second piece is a favour, not an obligation.

What a proof needs to show

Most proofs fail the customer's minute: a photo in an email with no context. A proof that gets a considered yes shows:

• The rendered proof at full width, next to the personalisation exactly as typed, so the spelling is checked where it matters.
• The font and the options, named the way the customer chose them.
• One item per section. An order with two personalised items gets two approvals; approving one never approves the other.
• Two actions only: approve, or request changes with a short note and, if you allow it, a file.
• A short window to change their mind after approving, and a plain sentence saying when the shop starts.

When not to ask for a proof

A proof for every item is a delay on every item. A tote with a monogram in one font needs no approval from a customer who typed two letters; a cutting board with two lines of text in a script face does. The rule should be a setting, not a habit:

• A shop default: never, always, or only when a text or upload property is present.
• A per-product override: proofs off for the totes, on for the boards.
• A per-job switch: waive the proof on this one, or ask for one where the rule says no.

Reminders, auto-approve and the hold

A proof that is never answered is a job that never starts. Three mechanics keep the queue moving without anyone chasing:

• Reminders after a number of days, repeated up to a limit, then stopped.
• Auto-approve after a set number of days, off by default. When it is on, the customer is told in the proof email and on the page: if we don't hear back by that date, we go ahead with this proof.
• A fulfilment hold on the Shopify order while the proof is pending, shown there as held for proof approval. It lifts the moment the proof is approved or waived, so nobody ships an item that was never checked.

Rendering text proofs instead of drawing them

For text in a font, the proof is the same picture every time: the product photo, a text box, the customer's words set in the font they chose. That can be a template set up once per product: the photo, where the text goes, which option value maps to which font file. The proof is then rendered when the order comes in and is ready to send before anyone opens the order.

Artwork uploads still need a person. The template covers the part of the queue that was never worth a designer's time.

Doing it with StatusClerk

StatusClerk makes the proof rule a setting at all three levels: the shop, the product, the job. It renders text proofs from a template you set per product, or per variant, and emails them in your name, behind a signed link that needs no login. Approvals and change requests are per item, taken on the page or in the block on the order status page. It runs the reminders, the disclosed auto-approve, and the fulfilment hold. A job becomes ready to produce once its approval is final, when the customer's short window to change their mind has closed, or the moment its proof is waived; never by hand.

Questions