Print eCommerce Versus Web-to-print

Posted on by Greg Cholmondeley | 1 Comment »

by Greg Cholmondeley, Workflow Practice Director, PODi and Caslon & Company

Evolution by Travis HessmanOne great thing about being in this industry for the past several decades is that I’ve had a chance to witness and participate in the birth and evolution of some of the technology and services. One that has perhaps changed the most is how printers digitally receive jobs. It’s evolved from being a way to electronically get job tickets and files into the shop to mind-blowing new services opportunities. This is a timely topic for me now because I just reviewed an update to EFI’s Digital StoreFront and, while I honestly expected to see the usual product enhancements, what I saw was something that really should no longer be called “web-to-print.”

Here’s my perspective on where this technology came from, how it’s traditionally been used up to where it is today, and how it could be used now. You might find yourself considering where your own operation’s capabilities reside along this timeline.

I did not invent web-to-print, but way back near the birth of the “World Wide Web” (yes, that’s what “www” stands for) I led a Xerox team developing a solution called “Digital Document Connection” for people to electronically send print files to print shops. We worked with PagePath Technologies integrating their “Launch” product with Xerox production printers so that clients could “electronically send their digital files.” Print shops would hand out floppy disks containing special print drivers to their customers. After installing the print drivers, clients could click “print” in their favorite word processor, select the print shop as their printer, and the driver would create print files and job tickets, zip them together, dial the print shop’s modem, and FTP transfer the zip files.

Yeah, I know, this was in the days when we lived in caves and still used dial-up modems over phone lines. It was back in the early 90s right after the first Mosaic browser was created when only a handful of people even knew what a web page was. We even created a version called “Bridge to Digital” where job tickets and single copies of received jobs were printed on a small, departmental printer and then copied and finished on 5090 production copiers for shops who wanted to appear to be digital but weren’t … but that’s another story.

Times have certainly changed. We no longer beat our clothes on rocks to wash them, bread comes pre-sliced, color was invented, and most of us now use the Internet throughout the day for any number of tasks. Throughout this period, the solutions available for sending work to print shops have changed, their features have changed, and the ways they are used have changed.

Early solutions focused heavily on just getting digital files to the shop. Most work back then came in as hardcopy masters and the goal was simply to get digital masters. Many implementations simply used emails for the job information and ftp sites for the files.

Next, the focus shifted to helping clients correctly create and link print-ready PDF files with accurate ticketing. The focus was on reducing errors and turnaround times, and these systems also began to have some job management capabilities for the shop.

Up to this point, the focus was really on finding better ways to get current jobs from existing clients into the shop. Now, print shops began to have their own web pages and the focus began to change to bringing in new work and new clients. The interfaces became prettier and easier to use, with preview images of the finished work and templates for common jobs like business cards, postcards or tri-fold brochures. Print shops could brand these with their colors, images, and product offerings so that they blended into their websites. The focus shifted from job submission to online ordering and this is what I consider the birth of the Web-to-print phase.

These web-to-print systems improved over time, becoming nicer-looking, easier to use, and incorporating more effective print shop management and integration capabilities on the back end. They also began experimenting with other basic services:

  • Non-print, fulfillment ordering
  • Simple variable data printing for business cards, postcards, etc.
  • Basic portals for major clients so that their employees and dealers could order branded materials

Today it’s hard to imagine anyone not having an online method for capturing work, yet most companies I talk to say that their retail online ordering page still only accounts for 5-20% of their revenue. Some get a lot of business through portals for major clients, while others get a lot through manifest ordering systems tied directly into client systems (imagine daily book orders from a publisher, or daily direct mail reminder letters from a leasing company). But even today, a lot of work still comes in the door through print reps.

The next step beyond web-to-print involves expanding to new services beyond just print.  It’s not just a software change – it’s also a business change. The whole focus is changing from one that offers printing which might also have business services to one that offers business services which might involve print. This became obvious to me when I reviewed the new features added to EFI’s Digital StoreFront. It’s no longer accurate to call this web-to-print. It’s more like print-ecommerce.

I use this as an example of where this space is headed because:

  • Yeah, it does all the web-to-print stuff – and looks good doing it in HTML 5
  • It incorporates DirectSmile with their personalized imagery which is way beyond basic VDP
  • It doesn’t just provide customizable portals – it lets print services providers offer ecommerce portal services to their clients where THEY can create and manage portals for THEIR dealers, franchises, branches, etc.
  • It lets print services providers offer client-driven mailing services by bringing mailing automation and data cleansing services right to the clients when they’re placing orders

I believe that this is good example of the next step in how this technology will be used. It’s letting Print Services Providers offer business services related to, but extending beyond printing in much the same way that campaign management and multi-channel marketing solutions let Marketing Services Providers offer a broader range of marketing services to their customers.

It probably helps to see an example of this so I’ve attached one of the videos from the PODi EFI Digital StoreFront Product Briefing. There were so many changes to this product that I created two update videos. The first covers the improved customization, appearance and operability. The second, which is included here, covers the new portal and client-facing mailing services. PODi members can see both videos along with the other product videos in the EFI Digital StoreFront 2015 Update Product Briefing.

One Response to “Print eCommerce Versus Web-to-print”

Comment from Steve Ciesemier
Time June 12, 2015 at 8:03 am

Great history review to place W@P in context, Greg. I remember working with you on DDC (Digital Document Connection) when I was at PagePath. Back then, I had some printers tell me the internet was a fad! Remember those days? BTW, there is a great infographic on the history of w2p here:

At Aleyant, we have embraced a slightly different path for our Aleyant Pressero web-to-print storefront system. Being the first to embrace html5 4 years ago with our Aleyant eDocBuilder as well as one of the first to embrace responsive design for today’s mobile print buyer back in 2014, we have kept our customers on the leading edge, just like you did with DDC years ago.

I agree that simply having an e-commerce w2p system is no longer enough. Instead, PSP’s need an approach that embraces an open ecosystem of 3rd party MIS, preflight, imposition, workflow and rip vendors whose systems can all talk to each other. One where the PSP can mix and match solutions from a variety of independent vendors that work best for their shop.

Yes, for our customers the order flow starts in an Aleyant Pressero storefront, but then it is fed into an automated workflow via API’s or osing hotfolders and our Automated Workflow Integrator. Yes, adding new features to the front end is nice, but integrating the front end with prepress and production is as important, perhaps more so.

Thanks again for your great review, Greg!

Write a comment