Shirtee.cloud Blog

Personalised POD products: Check customer inputs before approving the print file

A personalised product is ready for production only when the customer's input, selected product variant and approved print file all match. A completed name field is not enough. Before you start selling, decide which inputs you accept, how you check the result and which action actually releases the order for production.

Here, personalisation means changing a design for an individual order, for example by adding a name or date. It differs from a fixed collection in which everyone buys the same artwork. The workflow below is an original planning exercise. You need to verify which functions your store and its particular Shirtee.Cloud connection support.

What should a personalisation field explain?

State next to the field exactly what will appear on the product. “Name to print” is clearer than “Your details”. Show a fictional example and explain whether spaces, hyphens or multiple names are intended. Separate print text from delivery requests: “Please deliver by Friday” must not accidentally become part of the design.

Keep your first version manageable. A name field and a choice of artwork colour are easier to test systematically than free text, images, positions and fonts all at once. Restrict only what your design requires, and explain a limit where the customer encounters it.

A character limit is an input rule, not proof of readability. “Mila” and “Wilhelmine” require different amounts of space. Even names with the same number of letters can have different widths. Check both the content and how it appears within the intended design area.

Separate collection, design and approval

Three steps need clear ownership: the store collects the input, a design step creates an individual file, and an approval step releases that exact file for production. A storefront preview does not prove that the correct file has reached the production order.

If you are planning an Etsy shop with personalised designs, check three separate steps for each order: the captured customer input, the print file created from it and approval of that file. A name field or preview alone does not prove that the correct file reaches production. Before launch, establish how your particular order workflow should pass this information to Shirtee.Cloud and which checks are possible before production approval. This example assumes neither a native Etsy integration nor automatic personalisation.

For your own connection, record where the individual file is created and who reviews it. Establish how incomplete orders are held back. Start selling only after tracing the route with a test order. The guide to testing the order journey helps you check the wider process.

Build a small test with difficult inputs

Do not test only a short name without special characters. Use a consistent set of fictional inputs that exposes the practical boundaries of your design:

Test input What to check Expected decision
Mila An ordinary short name Correct transfer and suitable appearance
João Accent and character support The character survives in preview and file
Anne-Marie Hyphen No unintended splitting or substitution
A very long double name Width within the design area Planned adjustment or a clear follow-up question
Spaces only Missing content No production approval
A symbol or emoji Support in the chosen design Check rendering; ask if it cannot be used

This table does not define universal technical limits. A character that fails in your first design may work perfectly well in another. What matters is that a failure is not silently replaced by a different character.

Check leading and trailing spaces deliberately, too. Technical clean-up must not change intended spelling. If names will appear in capitals, make that design choice clear before the customer orders. Avoid presenting one version in the preview while sending a differently styled version to production.

Which file belongs to which order?

Use a unique combination of order reference, line item, variant and file version. One original example is TEST-1042-POS1-v2: the second file version for a particular line in a fictional test order. A person's name does not need to appear in the filename.

Also record which input produced the file and which version was approved. If the text changes after a clarification, give the new file a new version. An earlier preview cannot serve as approval for artwork that has since changed.

Before release, compare three things side by side: the confirmed print text, the actual file and the selected product variant. Check that the preview shows the same content. Product-specific resolution and export requirements still apply; the guide to preparing print files explains the foundations.

Use the same check for repeat orders. A customer may want the previous layout with a different name, rather than an exact duplicate of the old file. Make the requested difference explicit instead of relying on a vague note such as “same again”.

Treat changes as a separate decision

Define how a change request is checked before promising an adjustment. Saving a new file does not automatically mean an order already released downstream can still be changed. Check its current processing stage and the actions actually available in your setup.

Start with one design, a few input fields and documented tests. Record which questions arise and which fields customers misunderstand. Improve the field instructions or file checks first. Your personalised range can then grow around a repeatable process, rather than requiring a new improvised solution for every order.

AI-generated illustration of personalisation checks; not a specific catalogue product.