Adding a product to your Web-to-Print store and updating its content and specifications as requirements change, is an easy task. But to build a vast and complex product offering that can cope with any change in requirements, you need to plan well from the very beginning. You may have heard the phrase “Begin with the End in mind”, but with XMPie you can “Begin with the Back-End in mind,” because the web-to-print administrator can plan and automate the implementation of change requests.

Choosing a highly optimized approach upfront can save hundreds of hours’ worth of maintenance tasks. Our team at 121 Services recently helped one of our customers to streamline their top client’s inefficient template architecture – reducing the time they spend on maintenance tasks from 30 hours per week to just 15 minutes – and in this post, I’ll share how we did it.

By taking this approach, instead of manually updating products with new content and specifications, you’ll have much more time free to concentrate your efforts on higher value activities like winning new business and customer service.

Adding Corporate-Controlled Content to Products

Corporate Web-to-Print sites usually contain many different product types. Some products may have unique components, others may share characteristics, but all of them are likely to share the requirement to follow specific corporate-controlled content.

For instance, during the ordering process for products such as business cards, the print buyer needs to fill out a form with information such as office location, name, address, phone number, etc.  Instead of bothering (or trusting) the print buyers to add the content themselves, it is best practice to offer content from a pre-filled menu or form. Pre-filled form data ensures that brand guidelines are protected, typo errors are eliminated, and the user experience is simplified.

With XMPie the web-to-print administrator can set up form-fills, drop-down menus, image selectors, dependent drop-down menus and more, and prepopulate them with corporate-controlled content fetched from a central data source to create a seamless portal user interface.

For more complex requirements, the web-to-print administrator can use custom JavaScript rules to guide the portal user through the user journey from product selection to check-out. Database lookups on the back-end can even be added based on the user login.

Template Architecture Planning

But how should the web-to-print administrator organize the template architecture of their site to maximize efficiency and take into account future product changes?

Approach 1: Build Each Product Individually

One approach is to add and build each product individually. If the content of your product is unlikely to change, you can hardcode all the business logic at the product level in InDesign using XMPie’s uCreate Print plugin.  In this scenario, you may end up with many campaigns , each with its own business rules and logic to incorporate the corporate-controlled content, and each with a unique product definition.

With this approach, whenever the corporate-controlled content needs to be updated, the web-to-print administrator will need to change each and every product, along with the business rules and product definitions. This method is only advised if your products don’t share any content or specifications. You can imagine how much time would be needed (I’d say wasted) to do this change for hundreds of different products.

Approach 2: Add Content and Logic to Multiple Products at Once

But if you have multiple products that share the same business logic and use content that will need to be updated continuously, a much better method is to build the logic and rules into the product update method itself. With this approach, the web-to-print administrator can be prepared in advance for any inevitable content changes and save time when content needs to be updated.

Our customer needed help with streamlining their top client’s inefficient template architecture. Although the client’s store offered over 75 StoreFlow products which used similar business rules, because the rules had been hardcoded per product, it was challenging to accommodate any change in content, e.g., address. The client required corporate-controlled product updates multiple times per week for multiple offices, and it was taking them up to 30 hours of work per week to perform the product changes to InDesign and StoreFlow.

Instead, we wanted to minimize the moving parts, so we wrote a common business rule which pulls the content from a centralized product information database using a uPlan User View (a component of XMPie’s uPlan application for handling complex data and logic requirements). This common business rule enabled us to specify and control the business logic (rules) for all the StoreFlow products together. The drop-down menus in the admin tool were also set to use the same centralized database which is automatically refreshed every 15 minutes. 

This optimized architecture was a game changer in terms of cost. New locations could order critical startup marketing collateral fast. Instead of waiting a week or more for the new corporate-controlled content to be added/updated to each product, the new flow now takes about 15 minutes and is always current.

Begin with the Back-End in mind

Before you begin to plan your next multi-Product StoreFlow project, ask yourself one crucial question: How can you minimize the moving parts to take advantage of the efficiencies that XMPie offers to reduce repetitive maintenance tasks?

About the Author:

Ed Kotnik is a Solution Specialist at 121 Services, a US-based professional services company specializing in XMPie Web2Print, complex print, and omnichannel solutions support.