Names are really important. When people are working on complicated and expensive projects (almost all software projects) use the same term that has multiple meanings, I get very nervous. Words like products, items, documents, etc. can all mean the same thing and also have drastically different meanings.

Shared understanding comes from defining your terms and then having the patience and discipline to hold everyone accountable to the agreed upon understanding. This means that you might answer the same question 35 times during the course of a project. Each time you answer it you will be building that common understanding. This is especially important when your project team is a hybrid team of technology vendors, your staff, and potentially outside consultants. You have three different parties with three different "default languages" coming together to create something together that is expected to deliver on a unified vision of success.

One term I like to define very clearly at the outset of any web-to-print project is the term "product workflow." The purpose of web-to-print is to enable self-service engagement with your customers online. The determination of what types of product/services you want to offer your customer is a key tenet of any web-to-print strategy. The reason I like the combined term of product + workflow is that web-to-print is NOT standard e-commerce (shop, select, checkout). Web-to-print might have several steps in between the "shop" and the "checkout" steps, this is where the term “workflow” comes in, and more and more web-to-print workflows aren’t ending up in the cart at all (see my previous article on this subject).

A product workflow defines a series of steps the self-service online customer is guided through which may or may not end in checkout. For example, a variable data product workflow might take the user through a customization step, then a preview step, then end in a download or share step without ever hitting the shopping cart.

Common Web-to-Print Product Workflows

Ad Hoc

This is term I argued for quite aggressively more than a decade ago. The Ad Hoc product workflow is how most print is purchased today - the customer contributes a key part of the custom manufacturing process during the procurement process in the form of their files/assets. Most Ad Hoc print is handled by email today, your customer emails you an open text description of what they want and attaches their file. Web-to-Print systems are diving into this area through the use of configurable specification forms, intelligent uploads, and dynamic previews of the user’s selections.

One pet peeve I have about the Ad Hoc product workflow is that our industry initially separated this workflow from the idea of a Catalog. The Catalog (another term we should all define) is one feature component of the "shopping experience". Every product workflow exists in the shopping experience so an Ad Hoc product can and should exist in a shopping experience right next to a Promotional Product. When the customer clicks on an Ad Hoc product they are taken through a specific workflow (upload, specify, preview, checkout). When you click on the Promotional Product you might simply be taken right to the cart. Both products exist as equals in the shopping experience, yet they take very different workflows and potentially different destinations.

Another pet peeve is when people think ordering a brochure is a different product workflow than a flyer. They have different specifications, but they both fit into a workflow that has the same basic steps (provide assets, specify, preview, order). In certain cases, it’s easier to create a new workflow for Ad Hoc products that have a unique shared set of specifications, a good example of this is the oversize/wide format product set. Don't create a new product workflow for a simple variation, make sure it warrants a different approach.

Static Print Products

Another core challenge web-to-print systems solve is the distribution of materials in their current "approved state." A static product is simply that - a printed item that can be ordered in a self-service fashion. The distribution options are again part of the workflow; download, print on-demand, pull from inventory, etc. they should be part of the configurability of the product workflow.

Non Print Products

I struggle with the naming of this product workflow because outside the print industry this is what traditional e-commerce solutions support, the sales of physical stuff. One feature that has tripped up many web-to-print systems over the years is the idea of product variants. The best example is if you decide to sell promotional products through your web-to-print systems and apparel is a product category. You'll need to support the idea of a shirt as a product and then a combination of variants of that shirt (S, M, L, XL) and (Red, Blue Green). Product variants most definitely associate to unique SKUs in inventory and could also be priced differently.

Variable Data Print Products

This product workflow is probably the one most printers are familiar with because the whole idea of versioning and personalization is where the most obvious value came from web-to-print for both the customer and the printer. Web-to-print enabled customers to create their own "version" of a product. Versioning is the creation of one unique record of a printed product, typically done via a form that provided the user the ability to add custom data on top of a template. Personalization on the other hand is when the user wants to create multiple unique records based on a data feed into the template. If you take this one step further, you get to what I called a "Combo Variable Data Product" where in the same product you are both entering data from the form to customize the piece AND then also adding a data stream to personalize each piece to a recipient. A real estate flyer is a good example of a combo product, you choose a price and photos via the form to create a version for the specific property, then upload your mailing list to personalize to your recipient list.

There are endless variable data products variations, one unique one that is often set apart because of some unique steps in the workflow is Direct Mail. Just like wide format, Direct Mail might warrant its own workflow to deal with the address cleansing, list purchasing and such.

Email Campaigns

As we move beyond print into digital communication products, our definition of a product workflow has to include products that are delivered via the network rather than a truck. An email campaign workflow allows a self-service online user to customize an email template and then send it to the list of their choice. This is very similar to the "Combo Variable Data Product" above but with a very special distribution method that needs to consider the dynamic complexity of email “deliverability” (aka making sure it doesn't land in spam folders).

Many people in the print industry repeatedly ask me the question, "do you really think people will be doing more complex stuff like sending email campaigns in a self-service online environment?" My unequivocal answer to this question is YES, IF you can make it easy enough on the user. The tools to do marketing today are democratizing who can actually deploy the marketing. When you deploy technology that enables local marketing to occur within the carefully constructed brand constraints you empower organizations at the local level.

Multi-Step Campaigns

The next level of complexity up from the email campaign is a campaign that potentially combines print, personalization, email, and a landing page. Yes, this is being made available via a self-service online user experience today. Doing a full-service campaign like this takes a lot of human expertise and very good technology. The self-service version of the Multi-Step Campaign has to be very prescribed in order for people with little to no skills to execute on it. You have to spoon feed them in small bites to enable adoption and then even more important you have to spoon feed them in small bites on the results so that they drive the desired behavior.

Kits

Of all terms that really require solid definition this one is at the very top. Kit is a common word that everyone has a definition in mind when you say it. This makes it ripe for confusion. The Kit often creates a crazy amount of complexity when people ask for crazy things like; Kits with multiple product workflows in them, with multiple distribution methods, fulfilled by multiple vendors, complex assembling requirements, and the list goes on forever.

I define a Kit as a collection of products that ALREADY exists in your system which may or may not be available to be purchased individually. Remember the idea of product workflows here, when you build a kit that contains one static product, one versioned product, and then one non-print product that you fulfill from inventory you can begin to understand that the kitting product workflow needs to take into consideration a user experience that guides the user through the steps required to get the kit into the cart. When you deal in kits you have to think through lots of aspects including but not limited to; pricing, shipping, out of stock items, configurable kitting, and on and on forever.

Be careful of going down what I call the Kit Rabbit Hole. Too many systems have enabled a level of kit complexity that exceeds the capabilities of the shopper. This happens because the people giving the kit requirements are including everything that would make their lives easier from a fulfillment perspective without thinking through what the user experience will be. Be careful here, too much time and money has been wasted by requirements that aren't well thought through from the user perspective. When there is no user adoption of a feature, there is no chance of a return on investment (ROI).

Define your terms and share that definition with all stakeholders of the project. If you have a web-to-print solution today, what product workflows do you support? What product workflows do you think your customers have a need for? If you're shopping for a web-to-print system, create a strategy for what product workflows you want to support BEFORE you get any demos or talk to anyone in sales at a vendor.